[Kimchi-devel] Sharing of functionality between Kimchi and Ginger

[Aline Manera]

On 28/08/2015 07:03, Walter Niklaus wrote:
> Hi All,
>
> first I want to clarify that the following proposal is targeting the 
> 1.6 release and can wait till we have stabilized the new UI in 1.6.
> But I guess that it will take some discussion to come up with a good 
> solution so I thought I'll start it now even knowing that I'll not be 
> able to participate in the discussion for the next 2 weeks since I'll 
> be travelling.
>
> Problem statement:
>    -  there is a set functionalities which are usefull/required in 
> kimchi and ginger, for example:
>          - logical volume management:
>                - required by kimchi to define a storage pool based on LVM
>                - required by ginger to manage the host owned logical 
> volumes
>          - networking:  VLAN assignement, bridge management
>                - required by kimchi on virtual network management
>                - required by ginger outside/without virtualisation
>

I don't see those items as problems or even common to Kimchi and Ginger.

Kimchi does not and will not do LVM management. It is part of host 
management and so part of Ginger.
All the operations related to LVM done in Kimchi is to create and manage 
the logical pool, which means, all the operations (except extend a 
logical pool) are done through libvirt API.

The same applies to network management. Kimchi does not do host 
networking management. All the network operations are done through 
libvirt API.

Ginger as a host management interface should not rely on libvirt (a 
virtualization tool) to do its work.

So if I need to choose one of the options listed below, I'd go with 
Daniel with option 1 - as we will not have code duplicated in Kimchi and 
Ginger based on what I explained above.

> Currently the functionalities mentioned above are part of the kimchi 
> plugin.
>
> Options to address this problem:
>   1. Implement the functionality in both plugins.
>           Pros:   the current code in kimchi can stay unchanged
>           Cons:  code dupplication, double maintanance
>   2.  Share the source code modules
>           Pros:   no code duplication
>           Cons:  potential module duplication since the plugins are in 
> different repos
>   3.  "Interfacing" between the plugins: one plugin implements the 
> functionality and is exposing an interface for other plugins
>           Pros:   clean separation
>           Cons:  dependency between plugins (but we have that anyhow 
> already between kimchi and gingercommon)
>   4. ???
>
> My preffered Option would be 3. but potentially there are othere 
> options and aspect I may have missed.
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>