Template data model

[jacobweinstock]

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.

tink/pkg/apis/core/v1alpha1/template_types.go

Line 21 in fe2177f

Data *string `json:"data,omitempty"`

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]

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).