The trouble with EnvironProvider.InstanceId()

[roger peppe]

On 15 March 2013 10:21, Jeroen Vermeulen <jtv at canonical.com> wrote:
>>> 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.

currently there is unfortunately no way to determine a machine
id from a provider instance. it's not unfeasible to do in some circumstances
(at least in ec2, the bootstrap machine could be tagged as such
when bootstrapping), but even then, what should the provisioner
do if it finds two such machines?

> 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?

actually there's no problem there, because the bootstrap code
actually creates the Machine in the state (thus using "juju proper"
to generate the machine id).

that said, i don't have a problem with hardcoding knowledge about
machine 0 in this case - i think it's the only case where we cannot
associate information about the new machine with the instance id
(because the state isn't already there to set it in, and we can't
change an instance's cloudinit data *after* finding out that instance's id)