FR: when running locally, it would be nice if there is a way to pass custom credentials and project ID to dev appserver

[lesv]

There is apparently a way to pass app-id when you start up the GAE Java runtime locally. At the very least, it would be good (helpful to Veneer) if:

com.google.appengine.application.id System.property() were set. UPDATED by @chanseokoh: this property won't work.

[ludoch]

Btw, it used to be in appengine-web.xml :-) Not sure if the devserver has an extra param now...

…

On Thu, Aug 3, 2017 at 4:08 PM, Les Vogel ***@***.***> wrote: There is apparently a way to pass app-id when you start up the GAE Java runtime locally. At the very least, it would be good (helpful to Veneer) if: com.google.appengine.application.id System.property() were set. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#439>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE4zRtvu_4xdfY5qIOYgCe6mNjIxiYgks5sUlLygaJpZM4OtGFY> .

[lesv]

For gcloud on a Mac and Linux it can be found by:

1. Look in ~/.config/gcloud/active_config
2. Look in ~/.config/gcloud/configurations/config_NAME_FROM_ACTIVE_CONFIG
3. grab project =

[core]
project = lesv-003
account = lesv@google.com

[chanseokoh]

This might work for the command-line build tools, but this doesn't make much sense to IDEs. I wonder what should be done for the IDE story?

For IDEs, this can even be dangerous if the gcloud default project ID is silently picked up and actually contacted when running the dev server locally. (If the project is not ever to be contacted/scanned, there is no need for the dev server to know it, so I assume the project is actually contacted.) IDEs don't and shouldn't depend on the gcloud config state.

Even if it were OK for the IDEs to use the gcloud default project ID, then IDEs would need to have a way to pass to the dev appserver a login credential that has an access permission to the project. (Again, IDEs don't depend on the gcloud login state and rather have their own login system.) I don't believe there is a way to pass a login credential currently.

Then, IDEs would need to ask users to

1. go out of an IDE and do gcloud init (or something to that effect) to set a project ID
2. log in inside the IDE and select a right login credential

to run a simple HelloWorld app locally.

[lesv]

At some point, the IDE's are going to need to do the equivalent of gcloud auth application-default login if you are going to work w/o the gcloud sdk to provide support for Application Default Credentials. Project should come from a similar source.

[chanseokoh]

So, this is because of the ADC for Veneer? I see. Then, I think the right UX in the context of IDE is to allow users to optionally set an IDE login credential and a GCP project ID (through a friendly UI) when running applications or the dev server. If users want to set the login and the project ID for whatever reasons, they could do so, but these values must certainly be optional, to reduce friction to run apps such as a simple HelloWorld app where every operation is absolutely local.

For using IDE login credentials as ADC, I know this can be done through an env variable GOOGLE_APPLICATION_CREDENTIALS. However, note that if we don't enable APIs on our side (e.g., on the internal GCP project assigned for the Eclipse plugin), Veneer libraries still won't work. (AFAIK, gcloud has already enabled all necessary and feasible APIs on their project for their ADC.)

[chanseokoh]

BTW, I think appengine-plugins-core should not set the system property com.google.appengine.application.id by default, to avoid conflicts with IDE clients. (We should prevent IDEs from silently picking up the gcloud project config.) Only non-IDE clients should request to set it.

[lesv]

I just figured this was a cross project issue so I posted it here.

I don't think requiring users to setup ADC G_A_C envVar is the best idea.

@patflynn FYI

[chanseokoh]

Of course, users shouldn't set up the env var themselves. IDEs will provide a UI to select a logged-in account (and enter a GCP project ID) and set up the env var under the hood when running dev servers (in addition to setting up the system property for the project ID).

[chanseokoh]

There are discussions in the Cloud SDK Downloader design doc (written by @loosebazooka) suggesting that our build tools move away from using any of the gcloud config values (including project, user, or whatever). This will make this FR obsolete.

[lesv]

This is for the runtime environment locally, these could easily be sent from other sources, or we could document the requirement to set the envVar's - which I'm ok with.

[chanseokoh]

After all, it looks like setting the system property com.google.appengine.application.id is ineffective. The dev appserver1 seems to always overwrite it to no_app_id even if it is defined and given.

It has also been reported that setting the env var GOOGLE_CLOUD_PROJECT doesn't work either.

[chanseokoh]

It has also been reported that setting the env var GOOGLE_CLOUD_PROJECT doesn't work either.

Said too early. I was told that GOOGLE_CLOUD_PROJECT works for Veneer libraries. However, it still doesn't work for App Engine SDK services.

[chanseokoh]

Updated the title, as the system property com.google.appengine.application.id doesn't work anyway for the dev appserver. (#439 (comment))

[chanseokoh]

FTR, credentials can be passed with GOOGLE_APPLICATION_CREDENTIALS, which can also be a service account. Some Google Cloud APIs, such as Translation, seems to require a service account rather than a user credential.

[gartediego]

Hi,

Any update on this topic?

I've update to AppEngine Maven Plugin (Cloud SDK based) and now I don't have a way to get the project ID in DevServer.

Thanks in advance!

[chanseokoh]

@gartediego have you tried setting GOOGLE_CLOUD_PROJECT? I believe all Google Cloud libraries should pick this up. However, I think it is possible that the environment variable doesn't work for non-Cloud libraries like the old App Engine API.

[gartediego]

Thanks for your response @chanseokoh, but it's not working.

Regards,
Diego