The trouble with EnvironProvider.InstanceId()

[John Arbash Meinel]

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

I don't know if this makes anything clearer to JTV, but it should
hopefully ring some bells for William.

John
=:->


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFDI14ACgkQJdeBCYSNAAO27wCbBCVEKV1k0tLIVb0UMrfmyy0T
hlgAnRJQXwTYCSA9zi3kKJXW3DruCk7n
=J3cH
-----END PGP SIGNATURE-----