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
> - required by ginger to manage the host owned logical
> - 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
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
> 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