Open Stack

Dmitry,

2014-11-29 1:01 GMT+04:00 Dmitry Borodaenko <dborodaenko at 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" <vkramskikh at 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 <eli at 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 <
>>> vkramskikh at mirantis.com> wrote:
>>>
>>>> Evgeniy,
>>>>
>>>> Responses inline:
>>>>
>>>> 2014-11-28 18:31 GMT+03:00 Evgeniy L <eli at 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 <
>>>>> vkramskikh at 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 at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at 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 at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Software Engineer,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141130/a055b40f/attachment.html>