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

2015-11-02 Thread Vladimir Kuklin 
+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 
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 :
>
>> 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 
>> 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-requ...@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-requ...@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-requ...@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 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2015-11-02 Thread Vitaly Kramskikh 
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 :

> 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 
> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2015-11-02 Thread Sheena Gregson 
This seems like a reasonable approach.  As mentioned earlier in the thread,
our current framework allows plugins to declare which components they could
not work with, so we already have information about “incompatibility” for a
number of plugins.  The issue with this approach is that, as new plugins
are added to an existing release, the previously published plugins cannot
show that they are either (1) incompatible or (2) untested.



The proposed approach solves this problem.  Adding compatibility gives more
clarity to the users about known good combinations, and creating a gray
area for untested component combinations helps expose areas where we
haven’t done thorough testing and there may be issues, and users should
proceed with guidance/support.



*From:* Vitaly Kramskikh [mailto:vkramsk...@mirantis.com]
*Sent:* Monday, November 02, 2015 8:38 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins][UX] Component registry



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 <e...@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 <apopov...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2015-11-02 Thread Evgeniy L 
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 
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev