Dmitry, 2014-11-29 1:01 GMT+04:00 Dmitry Borodaenko <dborodae...@mirantis.com>:
> Vitaly, > > It's there a document or spec or a wiki page that describes the current > status of this discussion in the context of the whole pluggable > architecture design? > There is a spec for the current implementation <https://github.com/stackforge/fuel-specs/blob/master/specs/6.0/cinder-neutron-plugins-in-fuel.rst>. Here I'm trying to propose changes which allow to turn more complex things like Ceph and vCenter into plugins. That's it. > Jumping into this thread without having the whole picture is hard. Knowing > what is already agreed, what is implemented so far, and having a structured > summary of points of disagreement with pro and contra arguments would help > a lot. > Well, there is a problem with "pro and contra arguments" because currently the discussion looks like "Your proposal is wrong and complicated and stuff, but I still don't have my own proposal". So I think it could be a better idea to wait for proposal from Evgeniy and then we'll be able to make a list of pro and contra arguments. > On Nov 28, 2014 9:48 AM, "Vitaly Kramskikh" <vkramsk...@mirantis.com> > wrote: > >> 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 >> >> > _______________________________________________ > 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
