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
