Closed rjferguson21 closed 16 hours ago
Thanks for the issue! Agreed that the second proposed syntax is a bit cleaner than -component
. Trying to understand the root issue, I saw @zachariahmiller 's comment in https://github.com/defenseunicorns/uds-core/issues/176 regarding optionalComponents
. Can you elaborate on why optionalComponents
doesn't fit this use case?
We were thinking if there was something that was hypothetically required: false, default: true at the zarf layer then we would need a way to add or remove, not just add.
Metrics server being the main example we were thinking of
We were thinking if there was something that was hypothetically required: false, default: true at the zarf layer then we would need a way to add or remove, not just add.
Ideally also at deploy time, like zarf.
@zack-is-cool yeah when we discussed this earlier we had talked about an MVP of deploy time then handle create time as a follow up
Going through some old PRs/issues. @zachariahmiller @rjferguson21 @zack-is-cool @blancharda is this issue still desired / relevant?
Great timing @UncleGedd - I was going through some old uds-core issues and hit the related one for making metrics-server optional for core. I think we would need component deselection in bundles for that to be a seamless end user experience.
What we're currently thinking on that side is leveraging default: true
on our metrics-server
component which would have it enabled by default. When deploying with zarf that results in a prompt for the component (defaulting to "yes", but allowing "no"). If bundles supported a way to opt out of this that would be perfect to close the loop on how a user could disable a default component. I don't have any strong opinion on exposing at build vs create vs both, but would like at least one of those to be an option.
Zarf component selection/deselection at deploy time is definitely still relevant on our end.. though more for troubleshooting and quick iteration than anything blocking or required.
I think the original ask of this issue has been resolved via UDS functional layers.
Personally, I don't love the idea of switching on Zarf required
vs default
, IMO this adds complex logic on top of already complex logic.
Going to close this for now, but @blancharda feel free to open another with your specific use case. Thanks all!
Is your feature request related to a problem? Please describe
As of this this PR, Zarf supports deselection of optional components with
--components=-notthiscomponent
.We've discussed it being helpful to support a use case where packages can have components that are defaulted to be true but can be disabled.
Describe the solution you'd like
packages:
The
-podinfo
disables the podinfo component from the podinfo packageoptionalComponents:
Describe alternatives you've considered
The syntax around zarf component deselection is a bit awkward exposed directly in the uds bundle schema via
optionalComponents
. @zachariahmiller and I discussed it would probably be better to consider updating the schema to removeoptionalComponents
and replace with something like enabled in theoverrides
for the package so you'd end up with this instead.Additional context
I added a draft PR to enable the component deselection in a quick and dirty way but wanted to discuss that this was the right path forward.