From samuel.guimaraes at eldorado.org.br Thu Jul 21 14:12:19 2016 Content-Type: multipart/mixed; boundary="===============5976226636961326415==" MIME-Version: 1.0 From: Samuel Henrique De Oliveira Guimaraes 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 18:12:13 +0000 Message-ID: In-Reply-To: 1144ebe7-4fb1-c386-5c9c-40bfe4d92f0a@linux.vnet.ibm.com --===============5976226636961326415== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I'm not sure if I'm following this right. Will the Dashboard tab appear on = Kimchi or will it display a new panel-group with the peers list by adding t= he following lines to Gingerbase? = = ... #for $script in $data.scripts #end for What if the user only has Kimchi installed and not Gingerbase? 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) is = 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 Gingerb= ase 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 r= equired 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 gin= ger 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 > --===============5976226636961326415==--