Deploy button still shows "Deploy Changes" after provisioning was started from CLI

[Roman Prykhodchenko]

Provisioning was started by the following command:

fuel --env-id=4 node --provision --node=7 && fuel --env-id=4 node --deploy --node=7

The button in the UI should allow to break deployment but it doesn't. The screenshot with the debug information is attached.

[Roman Prykhodchenko (romcheg)]

Attached several other screenshot with some debug information

[Alexandra Morozova (astepanchuk)]

assigning to Fuel-Python due to New status of node during provisioning http://xsnippet.org/360654/

[Vitaly Kramskikh (vkramskikh)]

Status of cluster is "new" during provisining, that's why the button is active.

[Aleksey Kasatkin (alekseyk-ru)]

AFAIC, we need "stop" for particular nodes as well as provision/deployment.

I'm not sure how to manage cluster state here. When we run provision/deployment for a half of nodes I'd not change the status of cluster because it is not clear how to change its status when provision/deployment will be stared for other half of nodes.

Maybe change status of cluster when last node is triggered for provision/deployment but this may lead to some unclear UX as well.

As an option, we could add some new cluster statuses like "partial_provision", "partial_deployment", etc. But statuses management becomes sophisticated.

[Aleksey Kasatkin (alekseyk-ru)]

Generally, cluster status can be divided into several binary states: bootstrapped (true/false), provisioning (true/false), provisioned (true/false), deployment (true/false). Each of these is true when some nodes in cluster are in corresponing state.

This can be shorten to three states maybe: bootstrapped, in_progress, ready. Seems to be enough for cluster management (to determine which actions can be applied to cluster).

[Przemyslaw Kaminski (pkaminski)]

How about we add support for querystrings in GET method of TaskColllectionHandler, and add ability to filter that collection by task name and running status? UI would then be able to check if deployment task is running or not, regardless of cluster's status. I think this should be a general way of checking if some task is in progress or not.

[Vitaly Kramskikh (vkramskikh)]

This can be considered for 7.0 (though I don't see any profits of this, but there definitely will be increase of backend queries). In 6.1 it's pretty risky and requires major rework of code in many places. If it's not possible to fix status update on the nailgun side (which I consider as the reason of this bug), I suggest to add provision task to deployment group here:

https://github.com/stackforge/fuel-web/blob/master/nailgun/static/js/models.js#L409

[Vitaly Kramskikh (vkramskikh)]

I also like Alexey's proposal. current logic of enableness of the button is quite complex and uses multiple sources of truth (cluster status, node statuses, tasks and their statuses) and should be reworked.

[Oleg S. Gelbukh (gelbuhos)]

I don't think it's correct to tie cluster/environment status to statuses of nodes in the cluster. I guess it's more reasonable to connect it to status of services provided by the cluster. This can translate into status of nodes (e.g. your services probably not up if you don't have 'ready' controllers, and you probably can't have operational cluster without compute nodes, etc), but this is complex and indirect translation.

[Oleg S. Gelbukh (gelbuhos)]

Actually, I'm using version 6.0 and environment remains 'New' (with active 'Deploy changes' button) even though all nodes in the environment are 'ready' (provisioned and deployed via CLI).

[Aleksandr Didenko (adidenko)]

Assigned to Roma to link this feature bug to appropriate BP.

[Roman Prykhodchenko (romcheg)]

I've attached this bug to https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status. Returning the bug back to the pool.

[Vladimir Sharshov (vsharshov)]

Can be fixed only after implementation of https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status. Know issue. Moving to 8.0

[Alexander Kislitsky (akislitsky)]

We passed SCF in 8.0. Moving the bug to 9.0.