Bug 1379815

Summary: Adding additional node to instackenv.json and running "openstack baremetal import instackenv.json" causes all the existing nodes to lose their existing profile
Product: Red Hat OpenStack Reporter: Alexander Chuzhoy <sasha>
Component: openstack-tripleo-commonAssignee: Miles Gould <mgould>
Status: CLOSED NOTABUG QA Contact: Alexander Chuzhoy <sasha>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 10.0 (Newton)CC: augol, dsneddon, dtantsur, hbrock, jcoufal, jslagle, kbasil, mburns, mcornea, mgould, rhel-osp-director-maint, sasha, slinaber, srevivo
Target Milestone: ---   
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-02 15:04:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alexander Chuzhoy 2016-09-27 18:03:03 UTC
openstack-ironic: adding additional node to instackenv.json and running "openstack baremetal import --json instackenv.json" causes all the existing nodes to lose their tag to existing profile.

Environment:


Steps to reproduce:
1. Deploy overcloud with:
openstack overcloud deploy --debug \
--templates \
--libvirt-type kvm \
--ntp-server clock.redhat.com \
--neutron-network-type vxlan \
--neutron-tunnel-types vxlan \
--control-scale 3 \
--control-flavor controller-d75f3dec-c770-5f88-9d4c-3fea1bf9c484 \--compute-scale 1 \
--compute-flavor compute-b634c10a-570f-59ba-bdbf-0c313d745a10 \--environment-file "/usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml" \
--ceph-storage-scale 2 \
--ceph-storage-flavor ceph-cf1f074b-dadb-5eb8-9eb0-55828273fab7 \
-e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml \
-e /home/stack/virt/ceph.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/hostnames.yml \
-e /home/stack/virt/debug.yaml


#Note the used flavors

2. Add additional node to instackenv.json
3. Run "openstack baremetal import --json instackenv.json"
4. Run "openstack baremetal configure boot
5. Attempt to scale compute with:

openstack overcloud deploy --debug \
--templates \
--libvirt-type kvm \
--ntp-server clock.redhat.com \
--neutron-network-type vxlan \
--neutron-tunnel-types vxlan \
--control-scale 3 \
--control-flavor controller-d75f3dec-c770-5f88-9d4c-3fea1bf9c484 \--compute-scale 2 \
--compute-flavor compute-b634c10a-570f-59ba-bdbf-0c313d745a10 \--environment-file "/usr/share/openstack-tripleo-heat-templates/environments/services/sahara.yaml" \
--ceph-storage-scale 2 \
--ceph-storage-flavor ceph-cf1f074b-dadb-5eb8-9eb0-55828273fab7 \
-e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml \
-e /home/stack/virt/ceph.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/hostnames.yml \
-e /home/stack/virt/debug.yaml

Result:

Error: only 0 of 3 requested ironic nodes are tagged to profile controller-d75f3dec-c770-5f88-9d4c-3fea1bf9c484 (for flavor controller-d75f3dec-c770-5f88-9d4c-3fea1bf9c484)
Recommendation: tag more nodes using ironic node-update <NODE ID> replace properties/capabilities=profile:controller-d75f3dec-c770-5f88-9d4c-3fea1bf9c484,boot_option:local
There are 7 ironic nodes with no profile that will not be used: b49e5645-4080-43c9-9cd4-cc8f16ca5aa6, 8ae72c6f-a391-4e3f-9f7b-e5eaede47e78, 92c54948-b480-43a9-9f6c-46dc39d6c601, d3efcfa7-cde9-42e0-8990-76a54d7f9bd4, 4b1090ae-889a-46ab-9c14-9525c17bd8ef, a855f1a0-881c-4395-a6e0-8134ae132475, 21b69552-1144-4dc0-aade-b96c7688d4c1


Run ironic node-show on any of the existing nodes - you'll see that none of the nodes has tag to profile.

Workaround, manually set the tag to profile with:
ironic node-update <NODE ID> replace properties/capabilities=profile:<profile>,boot_option:local

Comment 1 Lucas Alvares Gomes 2016-09-27 18:06:21 UTC
Thanks for the report,

The "openstack baremetal import" command is not part of the Ironic project (even tho it uses the "baremetal" namespace). It's part of TripleO (python-tripleoclient to be more exact).

Comment 2 Alexander Chuzhoy 2016-09-27 18:14:28 UTC
Environment
instack-undercloud-5.0.0-0.20160907134010.649dc3f.el7ost.noarch
openstack-ironic-conductor-6.1.1-0.20160907120305.0acdfca.el7ost.noarch
python-ironicclient-1.7.0-0.20160902094012.464044f.el7ost.noarch
python-ironic-tests-6.1.1-0.20160907120305.0acdfca.el7ost.noarch
python-ironic-lib-2.1.0-0.20160829084617.52b2d2f.el7ost.noarch
openstack-ironic-common-6.1.1-0.20160907120305.0acdfca.el7ost.noarch
puppet-ironic-9.2.0-0.20160905145838.d14c611.1.el7ost.noarch
openstack-ironic-api-6.1.1-0.20160907120305.0acdfca.el7ost.noarch
openstack-ironic-inspector-4.1.1-0.20160906074601.0276422.el7ost.noarch
python-ironic-inspector-client-1.9.0-0.20160902092624.6364bc9.el7ost.noarch

Comment 4 James Slagle 2016-10-18 20:18:30 UTC
this is a usability issue in that the user would have to retag all their nodes. jcoufal, do you think this is a blocker?

Comment 5 Dmitry Tantsur 2016-10-20 10:52:10 UTC
Adjusting the component. Also I don't believe this bug is a blocker at this stage.

Comment 6 Jaromir Coufal 2016-10-27 08:41:09 UTC
Answered above.

Comment 7 Jaromir Coufal 2016-10-27 08:42:20 UTC
Answered above.

Comment 8 Miles Gould 2016-11-01 13:19:15 UTC
Alternative workaround: instead of adding the new nodes to an existing instackenv.json file, create a new file and pass that as the argument to `openstack baremetal import` instead.

In general, I'm not convinced this is a bug: you've told Ironic to update the nodes according to the information given in instackenv.json, and it's done exactly that. I can try special-casing properties/capabilities in the update process, but I think there's a good chance it won't be accepted upstream.

Comment 9 Miles Gould 2016-11-01 15:49:50 UTC
Sasha, can you attach the two instackenv.json files (before and after) that you were using?

Comment 10 Miles Gould 2016-11-02 15:04:14 UTC
Looking at the instackenv.json file from a recent OSPd 10 install, I see that it explicitly includes an entry for each node's capabilities. The logic in the code is "if an entry is not specified in the file, leave it as it is; if it is specified, replace what's there with the version in the file". So blowing away the node's existing capabilities and setting them to what instackenv.json specifies is exactly the intended behaviour.

We could special-case properties/capabilities to request the existing entry and merge it with what's specified in instackenv.json, but that would IMHO be weird and brittle. Given the existence of a simple workaround (create a new file for the new nodes, and pass that as the argument to `openstack baremetal import`) we should keep the logic simple, uniform and intelligible.

Is there any documentation which suggests that node capabilities will be preserved across `openstack baremetal import` calls? If so, the right thing would IMHO be to fix that to match the existing semantics.

Comment 11 Amit Ugol 2018-05-02 10:50:20 UTC
closed, no need for needinfo.