Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

As I said, it is not flexible and restrictive. What if there are some other
"backends" for anything appear? What to do if I want to write a plugin that
just adds some extra styles to the UI? Invent a new structures/flags on
demand? That's not viable.

I still think "enableness" of plugin is the root of all issues with your
approach. With your approach we lose single source of truth (cluster
attributes/settings tab) we'll need to search for strange solutions like
these groups/flags.

2014-12-17 12:33 GMT+01:00 Evgeniy L :
>
> Vitaly, what do you think about that?
>
> On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L  wrote:
>>
>> Hi,
>>
>> I don't agree with many of your statements but, I would like to
>> continue discussion about really important topic i.e. UI flow, my
>> suggestion was to add groups, for plugin in metadata.yaml plugin
>> developer can have description of the groups which it belongs to:
>>
>> groups:
>>   - id: storage
>> subgroup:
>>   - id: cinder
>>
>> With this information we can show a new option on UI (wizard),
>> if option is selected, it means that plugin is enabled, if plugin belongs
>> to several groups, we can use OR statement.
>>
>> The main point is, for environment creation we must specify
>> ids of plugins. Yet another reason for that is plugins multiversioning,
>> we must know exactly which plugin with which version
>> is used for environment, and I don't see how "conditions" can help
>> us with it.
>>
>> Thanks,
>>
>>>


>> On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>>
>>>
>>>
>>> 2014-12-10 19:31 GMT+03:00 Evgeniy L :
>>>


 On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh <
 vkramsk...@mirantis.com> wrote:

>
>
> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>
>> Hi,
>>
>> First let me describe what our plans for the nearest release. We want
>> to deliver
>> role as a simple plugin, it means that plugin developer can define
>> his own role
>> with yaml and also it should work fine with our current approach when
>> user can
>> define several fields on the settings tab.
>>
>> Also I would like to mention another thing which we should probably
>> discuss
>> in separate thread, how plugins should be implemented. We have two
>> types
>> of plugins, simple and complicated, the definition of simple - I can
>> do everything
>> I need with yaml, the definition of complicated - probably I have to
>> write some
>> python code. It doesn't mean that this python code should do
>> absolutely
>> everything it wants, but it means we should implement stable,
>> documented
>> interface where plugin is connected to the core.
>>
>> Now lets talk about UI flow, our current problem is how to get the
>> information
>> if plugins is used in the environment or not, this information is
>> required for
>> backend which generates appropriate tasks for task executor, also this
>> information can be used in the future if we decide to implement
>> plugins deletion
>> mechanism.
>>
>> I didn't come up with a some new solution, as before we have two
>> options to
>> solve the problem:
>>
>> # 1
>>
>> Use conditional language which is currently used on UI, it will look
>> like
>> Vitaly described in the example [1].
>> Plugin developer should:
>>
>> 1. describe at least one element for UI, which he will be able to use
>> in task
>>
>> 2. add condition which is written in our own programming language
>>
>> Example of the condition for LBaaS plugin:
>>
>> condition: settings:lbaas.metadata.enabled == true
>>
>> 3. add condition to metadata.yaml a condition which defines if plugin
>> is enabled
>>
>> is_enabled: settings:lbaas.metadata.enabled == true
>>
>> This approach has good flexibility, but also it has problems:
>>
>> a. It's complicated and not intuitive for plugin developer.
>>
> It is less complicated than python code
>

 I'm not sure why are you talking about python code here, my point
 is we should not force developer to use this conditions in any language.

 But that's how current plugin-like stuff works. There are various tasks
>>> which are run only if some checkboxes are set, so stuff like Ceph and
>>> vCenter will need conditions to describe tasks.
>>>
 Anyway I don't agree with the statement there are more people who know
 python than "fuel ui conditional language".


> b. It doesn't cover case when the user installs 3rd party plugin
>> which doesn't have any conditions (because of # a) and
>> user doesn't have a way to disable it for environment if it
>> breaks his configuration.
>>
> If plugin doesn't have conditions for tasks, then it has invalid
> metadata.
>

>>>

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Vitaly, what do you think about that?

