Folks, Please participate in this discussion. We already have a few meetings on this topic and there is still no decision. I understand entry level is pretty high, but please find some time for this.
Evgeniy, Responses inline: 2014-11-28 20:03 GMT+03:00 Evgeniy L <e...@mirantis.com>: > >> Yes, but is already used in a few places. I want to notice once again > - even a simple LBaaS plugin with a single checkbox needed to utilize this > functionality. > > Yes, but you don't need to specify it in each task. > Just by adding conditions to tasks we will be able to pluginize all current functionality that can be pluginized. On the other hand, 1 line will be added to task definition and you are concerned about this that much that you want to create a separate interface for "complex" plugins. Am I right? > > >> So, you're still calling this interface complicated. Ok, I'm looking > forward to seeing your proposal about dealing with complex plugins. > > All my concerns were related to simple plugins and that we should > find a way not to force a plugin developer to do this copy-paste work. > I don't understand what copy-paste work you are talking about. Copying conditions from tasks to is_removable? Yes, it will be so in most cases, but not always, so we need to give a plugin writer a way to define is_removable manually. If you are talking about copypasting conditions between tasks (though I don't understand why we need a few tasks with the same conditions), YAML links can be used - we use them a lot in openstack.yaml. > > >> If you have several checkboxes, then it is a complex plugin with > complex configuration ... > > Here we need a definition of s simple plugins, in the current > release with simple plugins you can define some fields on the UI (not a > single checkbox) and run several tasks if plugin is enabled. > Ok, we can define simple plugin as a plugin which doesn't require modification of generated YAML files at all. But with proposed approach there is no need to somehow separate "simple" and "complex" plugins. > > Thanks, > >> > On Fri, Nov 28, 2014 at 7:01 PM, Vitaly Kramskikh <vkramsk...@mirantis.com > > wrote: > >> Evgeniy, >> >> Responses inline: >> >> 2014-11-28 18:31 GMT+03:00 Evgeniy L <e...@mirantis.com>: >> >>> Hi Vitaly, >>> >>> I agree with you that conditions can be useful in case of complicated >>> plugins, but >>> at the same time in case of simple cases it adds a huge amount of >>> complexity. >>> I would like to avoid forcing user to know about any conditions if he >>> wants >>> to add several text fields on the UI. >>> >>> I have several reasons why we shouldn't do that: >>> 1. conditions are described with yet another language with it's own >>> syntax >>> >> Yes, but is already used in a few places. I want to notice once again - >> even a simple LBaaS plugin with a single checkbox needed to utilize this >> functionality. >> >>> 2. the language is not documented (solvable) >>> >> It is documented: >> http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#expression-syntax >> >>> 3. complicated interface will lead to a lot of bugs for the end user, >>> and it will be >>> a Fuel team's problem >>> >> So, you're still calling this interface complicated. Ok, I'm looking >> forward to seeing your proposal about dealing with complex plugins. >> >>> 4. in case of several checkboxes you'll have to write a huge conditions >>> with >>> a lot of "and" statements and it'll be really easy to forget about >>> some of them >>> >> If you have several checkboxes, then it is a complex plugin with complex >> configuration, so I see no problem here. There will be many more places >> where you can "forget" stuff. >> >>> >>> As result in simple cases plugin developer will have to specify the same >>> condition of every task in tasks.yaml file, add it to metadata.yaml. >>> If you add new checkbox, you should go through all of this files, >>> add "and lbaas:new_checkbox_name" statement. >>> >> Once again, in simple cases checkbox and the conditions (one for task and >> one for is_removable) can be easily pregenerated by FPB, so plugin >> developer has to do nothing more. If you add a new checkbox which doesn't >> affect plugin removeability and tasks, you have to change nothing in plugin >> metadata. >> >>> >>> Thanks, >>> >>> On Thu, Nov 27, 2014 at 7:57 PM, Vitaly Kramskikh < >>> vkramsk...@mirantis.com> wrote: >>> >>>> Folks, >>>> >>>> In the 6.0 release we'll support simple plugins for Fuel. The current >>>> architecture allows to create only very simple plugins and doesn't allow to >>>> "pluginize" complex features like Ceph, vCenter, etc. I'd like to propose >>>> some changes to make it possible. They are subtle enough and the plugin >>>> template still can be autogenerated by Fuel Plugin Builder. Here they are: >>>> >>>> >>>> https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf >>>> >>>> 1. environment_config.yaml should contain exact config which will >>>> be mixed into cluster_attributes. No need to implicitly generate any >>>> controls like it is done now. >>>> 2. metadata.yaml should also contain "is_removable" field. This >>>> field is needed to determine whether it is possible to remove installed >>>> plugin. It is impossible to remove plugins in the current >>>> implementation. >>>> This field should contain an expression written in our DSL which we >>>> already >>>> use in a few places. The LBaaS plugin also uses it to hide the checkbox >>>> if >>>> Neutron is not used, so even simple plugins like this need to utilize >>>> it. >>>> This field can also be autogenerated, for more complex plugins plugin >>>> writer needs to fix it manually. For example, for Ceph it could look >>>> like >>>> "settings:storage.volumes_ceph.value == false and >>>> settings:storage.images_ceph.value == false". >>>> 3. For every task in tasks.yaml there should be added new >>>> "condition" field with an expression which determines whether the task >>>> should be run. In the current implementation tasks are always run for >>>> specified roles. For example, vCenter plugin can have a few tasks with >>>> conditions like "settings:common.libvirt_type.value == 'vcenter'" or >>>> "settings:storage.volumes_vmdk.value == true". Also, AFAIU, similar >>>> approach will be used in implementation of Granular Deployment feature. >>>> >>>> These simple changes will allow to write much more complex plugins. >>>> What do you think? >>>> -- >>>> 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 >> >> > > _______________________________________________ > 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