Add support for reservation IDs with MachineDeployment

[deitch]

Issue #133 and related PR #134 reflect the request to deploy a single Machine with its attendant HardwareReservationID.

However, usually machines are deployed with a MachineDeployment, which has a PacketMachineTemplate.

This issue is to track what that would look like, eventually leading to a PR.

[deitch]

Here is a typical template, taken from the template/cluster.yaml:

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: PacketMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-worker-a
spec:
  template:
    spec:
      OS: "${NODE_OS}"
      facility:
      - "${FACILITY}"
      billingCycle: hourly
      machineType: "${WORKER_NODE_TYPE}"
      sshKeys:
      - "${SSH_KEY}"
      tags: []

Some possibilities:

• we just let it use any reservation ID of the right machineType in that facility, sort of a strategy: reserved, as suggested by @gianarb
• we provide a list of reservation IDs in the template; if none is provided, use on-demand. See below.

# using strategy
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: PacketMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-worker-a
spec:
  template:
    spec:
      OS: "${NODE_OS}"
      facility:
      - "${FACILITY}"
      billingCycle: hourly
      machineType: "${WORKER_NODE_TYPE}"
      sshKeys:
      - "${SSH_KEY}"
      strategy: reserved
      tags: []
---
# using 'hardwareReservationIDs'
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: PacketMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-worker-a
spec:
  template:
    spec:
      OS: "${NODE_OS}"
      facility:
      - "${FACILITY}"
      billingCycle: hourly
      machineType: "${WORKER_NODE_TYPE}"
      sshKeys:
      - "${SSH_KEY}"
      hardwareReservationIDs:
      - abcd
      - abce
      - 12ff
      tags: []

[gianarb]

I like the idea to have a specific list and we can make it not mandatory:

If the strategy=reserved and hardwareReservationIDs are set the procedure takes one from there, if hardwareReservationIDs are not set take a random one, if there are no resID available in the list of free-from API, fail or create demand.

We can even have the strategy to accept a list of possibilities that act as a fallback:

1. strategy=ondemand => easy
2. strategy=reserved => fails if there is not available resID
3. strategy=reserved,ondemand => fallback to ondemand is there are not resID available (in general or from the list)

The way you wrote the YAML assumes that the hardwareReservationIDs is a field in the PacketMachine object. I would like to have it as part of the Template only. Not sure if we can make it to work.

Do you see the list as part of the PacketMachine?! Because if that's the case we should use that to close #134

[deitch]

strategy=ondemand => easy

This is the default

strategy=reserved => fails if there is not available resID

This is how I understood "reserved"

strategy=reserved,ondemand

Oh, so you can specify a fallback. I like this. We just do it yaml-style:

strategy:
- reserved
- ondemand

I would like to have it as part of the Template only. Not sure if we can make it to work.

What would the yaml look like?

[gianarb]

The YAML will look like this:

# using 'hardwareReservationIDs'
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: PacketMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-worker-a
spec:
  template:
    hardwareReservationIDs:
       - abcd
       - abce
       - 12ff
    spec:
      OS: "${NODE_OS}"
      facility:
      - "${FACILITY}"
      billingCycle: hourly
      machineType: "${WORKER_NODE_TYPE}"
      sshKeys:
      - "${SSH_KEY}"
      tags: []

but I am not sure I can read that field from the machine reconciliation loop

[deitch]

I like that a lot better than what I first drew up. If we can do that, we should. If not, then in the spec itself.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cprivitere]

/reopen

[k8s-ci-robot]

@cprivitere: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cprivitere]

/lifecycle frozen

[cprivitere]

This appears to have been solved at some point, perhaps in the updates for CAPI 1.X. But now you can add reserved hardware UUIDs or "next-available" to the packetmachinetemplate and it will provision them properly. Here's a quick example block:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: PacketMachineTemplate
metadata:
  name: my-cluster-control-plane
  namespace: default
spec:
  template:
    spec:
      billingCycle: hourly
      machineType: c3.small.x86
      os: ubuntu_18_04
      sshKeys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDvMgVEubPLztrvVKgNPnRe9sZSjAqaYj9nmCkgr4PdK username@computer
      tags: []
      #If you want to specify the exact machines to use, provide a comma separated list of UUIDs
      hardwareReservationID: "b537c5aa-2ef3-11ed-a261-0242ac120002,b537c5aa-2ef3-11ed-a261-0242ac120002"
      #Or let the controller pick from available reserved hardware in the project that matches machineType and facility with `next-available`
      #hardwareReservationID: "next-available"

[cprivitere]

#409 fixes the docs for this.