Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all they should do is installing a package and modify a couple of config files (run a shell command). These ones have nothing to do with UI or any checkboxes, aren't they? 08 Окт 2014 г. 12:49 пользователь "Vitaly Kramskikh" < vkramsk...@mirantis.com> написал:
> Nikolay, > > Currently every thing that can be turned into a plugin (Ceph, vCenter, > Sahara, Murano, Ceilometer) provides a checkbox (or more complicated > controls) for the settings tab. Why change this approach for plugins? The > settings tab (cluster attributes) currently is a SSOT > <http://en.wikipedia.org/wiki/Single_Source_of_Truth>, and you want to > ruin it for no reason. > > Of course it makes no sense to generate anything. Checkboxes on the > settings tab can be added using simple YAML mixin and if you want to check > this checkbox to determine whether to perform some action or not and don't > want to write any python code, try to add to plugin's YAML "restrictions" > section which we already have for the settings tab, the wizard and roles. > > 2014-10-08 14:50 GMT+07:00 Nikolay Markov <nmar...@mirantis.com>: > >> >>> Right now we already have like 2 types of plugins (extensions), >> classified by usage of settings tab: >> >>> 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), >> or hypervisor (lvm/qemu/vmware) >> >>> 2. Self-contained service that just needs to be installed (sahara, >> murano, zabbix) >> >> That's not quite right. In 6.0 and after that there will be a lot of >> small plugins which only modify some config and/or install some >> package. There is nothing to configure here, and I as a plugin >> developer don't even want to know anything about checkboxes on UI. I >> just want two things: role to execute my command on and command >> itself. That's one small YAML. >> >> And autogenerating checkboxes for such plugins on UI is bad, because >> explicit is better than implicit (and all our settings are explicitly >> defined in openstack.yaml). >> >> On Wed, Oct 8, 2014 at 11:43 AM, Dmitriy Shulyak <dshul...@mirantis.com> >> wrote: >> > If there is no checkboxes (read configuration) and plugin is installed >> - all >> > deployment tasks will be applied >> > to every environment, but why do you think that there will be no >> checkboxes >> > in most cases? >> > >> > Right now we already have like 2 types of plugins (extensions), >> classified >> > by usage of settings tab: >> > 1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or >> > hypervisor (lvm/qemu/vmware) >> > 2. Self-contained service that just needs to be installed (sahara, >> murano, >> > zabbix) >> > >> > In 1st case you need to provide shared configuration storage (like >> cluster >> > attributes right now), in order for plugin >> > to be able to exclude part of core workflow from running (not installing >> > swift for example). >> > In case if the plugin is self-contained entity, like Sahara, Murano >> right >> > now - checkboxes would be simply required. >> > It works this way right now, and it doesnot look like huge overhead. >> > >> > So what do you think, will it work or no? >> > >> > On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov <nmar...@mirantis.com> >> wrote: >> >> >> >> Hi, >> >> >> >> Frankly speaking, I'm not sure on how 1st approach will even work. >> >> What if plugin doesn't provide any checkboxes (and in most cases it >> >> won't)? How should we determine in serializer, which plugins should be >> >> applied while generating astute.yaml and tasks.yaml? Should we >> >> autogenerate some stuff for plugins which are not even enabled and do >> >> needless work? >> >> >> >> This looks too complicated for me from the backend side, and option >> >> with enabling/disabling plugins in wizard for specific environment (we >> >> can invent mechanism to disable them on env which is not deployed yet, >> >> besides, for API it's just one PUT) is MUCH simpler and much more >> >> obvious, as I see. >> >> >> >> >> >> >> >> On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh >> >> <vkramsk...@mirantis.com> wrote: >> >> > Hi, >> >> > >> >> > I would go with the 1st approach. The thing I don't like in the 2nd >> >> > approach >> >> > is that we have to make the user enable plugin twice. For example, we >> >> > have >> >> > to enable Ceph as a plugin and then add Ceph role to nodes and choose >> >> > what >> >> > we want to store in Ceph (images, objects). Why we would need to >> >> > explicitly >> >> > enable Ceph plugin? Let's always show plugin options in wizard and >> >> > settings >> >> > tab, and if the user just doesn't want to enable Ceph, he would just >> >> > leave >> >> > all the checkboxes unchecked. The 2nd approach would also lead to >> some >> >> > kind >> >> > of inconsistency in case the user enabled Ceph plugin but left all >> the >> >> > Ceph-related checkboxes unchecked and didn't add Ceph nodes. >> >> > >> >> > 2014-10-07 21:17 GMT+07:00 Evgeniy L <e...@mirantis.com>: >> >> >> >> >> >> Hi, >> >> >> >> >> >> We had a meeting today about plugins on UI, as result of the meeting >> >> >> we have two approaches and this approaches affect not only UX but >> >> >> plugins itself. >> >> >> >> >> >> 1st - disable/enable plugin on settings tab >> >> >> >> >> >> user installs the plugin >> >> >> creates a cluster >> >> >> configures and enables/disables plugins on settings tab >> >> >> >> >> >> For user it will look like Ceph plugin checkboxes on settings tab, >> >> >> if he enables checkbox, then we pass the parameter to orchestrator >> >> >> as `true`. >> >> >> >> >> >> Cons: >> >> >> >> >> >> plugin developer should define a checkbox in each plugin (for plugin >> >> >> disabling/enabling) >> >> >> on the backend we have to enable all of the plugins for environment, >> >> >> because user can define any name for his checkbox and we won't be >> able >> >> >> to >> >> >> find it and make appropriate mapping plugin <-> env >> >> >> since all of the plugins are always "enabled" we have to run tasks >> for >> >> >> all >> >> >> of the plugins, and each plugin should parse astute.yaml in order to >> >> >> figure >> >> >> out if it's required to run task current script >> >> >> >> >> >> Pros: >> >> >> >> >> >> it won't require additional setting or step for wizard >> >> >> user will be able to disable plugin after environment creation >> >> >> >> >> >> 2nd - enable plugins in wizard >> >> >> >> >> >> user installs the plugin >> >> >> now he can choose specific plugins for his environment in wizard >> >> >> after cluster is created, he can configure additional parameters on >> >> >> settings tab, if plugin provides any >> >> >> >> >> >> Cons: >> >> >> >> >> >> user won't be able to disable plugin after cluster is created >> >> >> additional step or configuration subcategory in wizard >> >> >> >> >> >> Pros: >> >> >> >> >> >> On backend we always know which plugin is disabled and which is >> >> >> enabled. >> >> >> >> >> >> it means we don't provide settings for plugins which are disabled >> >> >> we don't run tasks on slaves if it's not required >> >> >> >> >> >> Thanks, >> >> >> >> >> >> _______________________________________________ >> >> >> OpenStack-dev mailing list >> >> >> OpenStack-dev@lists.openstack.org >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Vitaly Kramskikh, >> >> > Software Engineer, >> >> > Mirantis, Inc. >> >> > >> >> > _______________________________________________ >> >> > OpenStack-dev mailing list >> >> > OpenStack-dev@lists.openstack.org >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Nick Markov >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> >> -- >> Best regards, >> Nick Markov >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Vitaly Kramskikh, > Software Engineer, > Mirantis, Inc. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
