ZEP-0051: Introduce state values - #64
Conversation
Signed-off-by: Austin Abro <austinabro321@gmail.com>
AustinAbro321
changed the title
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
Signed-off-by: Austin Abro <austinabro321@gmail.com>
brandtkeller
left a comment
brandtkeller
left a comment
There was a problem hiding this comment.
in support of these being accessible in the package directly. I need to put together an example as this feels closely coupled to the UX.
|
Added it to the v1beta1 example zarf-dev/zarf#4865 |
Signed-off-by: Austin Abro <austinabro321@gmail.com>
| ... | ||
| ``` | ||
|
|
||
| Services are usually accompanied by fields in Zarf state. State fields such as `.Registry.Port` are typically set during `init` by command-line flags (`--registry-port`). This makes these fields impossible to set during `zarf package deploy`. Additionally, potential future fields such as `.State.Injector.Tolerations` are impractical to set through a CLI flag. A new field `.components.[X].stateValues` will accompany the new `.components.[X].service` field. State values allow setting sub-objects on state when the component's service matches the sub object. For instance, in order to declare the target path `.Registry.Port`, the component must declare the `.Registry` service. StateValues will not enable setting top level state fields such as storage class. |
There was a problem hiding this comment.
One of my current cognitive hurdles is where the boundary lies between regular configuration values and state values - both in separating the contract as well as refining the UX.
for example - I'm noodling on a backwards compatible option to potentially surface the injector pod configuration as a file/manifest such that we could open the gates to configuration through values without needing one-off flags/state values.
Something like .injector.Tolerations shouldn't need be a state value - we don't need to store that in state.
I believe that could flow naturally into this but also potentially negate the need for some of the flags all-together. I can speak/show more of what I am thinking but overall it surfaces the question of what is the boundary for state values and how to surface them accordingly.
There was a problem hiding this comment.
Yeah, another thing I considered was ServiceValues. I went with state since the values mapped and I thought it'd be more intuitive, but given there are fields like IsInternal, it probably isn't a good fit.
I'm certainly interested in completely different ideas as well.
2 participants
I considered deprecating all of the CLI flags. I decided against, because I think this method would make them less discoverable.