Fix RunServerOpts Userdata

Fix RunServerOpts Userdata

The UserData attribute of RunServerOpts was []byte, but it needs to be string to make juju bootstrap work.

All the current nova tests simply ignore this attribute - they pass in nil. I tried writing a test to set up
a cloud init config with a simple script command and introduced a deliberate error but the nova create server
operation succeeded nonetheless. Yet the huge cloud init script used by juju bootstrap fails. So I'm not sure
how to set up a small, self contained test in goose for the userData attribute. The code in this merge proposal
makes juju happy though, apart from that fact that Canonistack sometimes gives a "Resource limit exeeded" error
when bootstrapping a juju instance.

https://code.launchpad.net/~wallyworld/goose/RunServer-userData-fix/+merge/145539

(do not edit description out of merge proposal)

[wallyworld, 2013-01-30 04:50:43]

Please take a look.

[jameinel, 2013-01-30 06:49:23]

I think this is the right fix. ISTR that if you use []byte in a data structure,
JSON.Marshal(struct) will encode "foo" as [102, 111, 111].

So I like the change, but I'd really like to see a test for it, since it is one
of those "everything seemed fine but failed in reality" issues.

[dimitern, 2013-01-30 06:57:14]

On 2013/01/30 04:50:43, wallyworld wrote:
> Please take a look.

LGTM, but why did you move UserData out of the RunServerOpts struct?

[jameinel, 2013-01-30 07:12:45]

On 2013/01/30 06:57:14, dimitern wrote:
> On 2013/01/30 04:50:43, wallyworld wrote:
> > Please take a look.
> 
> LGTM, but why did you move UserData out of the RunServerOpts struct?

I don't think he removed it, he just changed its type from a []byte to a string.
However, if you still want to pass in a []byte, you can't just shove it in the
struct, because that slot now holds a string.

Then again, we shouldn't really be using the struct for bytes-on-the-wire as the
same struct for passing-parameters-to-the-function. Because of differences like
this.

Maybe it means the conversion to string should be done at a higher level (before
passing it into this function). But it does look like the other conversions are
being done at this level.

[dimitern, 2013-01-30 14:44:22]

On 2013/01/30 04:50:43, wallyworld wrote:
> Please take a look.

NOT LGTM - as discussed, this change is not needed, because the problem is we
shouldn't encode userData in base64, as being []byte this is done automatically
by go (see the docs). I have a CL which just removes the encoding and will
propose it shortly.