Changing the way federation feature (peers) is exposed to user
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-federation.... 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
I agree with option 3. Once I finish the tasks I’m allocated with I’ll draw some mockups for Ginger sidebar proposal that involves some minor changes in Wok navbar and main content area on HD screen resolutions and I think the navbar won’t have enough space to hold the menu items, the user actions and help button. Samuel From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Aline Manera Sent: segunda-feira, 4 de julho de 2016 12:27 To: Kimchi Devel <kimchi-devel@ovirt.org> Subject: [Kimchi-devel] Changing the way federation feature (peers) is exposed to user 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-federation.... 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
I agree with option 3 considering that the idea here is to solve this "Kimchi feature being coded in WoK" problem and this is easier than moving everything to WoK. Daniel On 07/04/2016 12:27 PM, 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-federation....
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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-federation....
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. 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).
*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@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/
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-federation....
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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-federation....
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@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/
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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel@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@eldorado.org.br>; kimchi-devel@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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 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?
Ginger Base is required by Kimchi, ie, Ginger Base is a Kimchi dependency.
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@eldorado.org.br>; kimchi-devel@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list Kimchi-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel@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-federation....
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Lucio Correia Software Engineer IBM LTC Brazil
On 07/04/2016 02:36 PM, Lucio Correia wrote:
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-federation....
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?
We use openSLP and register a service there. Today we are registering 'service:wokd' but I agree it should be changed to 'service:kimchid' if it is only a Kimchi feature.
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.
My doubt now is how others plugins may take advanced on it. Seems a useful feature only for Kimchi.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (5)
-
Aline Manera -
Daniel Henrique Barboza -
Lucio Correia -
Paulo Ricardo Paz Vital -
Samuel Henrique De Oliveira Guimaraes