[openstack-dev] [Fuel][Plugins][UX] Component registry

Vitaly Kramskikh vkramskikh at mirantis.com
Mon Nov 2 14:37:31 UTC 2015


Hi,

I think having both compatibility and incompatibility lists is a good idea.
I think we need just to show a warning if users pick options which are not
in compatibility list and disable options which are in incompatibility
list. We also need to be able to provide a message in case of
incompatibility: the current implementation of the wizard supports custom
messages in the wizard config and they are quite useful.

2015-11-02 16:16 GMT+07:00 Evgeniy L <eli at mirantis.com>:

> Hi,
>
> The main reason why I think we should get all of the three states is we
> don't know exactly if those plugins (which developer didn't specify) are
> compatible or not, so we should not make any assumptions and prevent
> the user from enabling any plugins she/he wants. The best we can do here
> is to provide all of the information plugin developer knows, directly to
> the user,
> without us in the middle who make decisions based on incomplete data.
>
> So lets ask plugin developer to specify a set of components which he tested
> his plugin with. Plus a list of components which he tested with and he is
> sure
> that those are not going to working together.
>
> On UI we can show explicitly, that this combination is tested and approved
> to
> be working, another combination is not working for sure (plugin developers
> tested
> it and explicitly specified), and there will be a lot of combination which
> are going
> to work together without problems, but we should say the user, that the
> developer
> didn't test it and he should test and use it carefully.
>
> Thanks,
>
> On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych <apopovych at mirantis.com>
> wrote:
>
>> Hi fuelers,
>>
>> Currently we are working on feature component registry [1] which should
>> help us to prevent not logical compositions of different components in
>> wizard tab during cluster(environment) creation. Now we have a mechanizm
>> of 'restrictions' which is not flexible for components provided by
>> plugins. In our current approach we have two states for components -
>> compatible/incompatible which are described in compatibility matrix
>> based on OpenStack components (For example: cinder-vmware storage only
>> compatible with vCetner hypervisor and should work when only KVM uses).
>> In this case we allow user to choose only that components we defently
>> know works well with each other. Another approach tell us to have 3
>> states: compatible/incompatible/ and all other components about
>> compatibility with others we know nothing. In that case we should show
>> on wizard which components compatible, which not, and others which user
>> can enable on his own risk. So I need your opinions: should we allow for
>> user choose only that coponents which are tested and defently works or
>> prevent her/him from choosing which are defently not works and means
>> potentional risk of failing deployment when component about we know
>> nothing isn't work together.
>>
>>
>>
>> [1] https://blueprints.launchpad.net/fuel/+spec/component-registry
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151102/2930214e/attachment.html>


More information about the OpenStack-dev mailing list