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

Bug #1449086 reported by Roman Prykhodchenko
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Confirmed
Medium
Fuel Sustaining
6.1.x
Won't Fix
High
Fuel Python (Deprecated)
7.0.x
Won't Fix
Medium
Fuel Python (Deprecated)
Mitaka
Won't Fix
Medium
Fuel Python (Deprecated)
Newton
Confirmed
Medium
Fuel Sustaining

Bug Description

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.

Revision history for this message
Roman Prykhodchenko (romcheg) wrote :
description: updated
description: updated
description: updated
Revision history for this message
Roman Prykhodchenko (romcheg) wrote :
Revision history for this message
Roman Prykhodchenko (romcheg) wrote :

Attached several other screenshot with some debug information

Revision history for this message
Alexandra Morozova (astepanchuk) wrote :

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

Changed in fuel:
assignee: Fuel UI Team (fuel-ui) → Fuel Python Team (fuel-python)
status: New → Confirmed
Revision history for this message
Vitaly Kramskikh (vkramskikh) wrote :

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

Revision history for this message
Aleksey Kasatkin (alekseyk-ru) wrote :

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.

Revision history for this message
Aleksey Kasatkin (alekseyk-ru) wrote :

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).

tags: added: feature
tags: added: module-nailgun
Revision history for this message
Przemyslaw Kaminski (pkaminski) wrote :

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.

Revision history for this message
Vitaly Kramskikh (vkramskikh) wrote :

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

Revision history for this message
Vitaly Kramskikh (vkramskikh) wrote :

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.

Dmitry Pyzhov (dpyzhov)
tags: added: release-notes
Changed in fuel:
milestone: 6.1 → 7.0
Revision history for this message
Oleg S. Gelbukh (gelbuhos) wrote :

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.

Revision history for this message
Oleg S. Gelbukh (gelbuhos) wrote :

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).

Revision history for this message
Aleksandr Didenko (adidenko) wrote :

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

Revision history for this message
Roman Prykhodchenko (romcheg) wrote :

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

Revision history for this message
Vladimir Sharshov (vsharshov) wrote :

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

tags: added: covered-by-bp
tags: added: known-issue
Changed in fuel:
milestone: 7.0 → 8.0
tags: removed: feature
Dmitry Pyzhov (dpyzhov)
no longer affects: fuel/8.0.x
tags: removed: release-notes
Dmitry Pyzhov (dpyzhov)
tags: added: area-python
Changed in fuel:
milestone: 8.0 → 9.0
Revision history for this message
Alexander Kislitsky (akislitsky) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.