On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L  wrote:
>
> Hi,
>
> I don't agree with many of your statements but, I would like to
> continue discussion about really important topic i.e. UI flow, my
> suggestion was to add groups, for plugin in metadata.yaml plugin
> developer can have description of the groups which it belongs to:
>
> groups:
>   - id: storage
> subgroup:
>   - id: cinder
>
> With this information we can show a new option on UI (wizard),
> if option is selected, it means that plugin is enabled, if plugin belongs
> to several groups, we can use OR statement.
>
> The main point is, for environment creation we must specify
> ids of plugins. Yet another reason for that is plugins multiversioning,
> we must know exactly which plugin with which version
> is used for environment, and I don't see how "conditions" can help
> us with it.
>
> Thanks,
>
>>
>>>
>>>
> On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh  > wrote:
>>
>>
>>
>> 2014-12-10 19:31 GMT+03:00 Evgeniy L :
>>
>>>
>>>
>>> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh <
>>> vkramsk...@mirantis.com> wrote:
>>>


 2014-12-10 16:57 GMT+03:00 Evgeniy L :

> Hi,
>
> First let me describe what our plans for the nearest release. We want
> to deliver
> role as a simple plugin, it means that plugin developer can define his
> own role
> with yaml and also it should work fine with our current approach when
> user can
> define several fields on the settings tab.
>
> Also I would like to mention another thing which we should probably
> discuss
> in separate thread, how plugins should be implemented. We have two
> types
> of plugins, simple and complicated, the definition of simple - I can
> do everything
> I need with yaml, the definition of complicated - probably I have to
> write some
> python code. It doesn't mean that this python code should do absolutely
> everything it wants, but it means we should implement stable,
> documented
> interface where plugin is connected to the core.
>
> Now lets talk about UI flow, our current problem is how to get the
> information
> if plugins is used in the environment or not, this information is
> required for
> backend which generates appropriate tasks for task executor, also this
> information can be used in the future if we decide to implement
> plugins deletion
> mechanism.
>
> I didn't come up with a some new solution, as before we have two
> options to
> solve the problem:
>
> # 1
>
> Use conditional language which is currently used on UI, it will look
> like
> Vitaly described in the example [1].
> Plugin developer should:
>
> 1. describe at least one element for UI, which he will be able to use
> in task
>
> 2. add condition which is written in our own programming language
>
> Example of the condition for LBaaS plugin:
>
> condition: settings:lbaas.metadata.enabled == true
>
> 3. add condition to metadata.yaml a condition which defines if plugin
> is enabled
>
> is_enabled: settings:lbaas.metadata.enabled == true
>
> This approach has good flexibility, but also it has problems:
>
> a. It's complicated and not intuitive for plugin developer.
>
 It is less complicated than python code

>>>
>>> I'm not sure why are you talking about python code here, my point
>>> is we should not force developer to use this conditions in any language.
>>>
>>> But that's how current plugin-like stuff works. There are various tasks
>> which are run only if some checkboxes are set, so stuff like Ceph and
>> vCenter will need conditions to describe tasks.
>>
>>> Anyway I don't agree with the statement there are more people who know
>>> python than "fuel ui conditional language".
>>>
>>>
 b. It doesn't cover case when the user installs 3rd party plugin
> which doesn't have any conditions (because of # a) and
> user doesn't have a way to disable it for environment if it
> breaks his configuration.
>
 If plugin doesn't have conditions for tasks, then it has invalid
 metadata.

>>>
>>> Yep, and it's a problem of the platform, which provides a bad interface.
>>>
>> Why is it bad? It plugin writer doesn't provide plugin name or version,
>> then metadata is invalid also. It is plugin writer's fault that he didn't
>> write metadata properly.
>>
>>>
>>>

> # 2
>
> As we discussed from the very beginning after user selects a release
> he can
> choose a set of plugins which he wants to be enabled for environment.
> After that we can say that plugin is enabled for the environment and
> we send
> tasks related to this plugin to task executor.
>
> >> My approach also allows to eliminate "enableness" of plugins which
> will cause 

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Hi,

I don't agree with many of your statements but, I would like to
continue discussion about really important topic i.e. UI flow, my
suggestion was to add groups, for plugin in metadata.yaml plugin
developer can have description of the groups which it belongs to:

groups:
  - id: storage
subgroup:
  - id: cinder

With this information we can show a new option on UI (wizard),
if option is selected, it means that plugin is enabled, if plugin belongs
to several groups, we can use OR statement.

