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

*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

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

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

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 the following lines to Gingerbase? <head> ... #for $script in $data.scripts <script type="text/javascript" src="$script"></script> #end for </head> What if the user only has Kimchi installed and not Gingerbase?

Samuel -----Original Message----- From: Aline Manera [mailto:alinefm@linux.vnet.ibm.com] Sent: quarta-feira, 20 de julho de 2016 10:56 To: Samuel Henrique De Oliveira Guimaraes <samuel.guimaraes(a)eldorado.org.br>; 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 Gingerbase 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@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 >

On 04-07-2016 12:27, 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-federati... > > > 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. How will Kimchi detect other servers?

If it's through wokd running and checking if Kimchi is installed, perhaps we should consider to have such feature in Wok (option 1) in a more generic way, in order future plugins can take advantage of it: i.e. detect_peers ('name') would return the wok peers with plugin 'name' installed.

I'm fine with option 3 too. > > *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 >