[Kimchi-devel] Changing the way federation feature (peers) is exposed to user

[Aline Manera]

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

> 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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>