The trouble with EnvironProvider.InstanceId()

[Jeroen Vermeulen]

On 03/15/2013 04:12 PM, William Reade wrote:
> On Fri, 2013-03-15 at 08:56 +0000, roger peppe wrote:

Thanks for getting deeper into this.  There is much here that I don't
understand, of course, so please forgive any stupidities on my part:


> Hmm, I made that change on the understanding that the MAAS instance id
> was written to disk (er, *somewhere*) in a reliable way. Was that belief
> not accurate?

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.

Our provider uses a node's URI on the MAAS API as its instance ID.  It
happens to contain the MAAS "system ID" as exposed on the metadata
service, so it's not _quite_ as disjoint as juju machine IDs are from
juju instance IDs, but we'd need more information than just the system
ID to reconstruct the whole instance ID.

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.


>> For instance, the first time an Environ becomes valid after the
>> provisioner has started, it could check that machine 0 is unassigned
>> and, if so, assign it the current instance (obtained with
>> Environ.CurrentInstanceId),
>> before continuing as usual.
>>
>> It's not as nice as the current solution (what's that bootstrap-specific code
>> doing in provisioner?!) but seems like it would work ok as long as we
>> have at most one bootstrap machine, something I suspect is unlikely
>> to change, even in a HA world.
> 
> The alternative perspective, to which I am sympathetic, is that this
> "bootstrap-specific" code is just as much provisioner-specific, in that
> its core purpose is to prevent the provisioner from going crazy. A
> couple of us discussed this in Atlanta, and there seemed to be rough
> agreement that it was a reasonable approach.

If all there is to it is a way to distinguish bootstrap instances from
run-of-the-mill instances, then it does sound to me, layman, as if
machine ID is the more appropriate criterion to distinguish them by.

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.


Jeroen