<div dir="ltr">+1 to Evgeniy<div><br></div><div>There should be no type of restrictions that cannot be overriden by user.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 5:37 PM, Vitaly Kramskikh <span dir="ltr"><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><br>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.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">2015-11-02 16:16 GMT+07:00 Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>The main reason why I think we should get all of the three states is we</div><div>don't know exactly if those plugins (which developer didn't specify) are</div><div>compatible or not, so we should not make any assumptions and prevent</div><div>the user from enabling any plugins she/he wants. The best we can do here</div><div>is to provide all of the information plugin developer knows, directly to the user,</div><div>without us in the middle who make decisions based on incomplete data.</div><div><br></div><div>So lets ask plugin developer to specify a set of components which he tested</div><div>his plugin with. Plus a list of components which he tested with and he is sure</div><div>that those are not going to working together.</div><div><br></div><div>On UI we can show explicitly, that this combination is tested and approved to</div><div>be working, another combination is not working for sure (plugin developers tested</div><div>it and explicitly specified), and there will be a lot of combination which are going</div><div>to work together without problems, but we should say the user, that the developer</div><div>didn't test it and he should test and use it carefully.</div><div><br></div><div>Thanks,</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych <span dir="ltr"><<a href="mailto:apopovych@mirantis.com" target="_blank">apopovych@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi fuelers,<br>
<br>
Currently we are working on feature component registry [1] which should<br>
help us to prevent not logical compositions of different components in<br>
wizard tab during cluster(environment) creation. Now we have a mechanizm<br>
of 'restrictions' which is not flexible for components provided by<br>
plugins. In our current approach we have two states for components -<br>
compatible/incompatible which are described in compatibility matrix<br>
based on OpenStack components (For example: cinder-vmware storage only<br>
compatible with vCetner hypervisor and should work when only KVM uses).<br>
In this case we allow user to choose only that components we defently<br>
know works well with each other. Another approach tell us to have 3<br>
states: compatible/incompatible/ and all other components about<br>
compatibility with others we know nothing. In that case we should show<br>
on wizard which components compatible, which not, and others which user<br>
can enable on his own risk. So I need your opinions: should we allow for<br>
user choose only that coponents which are tested and defently works or<br>
prevent her/him from choosing which are defently not works and means<br>
potentional risk of failing deployment when component about we know<br>
nothing isn't work together.<br>
<br>
<br>
<br>
[1] <a href="https://blueprints.launchpad.net/fuel/+spec/component-registry" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/component-registry</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr">Vitaly Kramskikh,<br>Fuel UI Tech Lead,<br>Mirantis, Inc.</div></div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>