Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-15 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-15 Thread Mike Scherbakov
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-14 Thread Mike Scherbakov
+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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-13 Thread Evgeniy L
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.

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-09 Thread Vitaly Kramskikh
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-09 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-09 Thread Vitaly Kramskikh
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-09 Thread Dmitry Borodaenko
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) -

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Dmitriy Shulyak
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Nikolay Markov
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)

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Vitaly Kramskikh
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Nikolay Markov
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Vitaly Kramskikh
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Vitaly Kramskikh
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Nikolay Markov
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-08 Thread Dmitry Borodaenko
I don't like how this discussion is framed. The initial premise that we have only two controversial options to choose from is lazy. If there is no consensus, we should look for more options, not for a popular vote. Secondly, current level of UX is not negotiable. You can't take something that we

[openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-07 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-07 Thread Evgeniy L
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-07 Thread Vitaly Kramskikh
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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

2014-10-07 Thread Nikolay Markov
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