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

[Daniel Henrique Barboza]

Option 1.

My reasoning is simple: Kimchi does a very superficial, minimal host 
management. Ginger has (or will have) the advanced version with 
full/dedicated support for any host management Kimchi does. In my 
opinion the code 'duplication' is minimal in this case, while we retain 
the independence of Kimchi from Ginger and vice-versa.


On 08/28/2015 07:03 AM, 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
>
> 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