search

defenseunicorns / uds-cli

Apache License 2.0
24 stars 10 forks source link

Support Zarf component deselection in UDS bundles #426

Closed rjferguson21 closed 16 hours ago

rjferguson21 commented 6 months ago

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:

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 remove optionalComponents and replace with something like enabled in the overrides for the package so you'd end up with this instead.

kind: UDSBundle
metadata:
  name: uds-stuff
  version: dev

packages:
  - name: podinfo
    path: ./
    ref: "0.0.1"
    overrides:
      podinfo:
        enabled: false

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.

UncleGedd commented 6 months 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?

zachariahmiller commented 6 months ago

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.

zachariahmiller commented 6 months ago

Metrics server being the main example we were thinking of

zack-is-cool commented 5 months ago

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.

zachariahmiller commented 5 months ago

@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

UncleGedd commented 1 month ago

Going through some old PRs/issues. @zachariahmiller @rjferguson21 @zack-is-cool @blancharda is this issue still desired / relevant?

mjnagel commented 1 month ago

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.

blancharda commented 1 month ago

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.

UncleGedd commented 16 hours ago

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!