deployment from CLI on 1 node leads to deployment on others

Bug #1339612 reported by Sergey Kolekonov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
New
High
Artem Roma

Bug Description

{"build_id": "2014-07-09_00-58-40", "ostf_sha": "f6f7cee46a85ca3e758f629c2df8b370e9de494a", "build_number": "304", "auth_required": false, "api": "1.0", "nailgun_sha": "2001a30884f2c24d18a62fc9f9c76c6ed66691e3", "production": "docker", "fuelmain_sha": "9e441d9035fa852bdb00be1031355f0f89823231", "astute_sha": "c0ffd4fa1b1ea16931f174a7f4efeac701ec23e6", "feature_groups": ["mirantis"], "release": "5.1", "fuellib_sha": "fd5fd0d3f74c5a084adfc951a4ee24e3dc27e09c"}

Steps to reproduce:
1. Create new environment from UI (for example, 1 controller + 1 compute)
2. Add nodes to environment and assign roles
3. ssh to the master node, execute nodes provisioning
4. When nodes are provisioned, start deployment on 1 node using CLI
     [root@fuel ~]# fuel node --env 1 --node 1 --deploy

Expected results:
The selected node is deployed, other nodes are unchanged

Actual results:
If selected node's deployment is successful, another node (compute) is deployed too.

Tags: cli
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :
Changed in fuel:
milestone: none → 5.1
Revision history for this message
Sergey Kolekonov (skolekonov) wrote :

Here's the diagnostic snapshot for the described deployment (after two executions of deployment)

Changed in fuel:
importance: Undecided → High
assignee: nobody → Fuel Python Team (fuel-python)
Artem Roma (aroma-x)
Changed in fuel:
assignee: Fuel Python Team (fuel-python) → Artem Roma (aroma-x)
Revision history for this message
Artem Roma (aroma-x) wrote :

There is notification on ui screenshot from which I may assume you had changed default deployment info for env via fuelclient before doing separate provisioning and deployment. In such case described behavior is expected.

I've tested workflow on clean (i.e. with no modified via cli) environment and everything worked as expected. As a matter of fact there already is bug for the issue so I will mark this as duplicate of that.

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

Other bug subscribers

Remote bug watches

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