Dont use terraform's file() for singleline strings in GCE metadata

[rifelpet]

Currently the instance_template's metadata field contains the startup script, ssh keys, cluster name, and IG name. rather than storing redundant separate files containing just the cluster and IG names, this will store them as string literals within the .tf file.

The motivation for this is that a new version of hcl2 adds support for writing multiline maps. Using the library's function for writing maps will allow us to get rid of our own hcl2.go's writeMap function. The only blocker is that the library doesn't support values being literals like foo = file(). GCE's instance_template is the only such use of maps in kops and this fixes 2 of the 4 fields.

The instance_template terraform resource actually has a separate metadata_startup_script field that we can use instead of having the script in the metadata field (I'll update that in a followup PR). That leaves the ssh key as the last file() in the metadata field. We could inline it as another hardcoded string, but it seems better to use ssh keys at the project level rather than instance level. I dont have a gce account to test that though so I'd need assistance in that migration.

/assign @geojaz

This also removes a redundant terraform literal function LiteralExpression that was only used in one place, with the identical LiteralFromStringValue being more commonly used.

[geojaz]

Thanks for cleaning out those file()s that reference a single word. Those are kinda silly.

I agree that we should move the actual startup script to the metadata_startup_script field in a follow-on PR.

For the project-wide SSH keys, i think you may have incorrectly linked to the docs for os-login. google_compute_project_metadata_item would manage the SSH key at the project-level. Mislink or not, os-login is probably a feature that we should be supporting in kops since it's the generally accepted way to manage SSH access to instances in GCE.

I would vote to just move the SSH key to the project-metadata for now and tackle alternative access models a different day. I'm happy to take a look at that PR when it's ready. I'll write an issue for os-login....

/approve
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: geojaz, rifelpet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [geojaz,rifelpet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment