So they should be implemented like Murano or Sahara and provide a checkbox in "Additional Services" section of the settings tab and the wizard
2014-10-08 19:57 GMT+07:00 Nikolay Markov <nmar...@mirantis.com>: > 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 > > -- 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
