RackSpace support

[Martin Packman]

Thanks for going through and listing all these issues Patrick. When I
looked last time around, the lack of a metadata service (so, nay way
to get data to cloud-init) and to a lesser extent security groups

On 28/08/2013, Patrick Hetu <patrick.hetu at gmail.com> wrote:
> Hello,
>
> I've tried to make Juju-core to work with RackSpace and it's not but
> here's the details of my quest:
>
> First, getting the list of the Flavors give back a 203 HTTP status
> (Non-Authoritative Information) instead of the expected 200.

Should treat all 2XX codes as success, lp:1218215.

> There is no SecurityGroup in RackSpace.

If the global firewaller mode isn't enough to work around this, we
probably need a disabled firewaller mode too. What did you do for
this?

> The catalog returned with the token by Keystone had:
>
> * a different tenantid for object-store and compute

That's odd. What impact did this actually have?

> * The compute service twice (v1.0, v2)

We should pick out the right version in goose, lp:1218218.

> The retry-after header is a complete date/time string instead of the
> expected float.

Apparently valid, lp:1218223.

<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.37>

> In RackSpace's Ubuntu images cloud-init is not installed by default
> so you have to create a custom image and bootrap with it.
> For that you need to create public container (cdn) with the metadata.
>
> I discovered that the userdata field doesn't exist in the API but there
> is a field named "personality" that is doing more or less the same thing.

It's not the same thing really, but can be used to do file injection.
However, without the metadata service, don't you still need to tell
cloud-init about the alternative data source?

> So I've put the user-data in the personnality field but now
> I'm getting a 413 error (Request Entity Too Large).

Did the cloud-config get gzip compressed, or was it given as raw yaml?

Martin