6:27 p.m.
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
6:37 p.m.
New subject: Changing the way federation feature (peers) is exposed to user
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(a)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(a)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-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
7:37 p.m.
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-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
8:16 p.m.
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.
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(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/
11:31 p.m.
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
4:38 p.m.
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-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.
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/
10:22 p.m.
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
4:55 p.m.
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
9:12 p.m.
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
9:15 p.m.
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(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
>
8:36 p.m.
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
--
Lucio Correia
Software Engineer
IBM LTC Brazil
11:34 p.m.
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-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?
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
3047
days inactive
3064
days old
11 comments
5 participants
participants (5)
-
Aline Manera -
Daniel Henrique Barboza -
Lucio Correia -
Paulo Ricardo Paz Vital -
Samuel Henrique De Oliveira Guimaraes