search

tinkerbell / tink

Workflow Engine for provisioning Bare Metal
https://tinkerbell.org
Apache License 2.0
913 stars 134 forks source link

Template data model #652

Open jacobweinstock opened 1 year ago

jacobweinstock commented 1 year ago

Currently, to understand all the fields available in a Template action you have to search the code base. And even then it's really confusing. https://github.com/tinkerbell/tink/blob/fe2177f9d99d5d811ee91d1c4f92ba0c7439c0b5/pkg/apis/core/v1alpha1/template_types.go#L21

The available fields for Templates and especially Template actions are unknowable from the Template CRD spec. Template.Spec.Data is just a string field, like the code referenced above.

This file for workflows ultimately describes all available fields. Finding and then understanding that this file holds the info for all fields in a Template is almost impossible for anyone without deep understanding of the the stack and this code base. I don't believe this is the experience we want.

We should discuss significantly improving the discover-ablility/understand-ability of the possible fields of a template. One option could be to make the CRD spec describe all the fields instead of taking a string blob. This might make template values like {{.device_1}} more difficult in code to find/parse. That might be worth the trade off though.

thoughts?

chrisdoherty4 commented 1 year ago

Broadly, I totally agree. I've had to figure this out several times (because I keep forgetting the nitty-gritty details) and its not pleasant.

It also ties into the additions we made for exposing Hardware data and the custom functions that are available. I think this ties in with, in some capacity, the additions made to reference Hardware in a different way as opposed to the device_1 thing too, which feels very incidental (even though it is intentional).