The trouble with EnvironProvider.InstanceId()

[William Reade]

On Fri, 2013-03-15 at 17:21 +0700, Jeroen Vermeulen wrote:
> Effectively, no.  We may well have a MAAS-assigned ID on disk somewhere,
> but that's not quite the same ID that the MAAS juju provider uses for an
> instance ID.

Blast. I recall there was confusion about what an "id" was in the python
provider; sorry about that.

> I'm not ruling out the possibility of reverse-engineering that
> information from the cloudinit config, but MAAS produces these URLs and
> we'd like to avoid coding up detailed knowledge of their structure in Juju.

We definitely shouldn't do that :).

> When it comes to "what's bootstrap-specific code doing in the
> provisioner," doesn't the converse already apply to the way the
> bootstrap system's machine ID is hard-coded to 0?  How does
> Environ.Bootstrap() know that that ID won't conflict with one that juju
> proper generates?  ISTM they already share implicit knowledge about how
> machine IDs are generated, and making that knowledge explicit could only
> be an improvement.

Yeah. We have made some effort to avoid relying on machine id 0 in the
juju-core codebase, but it has not been entirely successful.

The various Environ implementations are independently responsible for
knowing the correct value (in the args for the initial machine agent);
the jujud bootstrap command sets it to 0; and handling for
state.AssignLocal assumes 0 as well. If the second special case is
implemented in the provisioner instead of in jujud, we're theoretically
exactly as bad as we were before; but, in practice, I think this change
would also let openstack work better.

Would someone from blue weigh in here? AIUI this would make it possible
to use pre-grizzly openstack without additional work on instance-id
handling; if so, and if that's work you have planned anyway(?), it seems
it would be good to implement the provisioner change instead. I'm not
sure I have space to do this imminently myself, but I'd be glad to
advise if someone else were to pick up this work and was not familiar
with the affected parts.

Cheers
William