Comments (4)
Just an update to say that I personally like this idea and feel like it will make Tinkerbell much more user-friendly.
from boots.
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)
from boots.
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.
from boots.
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.
from boots.
Related Issues (20)
- Doc: dead link in iPXE Doc on main branch HOT 1
- Stop building 32b images
- Provide a configurable minimum lease expiry for DHCPOFFERs
- Release 0.7 HOT 1
- Add documentation around updated components in Boots HOT 1
- Deprecate and remove Cacher backend
- Remove Cacher backend HOT 1
- Support customization of HTTP port HOT 1
- Consume Tink v1alpha2 APIs
- Customscript error handling does not seem correct HOT 7
- [pls ignore] pxe boot HOT 1
- kernel arg `ip=dhcp` can cause very long boot time in Hook HOT 1
- Binding DHCP server to a specific interface instead of 0.0.0.0 HOT 2
- Add flag to set TFTP block size. HOT 1
- smee/dhcprelay is broadcasting DHCPOFFER instead of unicasting in an L3 environment
- The file backend does not update the runtime config on file change HOT 2
- documenation | static ip addresses | example required HOT 1
- Does smee support binding to IPv6 address ? HOT 4
- Default command-line option values depend on other command-line options (ref `detectPublicIPv4`) HOT 2
- Smee panic in proxy mode HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from boots.