Bug 1234338 - AHC-matching overrides already deployed nodes tags
Summary: AHC-matching overrides already deployed nodes tags
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: Director
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ga
: Director
Assignee: John Trowbridge
QA Contact: Alexander Chuzhoy
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-22 11:59 UTC by Jaromir Coufal
Modified: 2015-08-05 13:55 UTC (History)
4 users (show)

Fixed In Version: ahc-tools-0.1.1-5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-05 13:55:04 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Gerrithub.io 237390 None None None Never
Red Hat Product Errata RHEA-2015:1549 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform director Release 2015-08-05 17:49:10 UTC

Description Jaromir Coufal 2015-06-22 11:59:13 UTC
Description of problem:
ahc-matching tool rewrites tags at already deployed nodes. Soo for example for the use case where I am scaling nodes, I get in troubles that I have no available hosts because they were tagged wrong (despite the fact I do have enough hosts).


Example:
* state file describes: 1 controller, 1 compute, 1 storage

-> after running ahc-match and deploying I get following situation:

host_1 tag:control deployed:control
host_2 tag:compute deployed:compute
host_3 tag:storage deployed:storage
host_4 tag:--      deployed:--

-> I need to scale out computes:

* state file describes: 1 controller, 2 compute, 1 storage

-> ahc-match script does following

host_1 tag:control deployed:control
host_2 tag:compute deployed:compute
host_3 tag:compute deployed:storage
host_4 tag:storage --

You can see the problem that my deployed storage node was re-tagged as compute.


Version-Release number of selected component (if applicable):
2015-06-17.2 http://openstack.etherpad.corp.redhat.com/rhel-osp-director-puddle-2015-06-17-2

How reproducible:


Steps to Reproduce:
1. Deploy 1 control, 1 compute, 1 storage
2. Change state file for 2 computes
3. Conflict (as described above)

Actual results:
host_1 tag:control deployed:control
host_2 tag:compute deployed:compute
host_3 tag:compute deployed:storage
host_4 tag:storage --

Expected results:
host_1 tag:control deployed:control
host_2 tag:compute deployed:compute
host_3 tag:storage deployed:storage
host_4 tag:compute --

Comment 3 John Trowbridge 2015-06-23 18:39:23 UTC
Thanks Jaromir for reporting this. I put a patch upstream that should fix this: https://review.gerrithub.io/#/c/237390/

Note, the state file should be the new nodes we want to match. So in your example above, on the first run we would have:

* state file describes: 1 controller, 1 compute, 1 storage

And on the second run (to scale up by 1 compute) we would have:

* state file describes: 1 compute

This is still broken without the patch above though.

Comment 6 Alexander Chuzhoy 2015-07-21 13:30:58 UTC
Verified:

Environment:
instack-undercloud-2.1.2-21.el7ost.noarch
openstack-ironic-conductor-2015.1.0-9.el7ost.noarch
python-ironicclient-0.5.1-9.el7ost.noarch
ahc-tools-0.1.1-5.el7ost.noarch
openstack-ironic-api-2015.1.0-9.el7ost.noarch
python-ironic-discoverd-1.1.0-5.el7ost.noarch
openstack-ironic-common-2015.1.0-9.el7ost.noarch
openstack-ironic-discoverd-1.1.0-5.el7ost.noarch


1. Installed ahc-tools.
2.  sudo  sed 's/\[discoverd/\[ironic/' /etc/ironic-discoverd/discoverd.conf > /etc/ahc-tools/ahc-tools.conf
3. chmod 0600 /etc/ahc-tools/ahc-tools.conf
4. sudo cp /etc/ahc-tools/edeploy/compute.specs /etc/ahc-tools/edeploy/foo.specs
5. sudo echo [('foo','*')] > /etc/ahc-tools/edeploy/state
6. run 'ahc-match'
7. ironic node-show [node-uuid]|grep -A2 properties

Didn't see anything like "profile:foo"

Comment 8 errata-xmlrpc 2015-08-05 13:55:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2015:1549


Note You need to log in before you can comment on or make changes to this bug.