The main point is, for environment creation we must specify
ids of plugins. Yet another reason for that is plugins multiversioning,
we must know exactly which plugin with which version
is used for environment, and I don't see how "conditions" can help
us with it.

Thanks,

>
>>
>>
On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh 
wrote:
>
>
>
> 2014-12-10 19:31 GMT+03:00 Evgeniy L :
>
>>
>>
>> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>
>>>
>>>
>>> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>>>
 Hi,

 First let me describe what our plans for the nearest release. We want
 to deliver
 role as a simple plugin, it means that plugin developer can define his
 own role
 with yaml and also it should work fine with our current approach when
 user can
 define several fields on the settings tab.

 Also I would like to mention another thing which we should probably
 discuss
 in separate thread, how plugins should be implemented. We have two types
 of plugins, simple and complicated, the definition of simple - I can do
 everything
 I need with yaml, the definition of complicated - probably I have to
 write some
 python code. It doesn't mean that this python code should do absolutely
 everything it wants, but it means we should implement stable, documented
 interface where plugin is connected to the core.

 Now lets talk about UI flow, our current problem is how to get the
 information
 if plugins is used in the environment or not, this information is
 required for
 backend which generates appropriate tasks for task executor, also this
 information can be used in the future if we decide to implement plugins
 deletion
 mechanism.

 I didn't come up with a some new solution, as before we have two
 options to
 solve the problem:

 # 1

 Use conditional language which is currently used on UI, it will look
 like
 Vitaly described in the example [1].
 Plugin developer should:

 1. describe at least one element for UI, which he will be able to use
 in task

 2. add condition which is written in our own programming language

 Example of the condition for LBaaS plugin:

 condition: settings:lbaas.metadata.enabled == true

 3. add condition to metadata.yaml a condition which defines if plugin
 is enabled

 is_enabled: settings:lbaas.metadata.enabled == true

 This approach has good flexibility, but also it has problems:

 a. It's complicated and not intuitive for plugin developer.

>>> It is less complicated than python code
>>>
>>
>> I'm not sure why are you talking about python code here, my point
>> is we should not force developer to use this conditions in any language.
>>
>> But that's how current plugin-like stuff works. There are various tasks
> which are run only if some checkboxes are set, so stuff like Ceph and
> vCenter will need conditions to describe tasks.
>
>> Anyway I don't agree with the statement there are more people who know
>> python than "fuel ui conditional language".
>>
>>
>>> b. It doesn't cover case when the user installs 3rd party plugin
 which doesn't have any conditions (because of # a) and
 user doesn't have a way to disable it for environment if it
 breaks his configuration.

>>> If plugin doesn't have conditions for tasks, then it has invalid
>>> metadata.
>>>
>>
>> Yep, and it's a problem of the platform, which provides a bad interface.
>>
> Why is it bad? It plugin writer doesn't provide plugin name or version,
> then metadata is invalid also. It is plugin writer's fault that he didn't
> write metadata properly.
>
>>
>>
>>>
 # 2

 As we discussed from the very beginning after user selects a release he
 can
 choose a set of plugins which he wants to be enabled for environment.
 After that we can say that plugin is enabled for the environment and we
 send
 tasks related to this plugin to task executor.

 >> My approach also allows to eliminate "enableness" of plugins which
 will cause UX issues and issues like you described above. vCenter and Ceph
 also don't have "enabled" state. vCenter has hypervisor and storage, Ceph
 provides backends for Cinder and Glance which can be used simultaneously or
 only one of them can be used.

 

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

2014-12-10 19:31 GMT+03:00 Evgeniy L :

