Open Stack

>> 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.

>> 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.

>> 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.

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