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

[Chandra Shehkhar Reddy Potula]

On 08/28/2015 11:11 PM, Paulo Ricardo Paz Vital wrote:
> On Fri, 2015-08-28 at 12:03 +0200, 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.
> Interesting suggestion Walter and I prefer option 3 also.
>
> However, Ginger is an "optional" plugin to manage the host (and here I
> agree 100% with you that some Kimchi operations should be part of
> Ginger) and one question comes with this approach: what will happen if
> user installs only Wok with Kimchi?
>
> If Ginger implements all backend of the network operations, for
> example, and Kimchi has only the frontend using the interface provided
> by Ginger, I will not able to execute all necessary operations to
> create some special virtual networks. This approach will require the
> user to install both Kimchi and Ginger, always. And I guess this not
> what the projects want, for now!
>
> These are my 2 cents and you can not consider it totally since I'm
> coming back to the project :-D
>
> Best regards,
> Paulo
My Preferred option would be 3 for the following reason.

Having host management functionality in ginger and used by all the 
plugins simplify code duplication, but also gives the benefit of end 
user considering the tool not only on KVM but also on base linux.

Ginger is an optional plugin, but in case any plugin needs host 
management functionality then ginger can very well installed. I do not 
think any end user have objection in this case.
Ginger should be having vision of running it either on KVM or even on 
base linux operating system.

On the other hand ginger would also play a role in providing base to 
virtualization (kimchi) or  in even future Containers etc..

I would envision combination of ginger and kimchi plugins together help 
in virtualization in future.

Regards
Chandra

>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>