>
>
> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh  > wrote:
>
>>
>>
>> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>>
>>> Hi,
>>>
>>> First let me describe what our plans for the nearest release. We want to
>>> deliver
>>> role as a simple plugin, it means that plugin developer can define his
>>> own role
>>> with yaml and also it should work fine with our current approach when
>>> user can
>>> define several fields on the settings tab.
>>>
>>> Also I would like to mention another thing which we should probably
>>> discuss
>>> in separate thread, how plugins should be implemented. We have two types
>>> of plugins, simple and complicated, the definition of simple - I can do
>>> everything
>>> I need with yaml, the definition of complicated - probably I have to
>>> write some
>>> python code. It doesn't mean that this python code should do absolutely
>>> everything it wants, but it means we should implement stable, documented
>>> interface where plugin is connected to the core.
>>>
>>> Now lets talk about UI flow, our current problem is how to get the
>>> information
>>> if plugins is used in the environment or not, this information is
>>> required for
>>> backend which generates appropriate tasks for task executor, also this
>>> information can be used in the future if we decide to implement plugins
>>> deletion
>>> mechanism.
>>>
>>> I didn't come up with a some new solution, as before we have two options
>>> to
>>> solve the problem:
>>>
>>> # 1
>>>
>>> Use conditional language which is currently used on UI, it will look like
>>> Vitaly described in the example [1].
>>> Plugin developer should:
>>>
>>> 1. describe at least one element for UI, which he will be able to use in
>>> task
>>>
>>> 2. add condition which is written in our own programming language
>>>
>>> Example of the condition for LBaaS plugin:
>>>
>>> condition: settings:lbaas.metadata.enabled == true
>>>
>>> 3. add condition to metadata.yaml a condition which defines if plugin is
>>> enabled
>>>
>>> is_enabled: settings:lbaas.metadata.enabled == true
>>>
>>> This approach has good flexibility, but also it has problems:
>>>
>>> a. It's complicated and not intuitive for plugin developer.
>>>
>> It is less complicated than python code
>>
>
> I'm not sure why are you talking about python code here, my point
> is we should not force developer to use this conditions in any language.
>
> But that's how current plugin-like stuff works. There are various tasks
which are run only if some checkboxes are set, so stuff like Ceph and
vCenter will need conditions to describe tasks.

> Anyway I don't agree with the statement there are more people who know
> python than "fuel ui conditional language".
>
>
>> b. It doesn't cover case when the user installs 3rd party plugin
>>> which doesn't have any conditions (because of # a) and
>>> user doesn't have a way to disable it for environment if it
>>> breaks his configuration.
>>>
>> If plugin doesn't have conditions for tasks, then it has invalid metadata.
>>
>
> Yep, and it's a problem of the platform, which provides a bad interface.
>
Why is it bad? It plugin writer doesn't provide plugin name or version,
then metadata is invalid also. It is plugin writer's fault that he didn't
write metadata properly.

>
>
>>
>>> # 2
>>>
>>> As we discussed from the very beginning after user selects a release he
>>> can
>>> choose a set of plugins which he wants to be enabled for environment.
>>> After that we can say that plugin is enabled for the environment and we
>>> send
>>> tasks related to this plugin to task executor.
>>>
>>> >> My approach also allows to eliminate "enableness" of plugins which
>>> will cause UX issues and issues like you described above. vCenter and Ceph
>>> also don't have "enabled" state. vCenter has hypervisor and storage, Ceph
>>> provides backends for Cinder and Glance which can be used simultaneously or
>>> only one of them can be used.
>>>
>>> Both of described plugins have enabled/disabled state, vCenter is enabled
>>> when vCenter is selected as hypervisor. Ceph is enabled when it's
>>> selected
>>> as a backend for Cinder or Glance.
>>>
>> Nope, Ceph for Volumes can be used without Ceph for Images. Both of these
>> plugins can also have some granular tasks which are enabled by various
>> checkboxes (like VMware vCenter for volumes). How would you determine
>> whether tasks which installs VMware vCenter for volumes should run?
>>
>
> Why "nope"? I have "Cinder OR Glance".
>
Oh, I missed it. So there are 2 checkboxes, how would you determine
"enableness"?

> It can be easily handled in deployment script.
>
I don't know much about the status of granular deployment blueprint, but
AFAIK that's what we are going to get rid of.

>
>
>>> If you don't like the idea of having Ceph/vCenter checkboxes on the
>>> first page,
>>> I can suggest as an idea (research is required) to define groups like
>>> Storage Backend,
>>> Network Manager and we

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh 
wrote:

