No error handling / logging in MetadataConfig

[dietervdw-spotify]

google-cloud-java/google-cloud-clients/google-cloud-core/src/main/java/com/google/cloud/MetadataConfig.java

Line 83 in 44db769

// ignore

Calls to metadata service can fail. This causes a NPE a little further.
This is a prime example of crappy error handling.

So now this is failing for some reason for me (while I can perfectly curl the service), and I don't have a clue. Logging the actual error would be much appreciated!

Not making a PR for this since I don't know what your error handling policy is.
I'd just throw this up all the way?

[dietervdw-spotify]

My issue actually seems to be caused by #4269 .

[ajaaym]

@dietervdw-spotify can you please provide sample of code where its failing for you?

[dietervdw-spotify]

@ajaaym This was happening on version 0.70.0-alpha, it seems like that code path is now updated to handle the resulting null value.

However just swallowing errors is just bad. In my case apparently due to bug #4269 the metadata hostname didn't resolve to the actual google metadata service.
In version 0.70.0-alpha this caused an NPE, in the newer version this will just silently break anything that depends on MetadataConfig automatic metadata.

I guess it depends on Google's logging policy, but at least logging something on DEBUG or a one-line warning would help immensely!

[ajaaym]

@dietervdw-spotify do you mean http://metadata.google.internal is not getting resolved in GCE/GKE? error is getting silently ignored to avoid printing noise when not running in GCE/GKE mode and http://metadata.google.internal should always get resolved from GCE/GKE.

[dietervdw-spotify]

@ajaaym : In a previous version the metadata hostname was specified as metadata instead of metadata.google.internal and that failed to resolve on our GCE machines for some reason.

I personally don't agree with suppressing errors and I think it's bad practice. There's a lot that can go wrong on a network, and it would be great to have a trace afterwards if something breaks.

For example in the Logback Stackdriver appender: if the automatic resolution fails for some reason, logs will get sent to resource 'global' instead of using the right resource type and metadata tags.
That is wrong on so many levels:

• Logs get sent to the wrong destination and get the wrong tags, making them effectively get lost
• This will not recover until the application is restarted

So if there's a small network glitch during startup, my application is now running with a completely wrong configuration. I'd rather have startup fail and print a big fat error in that case.

Maybe the Stackdriver Logback appender is not using this class in the right way then?
In any case, something seems very wrong to me here.

[ajaaym]

@dietervdw-spotify This can not be done bcz if logback is used outside GCE/GKE then it becomes reentrant and can not fail startup as well in that case. Closing this for now as upgrading to latest version resolves this. Please feel free to reopen if you think otherwise.