appengine icon indicating copy to clipboard operation
appengine copied to clipboard

v2 module tries to resolve internal hostnames when used by go112/go113 app under dev_appserver.py

Open derat opened this issue 3 years ago • 0 comments

I've been trying to use the new google.golang.org/appengine/v2 module to upgrade a go111 app that makes heavy use of bundled services. As described in https://cloud.google.com/appengine/docs/standard/go/services/access, I added app_engine_apis: true to my app.yaml file and updated the import statements throughout my app to import the v2 packages (currently at v2.0.1). I'm still calling appengine.Main() at the end of my app's main() function.

When running my app via dev_appserver.py . with the go112 runtime and version 365.0.0-0 of the google-cloud-sdk, google-cloud-sdk-app-engine-go, and google-cloud-sdk-app-engine-python Debian packages, I see the following panic at the point of my app's first datastore access:

INFO     2021-11-18 15:03:31,219 devappserver2.py:316] Skipping SDK update check.
INFO     2021-11-18 15:03:31,398 <string>:383] Starting API server at: http://localhost:41237
INFO     2021-11-18 15:03:31,409 instance_factory.py:185] Building with dependencies from go.mod.
INFO     2021-11-18 15:03:31,421 dispatcher.py:281] Starting module "default" running at: http://localhost:8080
INFO     2021-11-18 15:03:31,422 admin_server.py:150] Starting admin server at: http://localhost:8000
INFO     2021-11-18 15:03:34,729 instance.py:294] Instance PID: 7682
2021/11/18 15:03:39 CRITICAL: panic: Metadata fetch failed for 'instance/attributes/gae_project': Get "http://metadata/computeMetadata/v1/instance/attributes/gae_project": dial tcp: lookup metadata on 100.115.92.193:53: no such host

goroutine 20 [running]:
google.golang.org/appengine/v2/panic(0xa3b340, 0xc0000700a0)
        /usr/lib/go-1.15/src/runtime/panic.go:969 +0x1b9
google.golang.org/appengine/v2/internal.mustGetMetadata(0xb58fcc, 0x1f, 0x0, 0x0, 0xc000068700)
        /home/me/go/pkg/mod/google.golang.org/appengine/[email protected]/internal/metadata.go:34 +0x148
google.golang.org/appengine/v2/internal.projectID(0xb4c9f9, 0xf)
        /home/me/go/pkg/mod/google.golang.org/appengine/[email protected]/internal/identity.go:149 +0x76
google.golang.org/appengine/v2/internal.partitionlessAppID(0xb4c9ea, 0xf)
        /home/me/go/pkg/mod/google.golang.org/appengine/[email protected]/internal/identity.go:142 +0x5e
google.golang.org/appengine/v2/internal.fullyQualifiedAppID(0xc0f4c0, 0xc0003427e0, 0xfa1410, 0x0)
        /home/me/go/pkg/mod/google.golang.org/appengine/[email protected]/internal/identity.go:156 +0x52
google.golang.org/appengine/v2/internal.FullyQualifiedAppID(0xc0f4c0, 0xc0003427e0, 0xfa1460, 0x0)
        /home/me/go/pkg/mod/google.golang.org/appengine/[email protected]/internal/api_common.go:77 +0x99
google.golang.org/appengine/v2/datastore.NewKey(0xc0f4c0, 0xc0003427e0, 0xb4afd8, 0xc, 0xb464db, 0x6, 0x0, 0x0, 0xb4457d)
        /home/me/go/pkg/mod/google.golang.org/appengine/[email protected]/datastore/key.go:293 +0x5c
...

It appears to be failing to resolve a Google-internal hostname. Looking at fullyQualifiedAppID in internal/identity.go, this seems to happen when the GAE_APPLICATION/GAE_LONG_APP_ID/GOOGLE_CLOUD_PROJECT or the GAE_PARTITION environment variables aren't set. When I log os.Env(), I can see that those environment variables are indeed missing.

I tried running GAE_APPLICATION=foo GAE_PARTITION=bar dev_appserver.py ., which results in a different failure when I try to use datastore (seemingly again caused by a failed DNS lookup):

2021/11/18 15:31:00 CRITICAL: panic: service bridge HTTP failed: Post "http://appengine.googleapis.internal:10001/rpc_http": dial tcp: lookup appengine.googleapis.internal on 100.115.92.193:53: no such host

After spending a fair amount of time on this, I updated my app.yaml to use go115 on a whim and was surprised to discover that the problem no longer occurs. Experimenting further, I see the failed resolutions with the go112 and go113 runtimes but not with go111, go114, or go115.

In my particular case, I think that I'm able to just use go115 for my app, but if the v2 module is expected to not support go112 and go113 (at least under dev_appserver), could you add a more descriptive error and update https://cloud.google.com/appengine/docs/standard/go/services/access (which currently refers to "Go 1.12+")? Thanks!

derat avatar Nov 18 '21 16:11 derat