Fix LXC containers on MAAS

Fix LXC containers on MAAS

We can't get a real CI framework soon enough.

When the provisioner was updated to use the API, this
accidentally broke LXC on MAAS, as the secret attributes
are stripped from the environment config for non-manager
nodes. This makes a completely invalid MAAS config, which
means the LCX provisioner task never starts.

There was no easy fix for this, so the correct one had
to do.  That is to provide an API call to get what the
containers actually need, and not have them depend on
things they don't need.

I took this opportunity to also simplify the parameters
for the StartContainer call.

https://code.launchpad.net/~thumper/juju-core/maas-lxc/+merge/193405

(do not edit description out of merge proposal)

[thumper, 2013-10-31 11:41:39]

Please take a look.

[dimitern, 2013-10-31 11:50:30]

Very nice! LGTM

https://codereview.appspot.com/20220043/diff/1/state/apiserver/provisioner/pr...
File state/apiserver/provisioner/provisioner.go (right):

https://codereview.appspot.com/20220043/diff/1/state/apiserver/provisioner/pr...
state/apiserver/provisioner/provisioner.go:185: // ContainerConfig returns the
current environment's configuration.
Fix the doc string please.

[thumper, 2013-10-31 11:55:01]

And thanks.

https://codereview.appspot.com/20220043/diff/1/state/apiserver/provisioner/pr...
File state/apiserver/provisioner/provisioner.go (right):

https://codereview.appspot.com/20220043/diff/1/state/apiserver/provisioner/pr...
state/apiserver/provisioner/provisioner.go:185: // ContainerConfig returns the
current environment's configuration.
On 2013/10/31 11:50:30, dimitern wrote:
> Fix the doc string please.

Done.

[john2, 2013-10-31 12:41:34]

LGTM

https://codereview.appspot.com/20220043/diff/1/state/api/provisioner/provisio...
File state/api/provisioner/provisioner.go (right):

https://codereview.appspot.com/20220043/diff/1/state/api/provisioner/provisio...
state/api/provisioner/provisioner.go:161: var result params.ContainerConfig
I would actually think that ContainerConfig would just return the params struct,
rather than splitting it back out into individual args.
That way, if we do decide to add things, we don't have to change the Client API

https://codereview.appspot.com/20220043/diff/1/worker/provisioner/lxc-broker.go
File worker/provisioner/lxc-broker.go (right):

https://codereview.appspot.com/20220043/diff/1/worker/provisioner/lxc-broker....
worker/provisioner/lxc-broker.go:65: providerType, authorizedKeys,
sslVerification, err := broker.api.ContainerConfig()
Just a question, would it make sense to move this API call up a level instead of
here? Most of our API calls occur in the other layer where the watchers are
going on.

Nothing you have to change, just something I thought of.