Open Stack

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