[Kimchi-devel] Sharing of functionality between Kimchi and Ginger
Daniel Henrique Barboza
dhbarboza82 at gmail.com
Fri Aug 28 19:00:29 UTC 2015
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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
More information about the Kimchi-devel
mailing list