>
>
> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>
>> Hi,
>>
>> First let me describe what our plans for the nearest release. We want to
>> deliver
>> role as a simple plugin, it means that plugin developer can define his
>> own role
>> with yaml and also it should work fine with our current approach when
>> user can
>> define several fields on the settings tab.
>>
>> Also I would like to mention another thing which we should probably
>> discuss
>> in separate thread, how plugins should be implemented. We have two types
>> of plugins, simple and complicated, the definition of simple - I can do
>> everything
>> I need with yaml, the definition of complicated - probably I have to
>> write some
>> python code. It doesn't mean that this python code should do absolutely
>> everything it wants, but it means we should implement stable, documented
>> interface where plugin is connected to the core.
>>
>> Now lets talk about UI flow, our current problem is how to get the
>> information
>> if plugins is used in the environment or not, this information is
>> required for
>> backend which generates appropriate tasks for task executor, also this
>> information can be used in the future if we decide to implement plugins
>> deletion
>> mechanism.
>>
>> I didn't come up with a some new solution, as before we have two options
>> to
>> solve the problem:
>>
>> # 1
>>
>> Use conditional language which is currently used on UI, it will look like
>> Vitaly described in the example [1].
>> Plugin developer should:
>>
>> 1. describe at least one element for UI, which he will be able to use in
>> task
>>
>> 2. add condition which is written in our own programming language
>>
>> Example of the condition for LBaaS plugin:
>>
>> condition: settings:lbaas.metadata.enabled == true
>>
>> 3. add condition to metadata.yaml a condition which defines if plugin is
>> enabled
>>
>> is_enabled: settings:lbaas.metadata.enabled == true
>>
>> This approach has good flexibility, but also it has problems:
>>
>> a. It's complicated and not intuitive for plugin developer.
>>
> It is less complicated than python code
>

I'm not sure why are you talking about python code here, my point
is we should not force developer to use this conditions in any language.

Anyway I don't agree with the statement there are more people who know
python than "fuel ui conditional language".


> b. It doesn't cover case when the user installs 3rd party plugin
>> which doesn't have any conditions (because of # a) and
>> user doesn't have a way to disable it for environment if it
>> breaks his configuration.
>>
> If plugin doesn't have conditions for tasks, then it has invalid metadata.
>

Yep, and it's a problem of the platform, which provides a bad interface.


>
>> # 2
>>
>> As we discussed from the very beginning after user selects a release he
>> can
>> choose a set of plugins which he wants to be enabled for environment.
>> After that we can say that plugin is enabled for the environment and we
>> send
>> tasks related to this plugin to task executor.
>>
>> >> My approach also allows to eliminate "enableness" of plugins which
>> will cause UX issues and issues like you described above. vCenter and Ceph
>> also don't have "enabled" state. vCenter has hypervisor and storage, Ceph
>> provides backends for Cinder and Glance which can be used simultaneously or
>> only one of them can be used.
>>
>> Both of described plugins have enabled/disabled state, vCenter is enabled
>> when vCenter is selected as hypervisor. Ceph is enabled when it's selected
>> as a backend for Cinder or Glance.
>>
> Nope, Ceph for Volumes can be used without Ceph for Images. Both of these
> plugins can also have some granular tasks which are enabled by various
> checkboxes (like VMware vCenter for volumes). How would you determine
> whether tasks which installs VMware vCenter for volumes should run?
>

Why "nope"? I have "Cinder OR Glance".
It can be easily handled in deployment script.


>> If you don't like the idea of having Ceph/vCenter checkboxes on the first
>> page,
>> I can suggest as an idea (research is required) to define groups like
>> Storage Backend,
>> Network Manager and we will allow plugin developer to embed his option in
>> radiobutton
>> field on wizard pages. But plugin developer should not describe
>> conditions, he should
>> just write that his plugin is a Storage Backend, Hypervisor or new
>> Network Manager.
>> And the plugins e.g. Zabbix, Nagios, which don't belong to any of this
>> groups
>> should be shown as checkboxes on the first page of the wizard.
>>
> Why don't you just ditch "enableness" of plugins and get rid of this
> complex stuff? Can you explain why do you need to know if plugin is
> "enabled"? Let me summarize my opinion on this:
>

I described why we need it many times. Also it looks like you skipped
another option
and I would like to see some more information why you don't like it and

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

2014-12-10 16:57 GMT+03:00 Evgeniy L :

