Expand Hardware spec fields available as template data in Templates: #807
Conversation
jacobweinstock
force-pushed
the
expand-template-data
branch
from
bd30160 to
f93f0f9
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #807 +/- ##
==========================================
+ Coverage 50.61% 50.89% +0.28%
==========================================
Files 36 36
Lines 1549 1558 +9
==========================================
+ Hits 784 793 +9
Misses 712 712
Partials 53 53 ☔ View full report in Codecov by Sentry. |
internal/workflow/reconciler.go
Outdated
| type netInterface struct { | ||
| MAC string | ||
| VLANID string | ||
| DHCP dhcp |
There was a problem hiding this comment.
I know we've been around this loop but lets go again: do we think DHCP is here to stay with the network interface data? I.e. would we introduce any feature where DHCP isn't specified? If so, how can I easily determine if the DHCP config is available from template language?
There was a problem hiding this comment.
Question: do we think DHCP is here to stay with the network interface data? Not necessarily.
Response: We could change this to IPAM or something more generic and remove non IPAM data. If the answer to this question is no, what would you say are our alternatives?
Question: would we introduce any feature where DHCP isn't specified?
Response: I can't think of any at the moment.
Question: If so, how can I easily determine if the DHCP config is available from template language?
Answer: I dont know if i understand what you're asking. How is this done with any data from the template language? I dont know if this is what you're asking but we could write some functions for retrieving this DHCP data.
There was a problem hiding this comment.
I think I'm inventing possibilities to challenge this because its meant to be a stable contract. I don't know how productive trying to provide stability here really is though. I feel like we'd be better off just plumbing through the raw Hardware.Spec and when that becomes stable this contract inherently becomes stable.
Given we've had numerous requests to get various fields, mostly network interface data, how do you feel about including that and declaring this 'stable' contract a deprecated experiment (but we'll leave it in for now)?
There was a problem hiding this comment.
@jacobweinstock What did we conclude - I don't recall?
jacobweinstock
force-pushed
the
expand-template-data
branch
from
258e15d to
a75c59c
Compare
jacobweinstock
force-pushed
the
expand-template-data
branch
from
46c2308 to
92bd978
Compare
Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock
force-pushed
the
expand-template-data
branch
from
92bd978 to
ff6ed07
Compare
This expands the available Hardware data to Templates for templating. Using sprig functions allows us to remove some custom template funcs we had. Sprig also gives us lots of other useful templating functions. Signed-off-by: Jacob Weinstock <[email protected]>
Has updated features and fixes. Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
If a value used in the template contract is nil, handle properly. Signed-off-by: Jacob Weinstock <[email protected]>
jacobweinstock
changed the title
Signed-off-by: Jacob Weinstock <[email protected]>
Description
This improves the templating of Templates. This was requested by quite a few folks in the community.
Why is this needed
Fixes: #
How Has This Been Tested?
How are existing users impacted? What migration steps/scripts do we need?
Checklist:
I have: