The trouble with EnvironProvider.InstanceId()

[roger peppe]

On 15 March 2013 13:34, John Arbash Meinel <john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ...
>
>> 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
>
> I do know we were poking around with this because of troubles on HP
> Cloud. Specifically, you *cannot* get the openstack UUID from the HP
> metadata server, you can only get the ec2-compatibility instance-id.
> However, you're not "supposed-to" be able to talk to the openstack
> APIs using the ec2 instance-id. (There is an ugly hack where you can
> decode the instance-id as a hex number and talk to pre-folsom
> openstack APIs using the decimal representation.)
>
> The key observation, was that until juju client connects to the
> provider for the first time, the provider doesn't have credentials to
> talk to the Environ (ec2/openstack). And the client can tell the
> provider what its InstanceId is at the same time that it is telling
> the provider what the credentials are.
>
> Just changing the code is a bit clumsy, because of what state is known
> where. We know the client has all the information, because it just
> grabbed the InstanceId from object storage to then lookup the IP
> address of the state server machine. But that information isn't on the
> objects that write the SecretAttrs to the mongo machine.

This does sound like a reasonable approach, but as you say,
the thing connecting to the state and pushing the secrets for
the first time doesn't actually know about the bootstrap instance
(or even if there *is* a bootstrap instance).

We could change the Environ.StateInfo method to return the
instance id of the instance we're connecting to (then updateSecrets
could set the instance id of machine 0 appropriately before pushing
the secrets), but this feels like breaking abstractions that really don't need
to be broken, and potentially constraining future provider implementations
and juju configurations.

I think I'm happy if the provisioner, which also has access
to the Environ after secrets have been pushed, can determine
whether a given instance id actually refers to itself and do the
same thing. It's the provisioner that needs to know, after all.

Perhaps rather than providing Environ.CurrentInstanceId and
comparing that, it might be cleaner to provide
a environs.Instance.IsCurrent method to determine if the given
instance is the one we're running on. In most implementations
it would probably do the same thing under the hood.

Thoughts?

  rog.