> Hi,
>
> First let me describe what our plans for the nearest release. We want to
> deliver
> role as a simple plugin, it means that plugin developer can define his own
> role
> with yaml and also it should work fine with our current approach when user
> can
> define several fields on the settings tab.
>
> Also I would like to mention another thing which we should probably discuss
> in separate thread, how plugins should be implemented. We have two types
> of plugins, simple and complicated, the definition of simple - I can do
> everything
> I need with yaml, the definition of complicated - probably I have to write
> some
> python code. It doesn't mean that this python code should do absolutely
> everything it wants, but it means we should implement stable, documented
> interface where plugin is connected to the core.
>
> Now lets talk about UI flow, our current problem is how to get the
> information
> if plugins is used in the environment or not, this information is required
> for
> backend which generates appropriate tasks for task executor, also this
> information can be used in the future if we decide to implement plugins
> deletion
> mechanism.
>
> I didn't come up with a some new solution, as before we have two options to
> solve the problem:
>
> # 1
>
> Use conditional language which is currently used on UI, it will look like
> Vitaly described in the example [1].
> Plugin developer should:
>
> 1. describe at least one element for UI, which he will be able to use in
> task
>
> 2. add condition which is written in our own programming language
>
> Example of the condition for LBaaS plugin:
>
> condition: settings:lbaas.metadata.enabled == true
>
> 3. add condition to metadata.yaml a condition which defines if plugin is
> enabled
>
> is_enabled: settings:lbaas.metadata.enabled == true
>
> This approach has good flexibility, but also it has problems:
>
> a. It's complicated and not intuitive for plugin developer.
>
It is less complicated than python code

> b. It doesn't cover case when the user installs 3rd party plugin
> which doesn't have any conditions (because of # a) and
> user doesn't have a way to disable it for environment if it
> breaks his configuration.
>
If plugin doesn't have conditions for tasks, then it has invalid metadata.

>
> # 2
>
> As we discussed from the very beginning after user selects a release he can
> choose a set of plugins which he wants to be enabled for environment.
> After that we can say that plugin is enabled for the environment and we
> send
> tasks related to this plugin to task executor.
>
> >> My approach also allows to eliminate "enableness" of plugins which
> will cause UX issues and issues like you described above. vCenter and Ceph
> also don't have "enabled" state. vCenter has hypervisor and storage, Ceph
> provides backends for Cinder and Glance which can be used simultaneously or
> only one of them can be used.
>
> Both of described plugins have enabled/disabled state, vCenter is enabled
> when vCenter is selected as hypervisor. Ceph is enabled when it's selected
> as a backend for Cinder or Glance.
>
Nope, Ceph for Volumes can be used without Ceph for Images. Both of these
plugins can also have some granular tasks which are enabled by various
checkboxes (like VMware vCenter for volumes). How would you determine
whether tasks which installs VMware vCenter for volumes should run?

>
> If you don't like the idea of having Ceph/vCenter checkboxes on the first
> page,
> I can suggest as an idea (research is required) to define groups like
> Storage Backend,
> Network Manager and we will allow plugin developer to embed his option in
> radiobutton
> field on wizard pages. But plugin developer should not describe
> conditions, he should
> just write that his plugin is a Storage Backend, Hypervisor or new Network
> Manager.
> And the plugins e.g. Zabbix, Nagios, which don't belong to any of this
> groups
> should be shown as checkboxes on the first page of the wizard.
>
Why don't you just ditch "enableness" of plugins and get rid of this
complex stuff? Can you explain why do you need to know if plugin is
"enabled"? Let me summarize my opinion on this:

   - You don't need to know whether plugin is enabled or not. You need to
   know what tasks should be run and whether plugin is removable (anything
   else?). These conditions can be described by the DSL.
   - Explicitly asking the user to enable plugin for new environment should
   be considered as a last resort solution because it significantly impair our
   UX for inexperienced user. Just imagine: a new user which barely knows
   about OpenStack chooses a name for the environment, OS release and then he
   needs to choose plugins. Really?

My proposal for "complex" plugin interface: there should be python classes
with exactly the same fields from yaml files: plugin name, version, etc.
But condition for cluster deletion and for tasks which are written in

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Hi,

First let me describe what our plans for the nearest release. We want to
deliver
role as a simple plugin, it means that plugin developer can define his own
role
with yaml and also it should work fine with our current approach when user
can
define several fields on the settings tab.

