Hi Mike,
Dmitry S. started to work on checkboxes auto-generation in nailgun
for UI.
And in parallel I've written simple script which just updates release
model with checkboxes and plugin's fields, this simple script will be used
only for POC, and then we will replace it with Dmitry's
Thanks, good.
On Wed, Oct 15, 2014 at 12:41 PM, Evgeniy L e...@mirantis.com wrote:
Hi Mike,
Dmitry S. started to work on checkboxes auto-generation in nailgun
for UI.
And in parallel I've written simple script which just updates release
model with checkboxes and plugin's fields, this
+1 for doing now:
we are going to implement something really simple, like updating plugin
attributes directly via api.
Then we can have discussions in parallel how we plan to evolve it.
Please confirm that we went this path.
Thanks,
On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L e...@mirantis.com
Hi,
We've discussed what we will be able to do for the current release and
what we will not be able to implement.
We have not only technical problems, but also we don't have a lot of time
for implementation. We were trying to find solution which will work well
enough
with all of the constraints.
Let me propose another approach. I agree with most of Dmitry's statements
and it seems in MVP we need plugin management UI where we can enable
installed plugins. It should be a separate page. If you want to create
environment with a plugin, enable the plugin on this page and create a new
Hi,
Vitaly, I like the idea of having separate page, but I'm not sure if it
should be on releases page.
Usually a plugin is not release specific, usually it's environment specific
and you can have
different set of plugins for different environments.
Also I don't think that we should enable
Evgeniy,
Yes, the plugin management page should be a separate page. As for
dependency on releases, I meant that some plugin can work only on Ubuntu
for example, so for different releases different plugins could be available.
And please confirm that you also agree with the flow: the user install
Notes from the architecture review meeting on plugins UX:
- separate page for plugins management
- user installs the plugin on the master
- global master node configuration across all environments:
- user can see a list of plugins on Plugins tab (plugins description)
-
If there is no checkboxes (read configuration) and plugin is installed -
all deployment tasks will be applied
to every environment, but why do you think that there will be no checkboxes
in most cases?
Right now we already have like 2 types of plugins (extensions), classified
by usage of settings
Right now we already have like 2 types of plugins (extensions), classified
by usage of settings tab:
1. Some kind of backend for service (swift/ceph, lvm/ceph, ovs/nsx), or
hypervisor (lvm/qemu/vmware)
2. Self-contained service that just needs to be installed (sahara, murano,
zabbix)
Nikolay,
Currently every thing that can be turned into a plugin (Ceph, vCenter,
Sahara, Murano, Ceilometer) provides a checkbox (or more complicated
controls) for the settings tab. Why change this approach for plugins? The
settings tab (cluster attributes) currently is a SSOT
Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
they should do is installing a package and modify a couple of config files
(run a shell command).
These ones have nothing to do with UI or any checkboxes, aren't they?
08 Окт 2014 г. 12:49 пользователь Vitaly Kramskikh
Hi,
Vitaly, I understand your concerns about UX.
But there are technical problems and statements which affect
plugin developer and makes his live more complicated.
My opinion is we definitely should know, if plugin is disabled
or if it's enabled for specific environment.
1. plugin developer
So they should be implemented like Murano or Sahara and provide a checkbox
in Additional Services section of the settings tab and the wizard
2014-10-08 19:57 GMT+07:00 Nikolay Markov nmar...@mirantis.com:
Our priorities for 6.0 at least are simplest plugins (like LBaaS), and all
they should do
Hi, responses inline.
2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com:
Hi,
Vitaly, I understand your concerns about UX.
But there are technical problems and statements which affect
plugin developer and makes his live more complicated.
My opinion is we definitely should know, if
Vitaly,
Once again, as a plugin developer I don't care about how Sahara or Murano
is implemented. I don't care about checkboxes, either. I just want one
simple command to run on target nodes and I should be provided with the
simplest possible interface to:
1) Write this command in some YAML and
Hi,
We had a meeting today about plugins on UI, as result of the meeting
we have two approaches and this approaches affect not only UX but
plugins itself.
*1st - disable/enable plugin on settings tab*
1. user installs the plugin
2. creates a cluster
3. configures and enables/disables
Hi Dmitry,
In 1st case - in tasks we will introduce simple conditions (in
description or in python code of the plugin):
You will be able to do it in the same way in case of 2nd solution.
I mean there is no constraints on conditions defining.
Also, we should not forget about CLI
In case of
Hi,
I would go with the 1st approach. The thing I don't like in the 2nd
approach is that we have to make the user enable plugin twice. For example,
we have to enable Ceph as a plugin and then add Ceph role to nodes and
choose what we want to store in Ceph (images, objects). Why we would need
to
Hi,
Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff
20 matches
Mail list logo
