Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-27 Thread Roman Prykhodchenko
Oleg, Thanks for the feedback. I have the following as a response: 1. This spec is just an excerpt for scoping in the proposed improvement to the 7.0 release plan. If it get’s scope the full specification will go through a standard review process so it will be possible to discuss names along

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-27 Thread Aleksey Kasatkin
Thank you Roman for driving this! Full list of nodes statuses is: NODE_STATUSES = Enum( 'ready', 'discover', 'provisioning', 'provisioned', 'deploying', 'error', 'removing', ) We could combine 'provisioning', 'provisioned', 'deploying' into one maybe as cluster has

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-27 Thread Oleg Gelbukh
Excellent, nice to know that we're on the same page about this. Thank you! -- Best regards, Oleg Gelbukh On Wed, May 27, 2015 at 12:22 PM, Roman Prykhodchenko m...@romcheg.me wrote: Oleg, Thanks for the feedback. I have the following as a response: 1. This spec is just an excerpt for

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-27 Thread Oleg Gelbukh
Roman, This looks like a great solution to me, and I like your proposal very much. The status of cluster derived directly from statuses of nodes is exactly what I was thinking about. I have to notes to the proposal, and I can copy them to etherpad if you think they deserve it: 1) status name

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-26 Thread Roman Prykhodchenko
Aleksey, thank you for your feedback. The first thing I’d like to highlight is that both web ui and the cli use the same Nailgun API to perform the same actions so basically we must not treat the command line client any differently. The idea of having a complex status for environment actually

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-26 Thread Roman Prykhodchenko
Oleg, Aleksander also proposed a nice proposed a nice solution [1] which is to have a complex status for cluster. That, however, looks like a BP so I’ve created an excerpt [2] for it and we will try to discuss it scope it for 7.0, if there is a consensus. References: 1.

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-25 Thread Aleksey Kasatkin
AFAIC, there are several problems (in API) here: 1. We cannot stop/reset particular nodes. 2. Cluster status doesn't address changes which were done via CLI. 3. Cluster status in its current form is not enough to manage cluster (i.e. to determine actions what can be applied to cluster at the

[openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-23 Thread Roman Prykhodchenko
Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-22 Thread Oleg Gelbukh
Roman, I'm totally for fixing Nailgun. However, the status of environment is not simply function of statuses of nodes in it. Ideally, it should depend on whether appropriate number of nodes of certain roles are in 'ready' status. For the meantime, it would be enough if environment was set to

[openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-22 Thread Roman Prykhodchenko
Hi folks! Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client. The background for that issue is that the provisioning task does not seem to update the cluster status

Re: [openstack-dev] [Fuel] Setting cluster status when provisioning a node

2015-05-22 Thread Mike Scherbakov
OpenStack operator should be provided with an option to just provision nodes. We want to provide flexibility for sophisticated users, and I consider this as normal use case. So I disagree that we should treat provisioning as just developers feature. For newbies / simplest clouds, we want to keep