Open Stack

+1 to Evgeniy

There should be no type of restrictions that cannot be overriden by user.

On Mon, Nov 2, 2015 at 5:37 PM, Vitaly Kramskikh <vkramskikh at mirantis.com>
wrote:

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


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151102/8fe7b92b/attachment.html>