RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1221472 - Error message is not clear: Node can not be updated while a state transition is in progress. (HTTP 409)
Summary: Error message is not clear: Node can not be updated while a state transition ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: RDO
Classification: Community
Component: openstack-ironic
Version: trunk
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: Kilo
Assignee: Dmitry Tantsur
QA Contact: Toure Dunnon
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-14 06:35 UTC by Udi Kalifon
Modified: 2016-05-19 15:35 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-19 15:35:03 UTC
Embargoed:


Attachments (Terms of Use)
Ironic logs (43.58 KB, application/x-gzip)
2015-05-14 18:35 UTC, Udi Kalifon
no flags Details

Description Udi Kalifon 2015-05-14 06:35:42 UTC
Description of problem:
When trying to register nodes on a bare metal setup with "instack-ironic-deployment --nodes-json instackenv.json --register-nodes" I got:

Node 8598be72-9e78-4d80-a7be-fb4fb47eadb6 can not be updated while a state transition is in progress. (HTTP 409)

What's a "state transition"? The error message should be clear on what operation was attempted, what "state" the node is currently in, and what to do to resolve. Also, what state was the node left in as a result of the failure?

This error should not occur anyways, as this is a fresh clean install and it's the first time that I'm registering any nodes. They should not be in any state transition.


Version-Release number of selected component (if applicable):
openstack-ironic-api-2015.1-dev681.el7.centos.noarch
openstack-ironic-discoverd-1.1.0-0.99.20150506.1426git.el7.centos.noarch
openstack-ironic-common-2015.1-dev681.el7.centos.noarch
openstack-ironic-conductor-2015.1-dev681.el7.centos.noarch
python-ironicclient-0.5.1-post7.el7.centos.noarch
python-ironic-discoverd-1.1.0-0.99.20150506.1426git.el7.centos.noarch


Steps to Reproduce:
1. Install on RHEL7.1 with RHEL7.1 guest images according to the instructions in https://repos.fedorapeople.org/repos/openstack-m/docs/internal/master/basic_deployment/basic_deployment.html

Comment 1 Dmitry Tantsur 2015-05-14 07:22:32 UTC
Hi!

First of all, our node registration is not an atomic operation from Ironic pov, that's why this error can occur.

I'm pretty surprised, however, that you're seeing it, because I've implemented retries for ironicclient some time ago. How often is this reproducable? Also please provide ironic conductor and API logs for relevant time slice.

Finally, if you'd like to change the wording itself, please report it to launchpad with your considerations.
Thanks!

Comment 2 Udi Kalifon 2015-05-14 11:03:51 UTC
I opened the bug because I didn't understand what the error message wants from me, and I believe other users will also be baffled. To change the wording of the error message, I'd first have to find out what exactly was the problem... What do you mean by "I implemented retries"? What requires retries and why? If the discovery is not an atomic operation (I didn't expect that it was), can we at least make sure that in every step of the operation there would be error checking and user-friendly error messages?

Unfortunately the problem does not recreate and I don't have the logs. Sorry. I do see, however, a lot of "Authorization failed for token" messages in ironic-api.log. I checked that "keystone token-get" works. Why is ironic having a problem with its tokens?

Comment 3 Dmitry Tantsur 2015-05-14 11:07:41 UTC
Hmm, now I'm confused. We are not talking about discovery at all right now, are we? Anyway, both discovery and 'instack-ironic-deployment --nodes-json instackenv.json --register-nodes' in question are implemented via calling a bunch of Ironic commands. Message you're seeing is from Ironic meaning that Ironic is doing something on a node, when new request is issued. I've implemented retries in Ironic client to solve this problem, however, looks like it's not enough.

Re tokens, it's hard to tell with information provided. The most likely cause is not Ironic itself, but someone trying to access Ironic API with a wrong token.

Comment 4 Udi Kalifon 2015-05-14 18:35:47 UTC
Created attachment 1025557 [details]
Ironic logs

This happened to me again just now so I'm attaching the logs. Look at the end of the logs for the relevant time slice. It seems like this problem happens once, on fresh machines, and if you run the register command again it succeeds. Could it be that the database is installed unclean or something is not initialized?

Comment 5 Chandan Kumar 2016-05-19 15:35:03 UTC
This bug is against a Version which has reached End of Life.
If it's still present in supported release (http://releases.openstack.org), please update Version and reopen.


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