Open Stack

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). It
doesn't reflect the fact that some nodes can be in 'provisioned' state,
some are in 'provisioning', 'deploying', 'ready' statuses.

First two seem clear enough. We could add ability to stop/reset particular
nodes and reflect CLI-driven changes in the cluster status.
To address the last point my proposal was (bug/1449086/comments/7
<https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086/comments/7>) to break
status into several binary states, i.e. binaries: 'new', 'deployment',
'ready', etc., each of which is set to true when cluster has at least one
node in corresponding status (I united 'provisioning', 'provisioned' and
'deploying' into one as it is done now).

Now it looks more reasonable to me to keep the original status as is and
add bitwise one mentioned above (to address states of different nodes)
because 'error' state is determinative for cluster (when cluster is in
'error' state it is no matter that some nodes are in 'ready' state).
So,
cluster is in 'new' state when all nodes are in 'discover' state,
it is in 'operational' state when all nodes are in 'ready' state,
cluster is in 'deployment' state when not all of its nodes are in 'discover'
or 'ready' state but there are no nodes in 'error' and 'removing' states.
New bitwise status is actual in 'deployment' state of cluster. It gives to
UI/CLI sufficient data to determine what actions can be applied to cluster
at the moment.

I've combined some of the states combinations into the table:

'new' flag

'deployment' flag

'ready' flag

description, actions allowed

false

false

false

There are no nodes in cluster or all nodes are in 'error'/'removing' state.
Cluster is in 'new'/'error'/'remove' state here so we don't care about
these flags.

false

true

false

All nodes are under provisioning/deployment. Deployment can be stopped.

true

true

false

Part of nodes is in 'discover' state, remaining part is under
provisioning/deployment. Deployment can be started for the first part
or/and stopped for the second part of nodes.

true

false

true

Part of nodes is in 'discover' state, remaining part is in 'ready' state.
Deployment can be started for the first part and second part can be reset.

true

true

true

We have some nodes in every of the states: 'discover',
provisioning/deployment, 'ready'. So, we can allow different actions for
nodes in different states.

false

true

true

Part of nodes is under provisioning/deployment, remaining part is in
'ready' state. Deployment can be stopped for the first part and second part
can be reset.
I didn't show another 2 combinations here as they aren't related to
'deployment'
state of cluster (as well as the first one in the table).

Also, we should be careful with the order of nodes deployment/reset. I'm
not sure whether it is written in our docs that cluster may be
non-functional if user tries to deploy nodes in the wrong order (e.g.
computes first). We could show some warnings about that. Same applies to
selective reset if we will implement it.



Aleksey Kasatkin


On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko <me at romcheg.me> wrote:

> 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 correctly and Nailgun’s API returns it as NEW
> even while some of the node are been provisioned.
>
> The reason for raising this thread in the mailing list is that
> provisioning a node is a feature for developers and basically end-users
> should not do that. What is the best solution for that: fix Nailgun to set
> the correct status, or make this provisioning feature available only for
> developers?
>
> 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
>
>
> - romcheg
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150525/eec51a64/attachment.html>