[Kimchi-devel] Changing the way federation feature (peers) is exposed to user

Tue Jul 19 19:22:14 UTC 2016

Hi,

So we are going with option 3, right? How can we extend Kimchi in Gingerbase or vice-versa to enable federation?

Samuel

-----Original Message-----
From: kimchi-devel-bounces at ovirt.org [mailto:kimchi-devel-bounces at ovirt.org] On Behalf Of Paulo Ricardo Paz Vital
Sent: terça-feira, 5 de julho de 2016 10:38
To: kimchi-devel at ovirt.org
Subject: Re: [Kimchi-devel] Changing the way federation feature (peers) is exposed to user

On Jul 04 05:31PM, Aline Manera wrote:
> 
> 
> On 07/04/2016 02:16 PM, Paulo Ricardo Paz Vital wrote:
> > On Jul 04 12:27PM, Aline Manera wrote:
> > > Hi all,
> > > 
> > > Kimchi provides an feature called federation to discover other Wok 
> > > servers running in the same network.
> > > This feature is not enabled by default. To enable it, the user 
> > > needs to follow the instructions in 
> > > https://github.com/kimchi-project/kimchi/blob/master/docs/README-f
> > > ederation.md
> > > 
> > > The problem is: this feature is exposed by the user as a drop down 
> > > menu with a list of servers found. But it is displayed in the top 
> > > header, ie, on Wok header.
> > > That way, we have some code on Wok related to a Kimchi feature.
> > > To fix it, we should change the way we expose that feature on UI 
> > > moving it as a content tab.
> > > As it is not strictly related to virtualization I don't see it 
> > > fits in any current Kimchi tabs and I don't think it justifies a new tab.
> > > But from the other hand, there is a plan to integrate the 
> > > federation feature with guest migration, so user don't need to 
> > > input the server details to do the migration - he/she only needs 
> > > to select one from the list. Said that, the federation feature is still required for Kimchi.
> > > 
> > > So I have 3 proposals:
> > > 
> > > 1. Move federation feature to WOK
> > > The peers will continue to be displayed as part of the top header 
> > > but all code (backend/API) will be moved to Wok.
> > > 
> > > 2. Move federation feature to Ginger Base The Dashboard tab will 
> > > display a new section with the peers information when federation 
> > > is enabled.
> > > 
> > > 3. Keep federation feature on Kimchi and make Kimchi extend the 
> > > Ginger Base UI (the same way Ginger s390x does with Ginger tabs) 
> > > The Dashboard tab will be extended by Kimchi to display a new 
> > > section with the peers information when federation is enabled.
> > > 
> > Will the code (backend and frontend) completely located in kimchi? 
> > If so, this certainly the best option.
> 
> Yeap! All code would be on Kimchi.

So, go for it!

> 
> > However, user can be a little bit confuse, once he/she is enabling a 
> > kimchi feature but on frontend it will be located as a extension of ginger base code.
> > So, it should be interesting be located on Gingerbase (option 2).
> 
> Good point!
> 
> But I am not sure how much the user knows on where is each plugin.
>

Oh, I got the point: "these users that never know how to use the tool, only the developers!" :-P

> > > *I prefer the option 3* as it solves the original issue (having UI 
> > > code related to a Kimchi feature on Wok) and do not affect any 
> > > other plugin or Wok behavior.
> > > 
> > > Once we get an agreement on it, I will proper involve Ginger 
> > > community if needed.
> > > 
> > > What are you thoughts on it?
> > > 
> > > Regards,
> > > Aline Manera
> > > _______________________________________________
> > > Kimchi-devel mailing list
> > > Kimchi-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> > 
> 
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> 

--
Paulo Ricardo Paz Vital
Linux Technology Center, IBM Systems
http://www.ibm.com/linux/ltc/

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