[KNIFE-335] Wait for RackConnect and/or Service Level automation before bootstrapping #42
Conversation
…ore bootstrapping
…g is a good thing.
Thanks Chris for whipping this into shape. |
What's the status of this pull request? It'd be great to see this merged in if it's working. |
Right now Rackspace is managing the pull requests and tickets for knife-rackspace. I'll let @krames weigh in on their plans for testing and merging the ticket. Rebasing to the newly released 0.7.0 will make it easier to merge and we'll also need to get the CLAs for @chrissnell and @kief to be able to merge it into knife-rackspace. |
I worked on this as a Rackspace employee. Does Rackspace have an existing CLA that covers me? |
@chrissnell I don't believe so. If you are not longer a Racker, you will need to sign your own contributor agreement (http://wiki.opscode.com/display/chef/How+to+Contribute). Alternatively, you can just wait for me to bless it. If you are a racker send me an email and I can look into getting you added to our contributor agreement. |
Before this gets committed, I need to do some surgery on this PR. Everything after (and including) diff d887825 needs to get moved to a separate PR. |
@chrissnell Thanks for letting me know! |
General question: shouldn't this logic be pushed into Fog? |
OK, the PR is cleaned up and ready for whatever you guys want to do with it. Thanks to @j2sol for the git surgery help. |
@chrissnell Can rebase this? Thanks! |
Hey @chrissnell @krames is there an internal JIRA ticket for this on tickets.opscode.com? If not, could you please create one, link to this PR, link this PR to the ticket, and mark the ticket as "Fix Provided" in JIRA? |
@chrissnell Can you answer @sethvargo question? Thanks! |
Hi @sethvargo, JIRA ticket has been create: http://tickets.opscode.com/browse/KNIFE-335 I wasn't able to mark it as 'Fix Provided'. Perhaps you can do that on your end. |
FWIW, we're using @chrissnell 's branch very actively here at $job, and it's working great. I've tested the following, all of which work as expected:
Thanks to @chrissnell and @kief for their work on this -- it's much appreciated. 👍 |
I've been actively using @chrissnell 's branch too over the past few weeks and it's working well. Any progress on getting this merged? |
Thanks! Merged to master. @chrissnell @kief @krames If another pull request could be made with an update to the README explaining the use cases for this that would be very useful. |
@mattray I will follow up with Chris on the docs. Thanks for the merge! |
did this really get merged to master? I can't see it there. |
@DavidWittman Let me have a look. |
[KNIFE-335] Wait for RackConnect and/or Service Level automation before bootstrapping
I am not quite sure what happened here. I have reopened the PR and merged it into master. @mattray Can you cut another knife-rackspace release? Thanks! |
0.8.1 was just pushed out with this fix. |
Add the ability to wait for automation that runs on Managed Service Level Rackspace accounts. Similar to the functionality in knife: chef-boneyard/knife-rackspace#42 Fixes test-kitchen#54.
http://tickets.opscode.com/browse/KNIFE-335
I took kief's PR ( #35 ) and made some changes to make it work more reliably with a variety of different Rackspace Cloud environments.
Here's what I fixed:
kief's code only checks Chef::Config[:knife] to see if :rackconnect_wait is set. The CLI option was essentially being ignored. Fixed.
Next, I noticed that kief's code required that both the RackConnect automation and the Service Level automation had to be complete before moving on. For users of RackConnect who use the un-managed service level, this resulted in a hang waiting for rax_service_level_automation == 'Complete', which would never happen. I fixed this by splitting the service level automation wait into it's own CLI option, --rackspace-servicelevel-wait. I don't have a Managed service level account so I can't test this, unfortunately. Can someone with Managed Cloud with and without RackConnect test this?
Finally, I noticed that the code hangs waiting for sshd to open. This is because Fog's server.addresses data structure only contains the pre-RackConnect public IP. Once the RC automation runs, the server can only be accessed via the new "access IP". My fix is to pull this access IP using Fog's server.access_ipv4_address method and use this value if it exists.
Some discussion of this issue can be found here: fog/fog#1507 ... I believe that a more long-term fix in Fog itself is being discussed.
Big ups to Kief for creating the initial PR.