Can you use some other auto-start mechanism? Our GCE VMs have startup scripts as part of the image that install packages from CIPD binaries and ensure they're running.

Fuchsia VMs also have some other auto-start mechanism that precludes the need for startup scripts in metadata.

The idea is to avoid having to bake custom images for workloads that don't really need any dependencies on OS level (like Tricium stuff), since custom images rot with time or require periodic maintenance (like we do with our image builder).

Regardless, metadata_from_file will also make our existing cipd_deployment metadata look nicer.

How should I proceed with this? Do you have an agreement on how to best support custom Tricium images?

What exactly is a custom Tricium image? Are you just taking our standard ccompute Trusty image and adding some extra stuff in? Are you building your own in parallel on https://uberchromegw.corp.google.com/i/internal.infra.cron? Something else?

More context: Tricium will be used to analyze CLs for gerrit-review.googlesource.com. Anyone can upload a CL there (any random person from the internet).

We can't run these tricium tasks on ccompute images or in ccompute GCE project because ccompute images various secrets "hardcoded" inside (either at the time the image is created or deployed later via puppet). These secrets are not needed for Tricium, and they can leak to external random people (because tricium analyzers are not perfectly sandboxed).

Instead we want to spin up completely standard GCE image in dedicated isolated GCE project.

Also we don't want to maintain a new custom image, because it adds toil (these image must be kept up-to-date with all security patches etc). Instead we want to use GCE images provided by the Cloud Platform and "convert" them into MP+Swarming bots via startup scripts supplied via metadata as described here https://cloud.google.com/deployment-manager/docs/step-by-step-guide/setting-metadata-and-startup-scripts

The startup script will essentially bootstrap CIPD client, then fetch and run MP agent (that will do the rest). Very minimal.

Placing this script inside a proto string is very nasty though. Thus this request to support including metadata from a file.

An alternative solution would be to generate templates.cfg from some more high-level definition. This would have to be done manually though after each modification.

All right, sounds fine. Then we should add metadata_from_file to templates.cfg.

When loading the config, we can probably just take each metadata_from_file, remove it, convert it from a key:filename string to a key:value string by loading the named file from luci-config, then add it to the template proto's metadata. Then the rest of the app doesn't need to know or care about metadata_from_file, it will just think there are some really long metadata keys.

GCE has a hard limit on the length of metadata values [1] so we can probably also reject files that are too long.

[1] https://cloud.google.com/compute/docs/reference/latest/instances/setMetadata

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/luci/luci-py.git/+/6ed67a311b69582c6ed66050ee03f9927dc162d1

commit 6ed67a311b69582c6ed66050ee03f9927dc162d1
Author: Emma <emso@chromium.org>
Date: Thu Nov 30 09:02:27 2017

Adds support for metadata_from_file.

Bug:778324
Change-Id: I71e77fc9f8ae5f2144d5710b9c44a1a39cd23788
Reviewed-on: https://chromium-review.googlesource.com/789933
Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
Reviewed-by: Marc-Antoine Ruel <maruel@chromium.org>
Commit-Queue: Emma Söderberg <emso@chromium.org>

[modify] https://crrev.com/6ed67a311b69582c6ed66050ee03f9927dc162d1/appengine/gce-backend/config.py
[modify] https://crrev.com/6ed67a311b69582c6ed66050ee03f9927dc162d1/appengine/gce-backend/config_test.py
[modify] https://crrev.com/6ed67a311b69582c6ed66050ee03f9927dc162d1/appengine/gce-backend/proto/config.proto
[modify] https://crrev.com/6ed67a311b69582c6ed66050ee03f9927dc162d1/appengine/gce-backend/proto/config_pb2.py