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 on
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 wrote:
> Oleg,
>
> Thanks for the feedback. I have the following as a response:
>
> 1. This spec is just an excerpt for scoping in the
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 wi
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 'op
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. http://lists.openstac
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 s
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 moment
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 correctl
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
'oper
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 t
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 correctl
11 matches
Mail list logo
