"Stop deployment" action works incorrectly at the end of deployment process

Bug #1466431 reported by Dennis Dmitriev on 2015-06-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fuel Sustaining
Fuel Python (Deprecated)
Fuel Python (Deprecated)
Fuel Sustaining

Bug Description

In Fuel UI, if "Stop deployment" is selected when all nodes have just been marked as 'Ready', then cluster status becomes "Stopped", but the button "Deploy changes" is inactive.

Looks like some post-deployment actions wasn't performed in this case. Several OSTF tests failed because TestVM image wasn't uploaded.

Steps to reproduce:
    - Create a cluster with any configuration (for example: CentOS / IBP, Nova-network/FlatDHCP, Ceph for images, RagosGW for objects);
    - Add nodes to the cluster (for example: 1 controller, 1 compute, 1 cinder, 3 ceph);
    - Deploy changes;
    - Press "Stop deployment" button at the moment when all nodes became "Ready"

Expected result: After pressing "Stop deployment", button "Deploy changes" is available.

Actual result: button "Deploy changes" is not available (see the attached screenshot). To make "Deploy changes" available, a new compute node was added to the cluster, but deploy failed with the following error in puppet for the new compute:

2015-06-18 10:19:43 NOTICE (/Stage[main]/Ceph::Nova_compute/Exec[Set Ceph RBD secret for Nova]/returns) Error ENOENT: don't have client.compute
2015-06-18 10:19:43 ERR (/Stage[main]/Ceph::Nova_compute/Exec[Set Ceph RBD secret for Nova]/returns) change from notrun to 0 failed: virsh secret-set-value --secret $( virsh secret-define --file /root/secret.xml | egrep -o '[0-9a-fA-F]{8}(-[0-9a-fA-F]{4}){3}-[0-9a-fA-F]{12}') --base64 $(ceph auth get-key client.compute) && rm /root/secret.xml returned 1 instead of one of [0]

{"build_id": "2015-06-16_13-53-26", "build_number": "522", "release_versions": {"2014.2.2-6.1": {"VERSION": {"build_id": "2015-06-16_13-53-26", "build_number": "522", "api": "1.0", "fuel-library_sha": "3528dddbd0c961290909d5e3e256f55ff75cd2fc", "nailgun_sha": "fa8dec50f3df2626c97f6c38a897cf4e0f80b39d", "feature_groups": ["mirantis"], "openstack_version": "2014.2.2-6.1", "production": "docker", "python-fuelclient_sha": "4fc55db0265bbf39c369df398b9dc7d6469ba13b", "astute_sha": "1ea8017fe8889413706d543a5b9f557f5414beae", "fuel-ostf_sha": "8fefcf7c4649370f00847cc309c24f0b62de718d", "release": "6.1", "fuelmain_sha": "42020c36d6dec9fedf61faa68aa3674156d41977"}}}, "auth_required": true, "api": "1.0", "fuel-library_sha": "3528dddbd0c961290909d5e3e256f55ff75cd2fc", "nailgun_sha": "fa8dec50f3df2626c97f6c38a897cf4e0f80b39d", "feature_groups": ["mirantis"], "openstack_version": "2014.2.2-6.1", "production": "docker", "python-fuelclient_sha": "4fc55db0265bbf39c369df398b9dc7d6469ba13b", "astute_sha": "1ea8017fe8889413706d543a5b9f557f5414beae", "fuel-ostf_sha": "8fefcf7c4649370f00847cc309c24f0b62de718d", "release": "6.1", "fuelmain_sha": "42020c36d6dec9fedf61faa68aa3674156d41977"}

Dennis Dmitriev (ddmitriev) wrote :
Changed in fuel:
assignee: nobody → Fuel Python Team (fuel-python)
status: New → Confirmed
Vladimir Sharshov (vsharshov) wrote :

Workaround: reset cluster.

We could not garantee that deployment will fine after stop deployment. As i remember, we have such bug for 6.1 also, but i could not find link, and also should added this info release-notes for 6.1.

Add release-notes tag.

Vladimir Sharshov (vsharshov) wrote :

Moved to 8.0

tags: added: release-notes
no longer affects: fuel/8.0
tags: added: module-nailgun
Changed in fuel:
milestone: 7.0 → 8.0
no longer affects: fuel/8.0
tags: added: covered-by-bp
Vladimir Sharshov (vsharshov) wrote :

This task is directly connected with blueprint: https://blueprints.launchpad.net/fuel/+spec/progress-bar-based-on-tasks, because we send Ready status for some node and after it do not resend/redeploy tasks for it.

Dmitry Pyzhov (dpyzhov) on 2015-10-22
tags: added: area-python

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

Changed in fuel:
milestone: 8.0 → 9.0

Related fix proposed to branch: master
Change author: Evgeny Konstantinov <email address hidden>
Review: https://review.fuel-infra.org/22317

Reviewed: https://review.fuel-infra.org/22317
Submitter: Evgeny Konstantinov <email address hidden>
Branch: master

Commit: 3efec3275f772c0c41c01d2a5013c596463a24fa
Author: Evgeny Konstantinov <email address hidden>
Date: Wed Jun 22 12:58:01 2016

Add Fuel known issues to relnotes 9.0

Change-Id: I9130ecc87d013db29e8a170911e59de0631a0222
Related-Bug: #1587897
Related-Bug: #1450100
Related-Bug: #1490597
Related-Bug: #1466431
Related-Bug: #1419201

Alexey Shtokolov (ashtokolov) wrote :

This Bug doesn't affect the Task-based deployment, which is the one available deployment engine since Fuel Mitaka (9.0)

tags: added: release-notes-done
removed: release-notes
Miroslav Anashkin (manashkin) wrote :

"Workaround: reset cluster."

How are you going to reset the entire cluster in case we add new node to already running cluster?
Reset wipes all existing nodes in the cluster!

Changed tags back to release notes and raised to Critical for 9.0, since this incorrect workaround was already published in the Release Notes.

tags: added: release-notes
removed: release-notes-done
Vladimir Kuklin (vkuklin) wrote :

Folks, in 9.0 Stop Deployment was rewritten. There are no post-deployment tasks any more - there is the single graph since task-based deployment engine. Clicking stop deployment button during deployment stage will put nodes into stopped status after puppet on the nodes stops running. There will be no data loss - you will be able to retrigger the deployment and as tasks are idempotent, there will be almost zero changes except for puppet notifies and idempotent calls to APIs.

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

Other bug subscribers

Related blueprints