Vitaly, what do you think about that?
On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L e...@mirantis.com 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
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
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
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
2014-12-10 16:57 GMT+03:00 Evgeniy L e...@mirantis.com:
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
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 e...@mirantis.com:
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
2014-12-10 19:31 GMT+03:00 Evgeniy L e...@mirantis.com:
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 e...@mirantis.com:
Hi,
First let me describe what our plans for the nearest release. We want to
deliver
role
2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak dshul...@mirantis.com:
- 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
Dmitry,
2014-11-29 1:01 GMT+04:00 Dmitry Borodaenko dborodae...@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
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
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
Evgeniy,
Responses inline:
2014-11-28 18:31 GMT+03:00 Evgeniy L e...@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
- 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
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
14 matches
Mail list logo
