[gcemeta] Return AssumeNonGCE hack, but reverse its value.

If InheritFromGCE is true => probe real GCE metadata.
If InheritFromGCE is false => do not probe real GCE metadata.

There are two conflicting concerns.

The first is related to testing code that behaves differently
in the GCE environment. Let's call it the "testing concern".

metadata.OnGCE() caches its value the first time it is called.
There are third party libraries we are importing that check
value of metadata.OnGCE() and do something differently based
on it.

In particular, the Cloud Telemetry has a failure mode where,
with a particular state of dependencies in go.mod (that can
and did happen accidentally via "go mod tidy"), it compiles,
but panics at runtime, but **only on GCE** (see
http://b/356517179#comment16). This caused an outage.

To have a test for this, we need to make sure to run tests
such that metadata.OnGCE() returns true and there's an emulated
metadata server running.

The second concern is that gcemeta.Server itself needs to know
if it runs on **real** GCE to get a **real** instance zone. Thus
it needs to call metadata.OnGCE() at some point. Let's call this
the "real zone concern".

There are 2 approaches:
1) Call metadata.OnGCE() before starting gcemeta.Server. Since
   the emulation is not enabled yet, this solves the "real zone
   concern". But it doesn't address the "testing concern", since
   when running tests not on GCE, metadata.OnGCE will forever be
   cached as "false" and the code under test will just ignore the
   emulated metadata server.
2) Call metadata.OnGCE() as late as possible in ".../zone"
   metadata handler. This solves the "testing concern", but it
   doesn't really solve the "real zone concern". It work only if
   the process that started gcemeta.Server doesn't install it
   into its own process environment, because if it does,
   metadata.OnGCE() will always return true, even when not on
   GCE, because it will be discovering the emulated server itself.

Initially the code used approach 1) and a boolean field
AssumeNonGCE to disable probing of GCE. This was deemed as
a hack since using AssumeNonGCE required understanding all
this subtleties.

The code was changed to use approach 2) to get rid of AssumeNonGCE.
Issues with it were discovered. In particular `luciexe` installs
the emulated metadata server into its own environment, which results
in real zone detection not working. Changing `luciexe` to not do that
looks non-trivial (process environ modification is a part of its public
API). And generally this is as brittle and confusing as AssumeNonGCE.

This CL switches back to use approach 1) except now with
InheritFromGCE field which should be passed explicitly to
**enable** GCE probing. That way everything works more or
less as expected when writing tests. There's only one
non-test usage of gcemeta.Server, InheritFromGCE is enabled
there. Hopefully, this will be less brittle than two previous
approaches.

R=iannucci@chromium.org
CC=​ukai@google.com
BUG=b/376372151

Change-Id: I0b2501d41110ee05e82fe7f7d536ed2dc80d1a70
Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5980912
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
3 files changed
tree: 25f6379b8a997fae51fb5ed987103379d6b029ad
  1. analysis/
  2. appengine/
  3. auth/
  4. auth_service/
  5. bisection/
  6. build/
  7. buildbucket/
  8. casviewer/
  9. cipd/
  10. cipkg/
  11. client/
  12. common/
  13. config/
  14. config_service/
  15. cv/
  16. deploy/
  17. examples/
  18. gae/
  19. gce/
  20. grpc/
  21. hardcoded/
  22. led/
  23. logdog/
  24. luci_notify/
  25. lucicfg/
  26. lucictx/
  27. luciexe/
  28. mailer/
  29. milo/
  30. mmutex/
  31. provenance/
  32. recipes_py/
  33. resultdb/
  34. scheduler/
  35. scripts/
  36. server/
  37. source_index/
  38. standalone/
  39. starlark/
  40. swarming/
  41. teams/
  42. third_party/
  43. tokenserver/
  44. tools/
  45. tree_status/
  46. vpython/
  47. web/
  48. .gitallowed
  49. .gitattributes
  50. .gitignore
  51. .go-lintable
  52. AUTHORS
  53. codereview.settings
  54. CONTRIBUTING.md
  55. CONTRIBUTORS
  56. go.mod
  57. go.sum
  58. LICENSE
  59. OWNERS
  60. PRESUBMIT.py
  61. README.md
  62. staticcheck.conf
  63. tools.go
  64. WATCHLISTS
README.md

luci-go: LUCI services and tools in Go

GoReference

Installing

LUCI Go code is meant to be worked on from an Chromium infra.git checkout, which enforces packages versions and Go toolchain version. First get fetch via depot_tools.git then run:

fetch infra
cd infra/go
eval `./env.py`
cd src/go.chromium.org/luci

It is now possible to directly install tools with go install:

go install go.chromium.org/luci/auth/client/cmd/...@latest
go install go.chromium.org/luci/buildbucket/cmd/...@latest
go install go.chromium.org/luci/cipd/client/cmd/...@latest
go install go.chromium.org/luci/client/cmd/...@latest
go install go.chromium.org/luci/cv/cmd/...@latest
go install go.chromium.org/luci/gce/cmd/...@latest
go install go.chromium.org/luci/grpc/cmd/...@latest
go install go.chromium.org/luci/logdog/client/cmd/...@latest
go install go.chromium.org/luci/luci_notify/cmd/...@latest
go install go.chromium.org/luci/lucicfg/cmd/...@latest
go install go.chromium.org/luci/luciexe/legacy/cmd/...@latest
go install go.chromium.org/luci/mailer/cmd/...@latest
go install go.chromium.org/luci/mmutex/cmd/...@latest
go install go.chromium.org/luci/resultdb/cmd/...@latest
go install go.chromium.org/luci/server/cmd/...@latest
go install go.chromium.org/luci/swarming/cmd/...@latest
go install go.chromium.org/luci/tokenserver/cmd/...@latest
go install go.chromium.org/luci/tools/cmd/...@latest

Contributing

Contributing uses the same flow as Chromium contributions.