Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141128/2ba3be5f/attachment.html>