cmd/jujud: create machine/0 on bootstrap

cmd/jujud: create machine/0 on bootstrap

During initzk, machine/0 needs to be created in the state.

https://code.launchpad.net/~dave-cheney/juju-core/go-cmd-jujud-set-machine-id/+merge/115051

(do not edit description out of merge proposal)

[dave_cheney.net, 2012-07-16 01:17:50]

Please take a look.

[rog, 2012-07-16 11:30:09]

On 2012/07/16 01:17:50, dfc wrote:
> Please take a look.

LGTM

[fwereade, 2012-07-16 22:45:15]

Can we put this code inside state.Initialize please? I'd prefer not to write the
/initialized node until we're really completely initialized...

Digression:

FWIW, we should IMNSHO be writing /environment inside Initialize as well; and we
should be doing this by replacing --env-type with --env, which would take a
base64-encoded environment configuration (without secrets ofc).

As it is, we don't even have enough information to fill in the generic
environment settings at initzk time: we pass env-type explicitly, and we can
infer default-series and authorized-keys from the machine we're running on, but
we don't know the environment name (which is required for a valid basic
provider-independent config).

IMO we should be explicit about all these things; and IMO doing so will *also*
be a win when we implement constraints (which should also go into /environment,
and need to be sent at bootstrap time; from experience, it is a bloody hassle
changing how we bootstrap, and we should make sure that at *least* we have a
channel to which it will be easy to add the things we *know* we'll need).

If you plan to implement this and any of the above is unclear, try to grab me
sometime and I'd be more than happy to talk about it; I did some of this in the
python, and in hindsight Did It Wrong, and I may be able to save you from
similar mistakes.

[dave_cheney.net, 2012-07-16 23:49:36]

On 2012/07/16 22:45:15, fwereade wrote:
> Can we put this code inside state.Initialize please? I'd prefer not to write
the
> /initialized node until we're really completely initialized...

Would I be able to get your to agree to a compromise of a TODO, a bug and a
promise to return to this discussion later ? I agree that this is potentially
racy, but we get away with it because cloud init will not setup the upstart jobs
for the PA and the MA until initzk finishes.

> FWIW, we should IMNSHO be writing /environment inside Initialize as well; and
we
> should be doing this by replacing --env-type with --env, which would take a
> base64-encoded environment configuration (without secrets ofc).
> 
> As it is, we don't even have enough information to fill in the generic
> environment settings at initzk time: we pass env-type explicitly, and we can
> infer default-series and authorized-keys from the machine we're running on,
but
> we don't know the environment name (which is required for a valid basic
> provider-independent config).
> 
> IMO we should be explicit about all these things; and IMO doing so will *also*
> be a win when we implement constraints (which should also go into
/environment,
> and need to be sent at bootstrap time; from experience, it is a bloody hassle
> changing how we bootstrap, and we should make sure that at *least* we have a
> channel to which it will be easy to add the things we *know* we'll need).
> 
> If you plan to implement this and any of the above is unclear, try to grab me
> sometime and I'd be more than happy to talk about it; I did some of this in
the
> python, and in hindsight Did It Wrong, and I may be able to save you from
> similar mistakes.

[dave_cheney.net, 2012-07-16 23:51:55]

> FWIW, we should IMNSHO be writing /environment inside Initialize as well; and
we
> should be doing this by replacing --env-type with --env, which would take a
> base64-encoded environment configuration (without secrets ofc).
> 
> As it is, we don't even have enough information to fill in the generic
> environment settings at initzk time: we pass env-type explicitly, and we can
> infer default-series and authorized-keys from the machine we're running on,
but
> we don't know the environment name (which is required for a valid basic
> provider-independent config).
> 
> IMO we should be explicit about all these things; and IMO doing so will *also*
> be a win when we implement constraints (which should also go into
/environment,
> and need to be sent at bootstrap time; from experience, it is a bloody hassle
> changing how we bootstrap, and we should make sure that at *least* we have a
> channel to which it will be easy to add the things we *know* we'll need).
> 
> If you plan to implement this and any of the above is unclear, try to grab me
> sometime and I'd be more than happy to talk about it; I did some of this in
the
> python, and in hindsight Did It Wrong, and I may be able to save you from
> similar mistakes.

This is valuable commentary, but I think it should really be addressed outside
the context of this proposal. Would you care to open a bug for it ?

[dave_cheney.net, 2012-07-17 00:09:49]

Please take a look.

[dave_cheney.net, 2012-07-17 22:40:19]

Please take a look.

[niemeyer, 2012-07-17 23:04:58]

LGTM

[niemeyer, 2012-07-17 23:08:37]

For the record, the /initialized node was really a mechanism to prevent having
to catch errors on every single action that has to create or read a fundamental
node that doesn't exist (/machines, /services, etc). Stuff like AddMachine are
indeed part of "initialization" as in the "initzk" command, but there's no
reason for AddMachine itself to be protected by that same mechanism. This is
usual manipulation of the state, and should be handled as usual by watchers,
etc.

[dave_cheney.net, 2012-07-17 23:14:01]

*** Submitted:

cmd/jujud: create machine/0 on bootstrap

During initzk, machine/0 needs to be created in the state.

R=rog, fwereade, niemeyer
CC=
https://codereview.appspot.com/6408047