Wait for RackConnect before bootstrapping

[kief]

Added an option to "server create" that should be used when using RackConnect. It will wait until RackConnect setup has completed before bootstrapping, otherwise the chef run may break RackConnect monitoring and potentially cause other unhappiness.

[brianseeders]

There's also an "mckick" script that runs on Managed Cloud servers, and it sets up various things for the Rackspace support team.

I believe it runs after RackConnect is successfully set up, and can fail if you are bootstrapping at the same time.

Metadata key "rax_service_level_automation" I think is related to this. Maybe a check for this should also be added in a similar way? As a note, it does seem to take a while for mckick to complete, so waiting for this may significantly delay bootstrapping.

[kief]

@brianseeders You're right, I've added a check for rax_service_level_automation. I did see issues such as a failure to install packages because the apt cache was locked.

You're also right, it takes a hell of a long time for this stuff to finish, I've had to bump up the timeout from the default 10 minutes to 20 minutes.

[rodrigdav]

It looks like this would only address V2 servers and not V1. Since in version one you have to check for a file to exist in the /tmp directory. Have you thought of maybe adding support for version 1 servers?

[chrissnell]

I found a couple of issues in this PR and fixed some of them.

First off, the code only checks Chef::Config[:knife] to see if :rackconnect_wait is set. The CLI option was essentially being ignored. I fixed this.

Next, I noticed that your code assumed 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.

Finally, I noticed that the code now hangs waiting for sshd to open. I believe that this is because the public IP has changed and Fog is unable to detect this or fetch the new IP. Some discussion of this issue can be found here: fog/fog#1507 ... I was not able to fix this bug yet.

I'm hesitant to send you a PR until I get everything working. My fork can be found here: https://github.com/chrissnell/knife-rackspace

[chrissnell]

OK, I now have knife-rackspace pulling and using the "access IP" via Fog if it's available. I've tested it with both RackConnect and pure Rackspace Cloud environment and it seems to be working now. The new PR that incorporates Kief's code and my patches can be found here: #42

[krames]

@kief Sorry about the delay in reviewing this. As it turns out @chrissnell has a slightly better implementation so I am going to recommend closing this.

Thanks for the contribution and again I am sorry about the delay.

@mattray Can you close this?

[mattray]

Thanks @kief