Also I would like to mention another thing which we should probably discuss
in separate thread, how plugins should be implemented. We have two types
of plugins, simple and complicated, the definition of simple - I can do
everything
I need with yaml, the definition of complicated - probably I have to write
some
python code. It doesn't mean that this python code should do absolutely
everything it wants, but it means we should implement stable, documented
interface where plugin is connected to the core.

Now lets talk about UI flow, our current problem is how to get the
information
if plugins is used in the environment or not, this information is required
for
backend which generates appropriate tasks for task executor, also this
information can be used in the future if we decide to implement plugins
deletion
mechanism.

I didn't come up with a some new solution, as before we have two options to
solve the problem:

# 1

Use conditional language which is currently used on UI, it will look like
Vitaly described in the example [1].
Plugin developer should:

1. describe at least one element for UI, which he will be able to use in
task

2. add condition which is written in our own programming language

Example of the condition for LBaaS plugin:

condition: settings:lbaas.metadata.enabled == true

3. add condition to metadata.yaml a condition which defines if plugin is
enabled

is_enabled: settings:lbaas.metadata.enabled == true

This approach has good flexibility, but also it has problems:

a. It's complicated and not intuitive for plugin developer.
b. It doesn't cover case when the user installs 3rd party plugin
which doesn't have any conditions (because of # a) and
user doesn't have a way to disable it for environment if it
breaks his configuration.

# 2

As we discussed from the very beginning after user selects a release he can
choose a set of plugins which he wants to be enabled for environment.
After that we can say that plugin is enabled for the environment and we send
tasks related to this plugin to task executor.

>> My approach also allows to eliminate "enableness" of plugins which will
cause UX issues and issues like you described above. vCenter and Ceph also
don't have "enabled" state. vCenter has hypervisor and storage, Ceph
provides backends for Cinder and Glance which can be used simultaneously or
only one of them can be used.

Both of described plugins have enabled/disabled state, vCenter is enabled
when vCenter is selected as hypervisor. Ceph is enabled when it's selected
as a backend for Cinder or Glance.

If you don't like the idea of having Ceph/vCenter checkboxes on the first
page,
I can suggest as an idea (research is required) to define groups like
Storage Backend,
Network Manager and we will allow plugin developer to embed his option in
radiobutton
field on wizard pages. But plugin developer should not describe conditions,
he should
just write that his plugin is a Storage Backend, Hypervisor or new Network
Manager.
And the plugins e.g. Zabbix, Nagios, which don't belong to any of this
groups
should be shown as checkboxes on the first page of the wizard.

>
[1]
https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf

On Sun, Nov 30, 2014 at 3:12 PM, Vitaly Kramskikh 
wrote:

>
>
> 2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak :
>
>>
>>>- 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.
>>>
>>>  Initially i had the same thoughts and wanted to use it the way it is,
>> but now i completely agree with Evgeniy that additional DSL will cause a lot
>> of problems with compatibility between versions and developer experience.
>>
> As far as I understand, you want to introduce another approach to describe
> UI part or plugins?
>
>> We need to search for alternatives..
>> 1. for UI i would prefer separate tab for plugins, where user will be
>> able to enable/disable plugin explicitly.
>>
> Of course, we need a separate page for plugin management.
>
>> Currently settings tab is overloaded.
>> 2. on backend we need to validate plugins against certain env before
>> enabling it,
>>and for simple case we may expose some basic entities like
>> network_mode.
>> For case where you need complex logic - python code is far more flexible
>> that new DSL.
>>
>>>
>>>- 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

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

Dmitry,

2014-11-29 1:01 GMT+04:00 Dmitry Borodaenko :

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

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

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak :

>
>>- 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.
>>
>>  Initially i had the same thoughts and wanted to use it the way it is,
> but now i completely agree with Evgeniy that additional DSL will cause a lot
> of problems with compatibility between versions and developer experience.
>
As far as I understand, you want to introduce another approach to describe
UI part or plugins?

> We need to search for alternatives..
> 1. for UI i would prefer separate tab for plugins, where user will be able
> to enable/disable plugin explicitly.
>
Of course, we need a separate page for plugin management.

