Sharing of functionality between Kimchi and Ginger
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.
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
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Paulo Ricardo Paz Vital <pvital@linux.vnet.ibm.com> IBM Linux Technology Center
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (5)
-
Aline Manera -
Chandra Shehkhar Reddy Potula -
Daniel Henrique Barboza -
Paulo Ricardo Paz Vital -
Walter Niklaus