+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 <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> >> 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?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: [email protected]?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 [email protected]
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
