From alinefm at linux.vnet.ibm.com Thu Jul 21 14:16:05 2016 Content-Type: multipart/mixed; boundary="===============2392035122777743184==" MIME-Version: 1.0 From: Aline Manera To: kimchi-devel at ovirt.org Subject: Re: [Kimchi-devel] Changing the way federation feature (peers) is exposed to user Date: Thu, 21 Jul 2016 15:15:58 -0300 Message-ID: <975822e7-025c-2108-97dc-5571ac987931@linux.vnet.ibm.com> In-Reply-To: e6f0ced931be42ea8c3be56da5c41241@serv031.corp.eldorado.org.br --===============2392035122777743184== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 07/21/2016 03:12 PM, Samuel Henrique De Oliveira Guimaraes wrote: > I'm not sure if I'm following this right. Will the Dashboard tab appear o= n Kimchi or will it display a new panel-group with the peers list by adding= the following lines to Gingerbase? > > > ... > #for $script in $data.scripts > > #end for > > > What if the user only has Kimchi installed and not Gingerbase? Ginger Base is required by Kimchi, ie, Ginger Base is a Kimchi dependency. > Samuel > > > -----Original Message----- > From: Aline Manera [mailto:alinefm(a)linux.vnet.ibm.com] > Sent: quarta-feira, 20 de julho de 2016 10:56 > To: Samuel Henrique De Oliveira Guimaraes ; kimchi-devel(a)ovirt.org > Subject: Re: [Kimchi-devel] Changing the way federation feature (peers) i= s exposed to user > > > > On 07/19/2016 04:22 PM, Samuel Henrique De Oliveira Guimaraes wrote: >> Hi, >> >> So we are going with option 3, right? How can we extend Kimchi in Ginger= base or vice-versa to enable federation? >> >> Samuel > Hi Samuel. > > There is a detailed explanation at > https://github.com/kimchi-project/ginger/issues/317#issuecomment-210554662 > > Let me know if you need my help on anything else. > > Regards, > Aline Manera > >> -----Original Message----- >> From: kimchi-devel-bounces(a)ovirt.org >> [mailto:kimchi-devel-bounces(a)ovirt.org] On Behalf Of Paulo Ricardo Paz >> Vital >> Sent: ter=C3=A7a-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 gi= nger 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 >> --===============2392035122777743184==--