Talk about Proposal 0016, Default Workflows

[Raj-Dharwadkar]

tinkerbell/smee#178
Thanks for contribution and this is great work! We need more discussion to move forward.

[displague]

I left some comments on the issue about the approach of setting default workflows (using a matching system rather than name='default') and suggesting auto-registering workflows rather than baking responsibility into tinkerbell:

tinkerbell/smee#178 (comment)

[mmlb]

@nshalman and I were talking about this the other day last week. We were brainstorming and thought maybe instead of this concept built in we have something like a callback url for when a machine has no data tink can reach out and say "hey you, figure something out" and that other side can throw in some data to tink and have it run the "inventory workflow" or w/e else is wanted. This way we don't have 1 static template that needs to apply for many situations and leave it up to some other service to figure it out. This also has the benefit of moving some of the responsibility of hw data out of tink and into a DCIM + shim which I think everyone wants.

[ITJamie]

+1 on this. It fits similar to many other systems like MAAS or rackn digital rebar (sledgehammer is digital rebars os that handles profiling a system).

It would be good if based on the responding hardware info it would then allow triggering of some additional workflows, eg on dells configure idrac's, on hp's configure the ilo's.

[blackliner]

When I first heard about tinkerbells hardware concept, and having a lot of contact with k8s lately (pod scheduling with special HW like GPUs, node provisioning via karpenter) I imagined it would work like this:

• When a new PXE request comes in, the node is booted the usual way into whatever in-memory OS is currently the fancy one.
• Before running any workflows, this in-memory OS will analyze the node hardware (CPU count, type, arch, memory, GPU, pci... just use NFD)
• I can define high level rulesets that will select a workflow, i.e.

kind: HardwareRuleset
spec:
  - cpu:
      kubernetes.io/arch: amd64
      feature.node.kubernetes.io/cpu-cpuid.AVX2: "true"
  - nvidia/gpu:
      nvidia/gpu_compute_capability: 7.5
      matches: ">="
  - networking:
      bitrate: 10G
      matches: "<"
  - storage:
      totalRaw: 10TB
      matches: ">="

or, to provide the usecase of how its done today with MAC:

kind: HardwareRuleset
spec:
- networking:
    mac: 02:42:b7:c2:1f:44
    matches: "=="

• Finally, a hardware.yaml will have one or multiple of these rulesets listed
• Continue with provisioning as usual