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