> Currently settings tab is overloaded.
> 2. on backend we need to validate plugins against certain env before
> enabling it,
>and for simple case we may expose some basic entities like network_mode.
> For case where you need complex logic - python code is far more flexible
> that new DSL.
>
>>
>>- 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".
>>
>> How checkbox will help? There is several cases of plugin removal..
>
It is not a checkbox, this is condition that determines whether the plugin
is removable. It allows plugin developer specify when plguin can be safely
removed from Fuel if there are some environments which were created after
the plugin had been installed.

> 1. Plugin is installed, but not enabled for any env - just remove the
> plugin
> 2. Plugin is installed, enabled and cluster deployed - forget about it for
> now..
> 3. Plugin is installed and only enabled - we need to maintain state of db
> consistent after plugin is removed, it is problematic, but possible
>
My approach also allows to eliminate "enableness" of plugins which will
cause UX issues and issues like you described above. vCenter and Ceph also
don't have "enabled" state. vCenter has hypervisor and storage, Ceph
provides backends for Cinder and Glance which can be used simultaneously or
only one of them can be used.

> My main point that plugin is enabled/disabled explicitly by user, after
> that we can decide ourselves can it be removed or not.
>
>>
>>- 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.
>>
>> I had some thoughts about using DSL, it seemed to me especially helpfull
> when you need to disable part of embedded into core functionality,
> like deploying with another hypervisor, or network dirver (contrail for
> example). And DSL wont cover all cases here, this quite similar to
> metadata.yaml, simple cases can be covered by some variables in tasks (like
> group, unique, etc), but complex is easier to test and describe in python.
>
Could you please provide example of such conditions? vCenter and Ceph can
be turned into plugins using this approach.

Also, I'm not against python version of plugins. It could look like a
python class with exactly the same fields form YAML files, but conditions
will be written in python.

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

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Andrew Woodward]

I think it's necessary to start a working group for plugins and meet by
weekly until issues like these are flushed out of the design
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Dmitry Borodaenko]

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?

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.
On Nov 28, 2014 9:48 AM, "Vitaly Kramskikh"  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 :
>
>> >> 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 :
>>>
 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:

> Fol

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Dmitriy Shulyak]

>
>
>- 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.
>
>  Initially i had the same thoughts and wanted to use it the way it is, but
now i completely agree with Evgeniy that additional DSL will cause a lot
of problems with compatibility between versions and developer experience.
We need to search for alternatives..
1. for UI i would prefer separate tab for plugins, where user will be able
to enable/disable plugin explicitly.
Currently settings tab is overloaded.
2. on backend we need to validate plugins against certain env before
enabling it,
   and for simple case we may expose some basic entities like network_mode.
For case where you need complex logic - python code is far more flexible
that new DSL.

>
>- 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".
>
> How checkbox will help? There is several cases of plugin removal..
1. Plugin is installed, but not enabled for any env - just remove the plugin
2. Plugin is installed, enabled and cluster deployed - forget about it for
now..
3. Plugin is installed and only enabled - we need to maintain state of db
consistent after plugin is removed, it is problematic, but possible
My main point that plugin is enabled/disabled explicitly by user, after
that we can decide ourselves can it be removed or not.

>
>- 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.
>
> I had some thoughts about using DSL, it seemed to me especially helpfull
when you need to disable part of embedded into core functionality,
like deploying with another hypervisor, or network dirver (contrail for
example). And DSL wont cover all cases here, this quite similar to
metadata.yaml, simple cases can be covered by some variables in tasks (like
group, unique, etc), but complex is easier to test and describe in python.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

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 :

> >> 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  > wrote:
>
>> Evgeniy,
>>
>> Responses inline:
>>
>> 2014-11-28 18:31 GMT+03:00 Evgeniy L :
>>
>>> 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_attribu

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

>> 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 
wrote:

> Evgeniy,
>
> Responses inline:
>
> 2014-11-28 18:31 GMT+03:00 Evgeniy L :
>
>> 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 Gra

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

Evgeniy,

Responses inline:

2014-11-28 18:31 GMT+03:00 Evgeniy L :

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

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

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
2. the language is not documented (solvable)
3. complicated interface will lead to a lot of bugs for the end user, and
it will be
a Fuel team's problem
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

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.

Thanks,

On Thu, Nov 27, 2014 at 7:57 PM, Vitaly Kramskikh 
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

[openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Vitaly Kramskikh]

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