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
