Rely on IP address for metadata server

[bshi]

The client code uses the hard-coded IP and "metadata" to contact the GCE metadata host. For maximum portability, don't rely on name resolution.

We launched the default container found at https://index.docker.io/u/google/docker-registry/ on GCE and discovered the container could not resolve "metadata" and /etc/hosts is not writable in the image mentioned. As a result, the public image was unusable for us.

[obeleh]

I'm having the same problem in #7

[proppy]

Does metadata.google.internal resolve?

[obeleh]

Yes it does

[proppy]

So maybe a better fix is to always use the FQDN.

[proppy]

/disclaimer I'm not a maintainer of this project: but very interested by any issue you may encounter with google/docker-registry.

I enabled the issue tracker on https://github.com/GoogleCloudPlatform/docker-registry/issues, if you have any issues specific to using the registry on GCE (or on your laptop with gcloud credentials).

[obeleh]

Ah yes I was sad that this option wasn't enabled yet. Thanks!!!

[bshi]

@proppy Given that the module already defines METADATA_SERVER = 'http://169.254.169.254', it seems most reliable not to rely on any particular name resolver.

[obeleh]

I would opt for some fallback mechanisms. Baking in an IP address into code is creepy.

[bshi]

Creepy or not, the reality is that that magic IP is probably here to stay. It's no accident that it happens to match the AWS metadata IP that's been around for a decade+. In this case, it's no better than a magic hostname; it's likely worse since using a hostname forces the logic to go through one more unecessary name resolution code path that may or may not be there.

https://developers.google.com/compute/docs/metadata http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html

[obeleh]

Ok I agree with you. But the reason for hard coding an ip shouldn't be "because we always did it that way".