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

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.

> 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.

> > *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(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/kimchi-devel > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel