The trouble with EnvironProvider.InstanceId()

roger peppe roger.peppe at canonical.com
Fri Mar 15 08:56:38 UTC 2013


On 15 March 2013 04:43, Jeroen Vermeulen <jtv at canonical.com> wrote:
> Hi all,
>
> There's this new method on the EnvironProvider interface: InstanceId().
>  It's meant to return the InstanceId of the machine it's being executed on.
>
> This is problematic for us.  In order to know the instance id, we need
> to know what MAAS we're talking to.  The Environ would know that, but
> definitely not the EnvironProvider.  The EC2 provider does not have this
> problem because there, the address of the meta-data service is
> hard-coded as a global constant.
>
> Ian suggests that with a bit of refactoring, perhaps the call to
> InstanceId() could be delayed, so that it could live in Environ instead
> of EnvironProvider.  Would that be a possibility?
>
> Or does anyone have any other suggestions?  One thing we thought of was
> to look in the machine's cloudinit config and reverse-engineer the URL
> for the metadata API from the file URLs included there.  But it's not
> very robust, clean, or testable.

As far as I know, the only reason we need EnvironProvider.InstanceId
is so that we know the instance id to associate with the bootstrap machine
in the state, so that the provisioner doesn't see this instance that it
doesn't know about and kill it, killing the bootstrap machine.

How about a different approach? If there's a way for the provisioner to
tell that it is seeing the bootstrap instance, then it could avoid
killing that instance, and instead associate it with the bootstrap machine.

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 other possibility, probably not even worth mentioning, is to send
the provider keys in the bootstrap machine's cloudinit, thus making
it possible for the bootstrap machine to create an Environ and find the
current instance id before bootstrapping the state.

  cheers,
    rog.



More information about the Juju-dev mailing list