add hardware reservation id support

[jhead-slg]

Fixes #133

[gianarb]

Hello! Thank you for your PR! I am not sure I would like to expose the possibility to set that parameter from the outside.
It works when using a Machine but It does not look a reliable approach when using a machine template and machine deployment (they work like ReplicaSet for pods) that is probably the thing everyone will use at the end because it manages reconciliation and scaling.

I prefer to hide this capability behind a different field like: strategy=ondemand|reserved|spot and the reservation ID can be retrieved via API, in this way the reconciliation will stay more flexible.

The open question that I have is: what happens when there are not reserved ID available? Should we spin up an on-demand one or wait until a reserved ID becomes available?

[deitch]

Hey @jhead-slg , thanks for this. We should get this in, so let's figure out the API?

We know two ways to allocate machines in cluster-api:

• Machine - specify actual specific machines
• MachineDeployment - template

Multi-master and scaling (both master and worker) only work with MachineDeployment, so we would need a way to support it there.

I think you are addressing the first one, while @gianarb is looking at the second, hence the disconnect.

We could go down the single Machine reservation ID path based on this PR, and then have a separate PR to add support for MachineDeployment.

Actually, I like that. I am going to open an issue to add support for reserved instances for MachineDeployment, while Machine can be tied to a single reservation ID.

We cannot quite merge this PR in because:

• it needs docs
• we need to be explicit about failure - to answer your question @gianarb, the way Packet usually works is, if I ask to deploy a machine and specify a reservation ID, and it fails, then the request fails. We should stick to that.
• we need to add the API code to use it
• we need to regenerate

One other weakness is that clusterctl cluster > output.yaml won't work, as it doesn't have provisions for optional fields, e.g. if env var RESID is set then add the field, else not. It doesn't even have support for defaults yet.

Still, this is a good path to go down, and we can base it on this.

[gianarb]

I like the idea to avoid possible but not that scalable approaches if possible.

There is not enough context for me to evaluate if there is a problem that can be solved only treating those reservation IDs as pets. I am all in about this approach if I can see this use case.

Anyway, it is the same, I will be very happy to implement only the workflow that looks scalable and reliable. But overall I won't make any more friction about this topic moving forward, I am just happy to point it out 👍