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

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(a)ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Paulo Ricardo Paz Vital Sent: terça-feira, 5 de julho de 2016 10:38 To: kimchi-devel(a)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(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 > -- Paulo Ricardo Paz Vital Linux Technology Center, IBM Systems http://www.ibm.com/linux/ltc/ _______________________________________________ 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