GCLOUD_PROJECT is deprecared in favor of GOOGLE_CLOUD_PROJECT + avoid using it at all

[steren]

The sample relies on the GCLOUD_PROJECT environment variable (see https://github.com/GoogleCloudPlatform/nodejs-getting-started/blob/master/2-structured-data/config.js#L27)

However, this variable is now deprecated and is not present in newer versions of the Node.js runtimes for App Engine.

Instead, developers should rely on the GOOGLE_CLOUD_PROJECT environment variable.

[jcapogna]

Aha. I'm just going through these tutorials and I found myself having to manually set the GCLOUD_PROJECT env variable in my startup script.

The google cloud libraries being used still seem to want GCLOUD_PROJECT to be set. At least I was getting errors about GCLOUD_PROJECT before I started manually setting it. Does this mean we need to set GCLOUD_PROJECT and GOOGLE_CLOUD_PROJECT or do the new libraries expect GOGOLE_CLOUD_PROJECT?

[steren]

Actually, the client library teams tells me that the best practice is to leverage the metadata server present on all GCP runtimes.

This means that if you have a client object, most languages expose it as a property on the client, e.g, storage_client.project.

The GOOGLE_CLOUD_PROJECT is not present on many GCP runtimes (e.g. GKE or GCE)

[zbjornson]

best practice is to leverage the metadata server present on all GCP runtimes

google-auth-library (for Node.js) forks a process to run gcloud config to get the project ID, and last I looked, it prioritizes that over using the metadata server:

https://github.com/googleapis/google-auth-library-nodejs/blob/37bb8c7cd0a6501103274284d9cddd6816cc881e/src/auth/googleauth.ts#L177-L182

Forking a process isn't safe on Linux because of nodejs/node#25382; we routinely get crashes from the GCP client libs. I think that should be addressed before Google globally recommends not using an env var. An env var is also faster than making a req to the metadata server.

[GitTom]

I'm no longer able to access GCLOUD_PROJECT or GOOGLE_CLOUD_PROJECT on the Node 10 runtime in Firebase Functions or Google Cloud Functions.

This is consistent with the warning/advice given above, but it is a problem for me.

It seems that the metadata server is now the recommended solution, but that puzzles me because my understanding was that that is only for GCE.

Never-the-less I tried to use it (via the 'gcp-metadata' node module which is quite widely used) with GCF and FBF and I think I tried it with Cloud Run too, and it failed to work on all of them. I could keep trying to debug the problem on those, but I didn't even think it was supposed to work on them.

I gotta' say, just reading 'process.env.GOOGLE_CLOUD_PROJECT' sure was simple. If getting rid of it was motivated by making these platforms conform more closely to k-native then I applaud that motivation, but am not sure how to proceed.

[steren]

I have this snippet that shows how to get the project-id from the metadata server in Node.js: https://gist.github.com/steren/6bc5e011632e8c0f13cf8578d7944d97

[GitTom]

Yes, that does work for me, thank you. (It doesn't work in emulator, but I expected that.) I'm not sure why the gcpMetadata module didn't work in Functions and this does - but I'm glad to have something that does.

It is unfortunate, in the context of FaaS services, to have to do a request each time for a static value, but I guess there are options to minimize that cost: I will load it into global so it only has to be requested once per instance, and I guess one could setup something in deployment to set an env var with the desired static metadata values.

[steren]

Another alternative is for you to set the project name as a user environment variable at deployment time.

[GitTom]

Yes, that is what I meant in my last sentence (but I think my wording was a bit unclear) and I think it is a good solution.

[fhinkel]

Obsolete with planned rewrite of the tutorial.