Runner-only install, supports adoption

[mitchellh]

This enables a runner-only deployment, optionally with adoption.

Example: Adoption

$ helm install \
  --set server.enabled=false \
  --set runner.server.addr="1.2.3.4:5678" \
  --set runner.server.cookie="mycookie" \
  my-runner
  hashicorp/waypoint

Example: Pre-Adoption from a Secret

$ helm install \
  --set server.enabled=false \
  --set runner.server.addr="1.2.3.4:5678" \
  --set runner.server.tokenSecret="mysecret" \
  my-runner
  hashicorp/waypoint

Example: Adoption with Multiple Runners

$ helm install \
  --set server.enabled=false \
  --set runner.server.addr="1.2.3.4:5678" \
  --set runner.server.cookie="mycookie" \
  --set runner.replicas=2 \
  my-runner
  hashicorp/waypoint

[izaaklauer]

I'm modeling a setup with the server in an infra cluster, and runners in app clusters. When I install the server alone with runner.enabled=false, it still adds the waypoint-runner serviceaccount and waypoint-runner-token secret. Might want to add the {{- if (eq (.Values.runner.enabled | toString) "true") }} check to those templates.

[mitchellh]

Ah yes, I purposely made it so the server can’t be installed ON ITS OWN without a runner. This PR only introduces the ability to have “runner-only” installs, not the ability for servers to have “runner-less” installs.

Is that something we even want? I’m unsure, since I think our server currently assuming it should have a runner always available makes sense (for stuff like polling and other maintenance related tasks). It runs fine without a runner but I’d say we always expect that there is one…

Even if so, that feels like a separate use case that we should do this on its own first.

[mitchellh]

I guess, if we have a way to "disable" runners, it makes sense that it work lol. So let me fit that in...

[izaaklauer]

Ah, you're right, in my setup i'd actually want a pool of "shared" runners in my infra cluster for polling tasks. I don't need them to have any service accounts or cluster permissions though.

[mitchellh]

I made it so the service account isn't created if the runners are disabled. The token has to still be created cause the bootstrap job still creates a runner token. I think we can address that optimization (to not do that) later.

I think we can introduce more knobs in the future so that the server-installed runners can have less permissions.

[izaaklauer]

An operator in this deep could also just set runner.serviceaccount.create=false and craft their own permissions.

[mitchellh]

My latest commit makes this safe to merge.

When WP 0.8 is released, we should make the modification noted in the TODO though since its an improvement in all scenarios. But, the way it is now is no worse/different than how the Helm chart and Waypoint work today.

[izaaklauer]

As it is, this makes basic targetable runner installation way easier. But you still need to append an -id=<dev/prod> flag in the helm values, and you still need to create the new runner profile manually.

To expand off this, it would be sweet if the "runner only" install mode also created a new runner profile, targeting the runner it just installed. cc @xiaolin-ninja

[izaaklauer]

When installing a server without runners, it's a little bit unintuitive that the odr block needs to be set when installing the server, not the runners, because the bootstrap job that runs on server install is what applies the default odr profile.

e.g ODR config lives right underneath runner -> enabled:false:

runner:
  enabled: false
  odr:
    image:
      tag: latest
      repository: ghcr.io/hashicorp/waypoint/alpha
      pullPolicy: Always
    managedNamespaces:
    - izaakteam
    - acmecorp

server:
  image:
    tag: latest
    repository: ghcr.io/hashicorp/waypoint/alpha
    pullPolicy: Always

I was expecting to set the ODR settings when I installed the runner.

[mitchellh]

As it is, this makes basic targetable runner installation way easier. But you still need to append an -id=<dev/prod> flag in the helm values, and you still need to create the new runner profile manually.

It'll auto-generate an ID you can pick up with waypoint runner list to create a profile later too. The ID (when adoption is used) is persisted into the state directory so it won't change. Of course, once profiles support labels you can use that too.

To expand off this, it would be sweet if the "runner only" install mode also created a new runner profile, targeting the runner it just installed. cc @xiaolin-ninja

My expectation would be that the Helm chart won't have this API permission because the runner being created doesn't have a token at all (its being adopted).

[mitchellh]

So the actual workflow I imagine, to be clear, with runner profiles:

1. Use this Helm chart with zero API tokens to spin up new runner(s).
2. Open Waypoint UI to view pending runners (runners pending adoption)
3. Adopt runners, preview profiles they'd be attached to (if any, since weak binding)
4. Use UI to create new runner profiles, preview runners that'd be part of it

So you'd have basically a 100% UI flow except for the helm install single command