4:25 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel