Proposal 0016, Default Workflows

[Belchy06]

Expected Behaviour

It would be very helpful to have default workflows for Tinkerbell, meaning that when a currently unknown machine sends out a DHCPDISCOVER request, Boots will push the new hardware and create a workflow for the new machine from the default template.

Current Behaviour

Currently, you must manually push each new piece of hardware you expect and then manually create a workflow for this HW

Possible Solution

on dhcpdiscover received:
- grab mac address from req
- create hardware with mac
- push hardware
- grab a template titled 'default'
- create workflow with new hw id and default template id

Context

Trying to provision multiple bare metal machines on a private network as soon as they are turned on

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS):
  Win10, Ubuntu

• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
  Running based on Local Setup with Vagrant tutorial

[tstromberg]

Just an update to say that I personally like this idea and feel like it will make Tinkerbell much more user-friendly.

[displague]

In the 8/31 Tinkerbell meeting, this proposal was discussed briefly.

I have some thoughts on the overall approach.

Regarding, the registration approach:

• create hardware with mac
• push hardware

Tinkerbell should avoid taking on more responsibilities. A default workflow could take on this function.

When attributing workflows as default:

• grab a template titled 'default'
• create workflow with new hw id and default template id

Workflows could be matched to hardware ID using some matching system rather than == comparisons.
For example, one component of a matching system could be a regexp pattern. A "Raspberry Pi Default Workflow" could match all Pi MAC Addresses (B8:27:EB:.*, https://www.wireshark.org/tools/oui-lookup.html).

A more comprehensive matching system could take all hardware components into consideration.

Following that pattern, an 'AutoRegister Workflow' (any "default" workflow) could match .* HW IDs.

Questions:

• Would we need to ensure that some default workflows are executed only once?
• Would we also need to set the priority of default workflows, enabling auto-register-workflow to run before raspberry-pi-workflow?
• Can or should the pattern matching workflow executor run as a workflow? (Let a workflow fetch matching workflows, perhaps apply additional filters and then execute these workflows in some sequence)
• Are there trust issues in allowing the node to self-register, if so, can we enable the necessary trust level?

Cross-posted in discussion tinkerbell/tink#522 (comment)

[jmpolom]

Workflows could be matched to hardware ID using some matching system rather than == comparisons.
For example, one component of a matching system could be a regexp pattern. A "Raspberry Pi Default Workflow" could match all Pi MAC Addresses (B8:27:EB:.*, https://www.wireshark.org/tools/oui-lookup.html).

A more comprehensive matching system could take all hardware components into consideration.

I'm very interested in tinkerbell/boots gaining support to do "wildcard" hardware matching, initially just using a regex to match MAC addresses much like @displague provided as an example. I prefer the paradigm of creating workflows that can match a hardware identifier via some provided (regex) patterns, instead of only allowing a single "default" (both in name and function) template that is auto-registered to the specific hardware that is initially unknown to tinkerbell. I think this would be far more flexible and in effect create "scoped default workflows".

I think it should be left up to the user whether to run a workflow that explicitly registers a specific workflow per piece of hardware (ex: to build an inventory) or simply allow workflows to run as they are matched to a specified identifier pattern. I do like the idea of having a "discovery" workflow that runs and is potentially able to gather much more system information than you receive from a simple DHCP request.

Am I correct in understanding that adding support for an enabling feature like regex matching of MAC addresses would need to be added to the tink server and not boots? Best I can tell from my read of the boots codebase is that boots does not do any hardware matching itself, except in the case of the standalone data model.

[mmlb]

We should discuss this in tinkerbell/tink#522. This is a tink feature not so much a boots one an as such doesn't make sense as an issue here.