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

[Walter Niklaus]

Aline, Daniel,

thanks for the clarification. It sounds as we don't really have an issue 
here as I thought.

On 31.08.2015 16:25, Aline Manera wrote:
>
>
> 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
>>
>