Revert to `bundle` syntax in CLI about uds-cli HOT 6 CLOSED

My 2 🪙s would be that this could / should be driven by an ADR (probably not on this particular issue since it is small by itself) but having a base uds-cli / bundle ADR on what they are and what they are planned to contain would allow people to see more decision criteria / more of the vision / drive behind uds-cli and bundles.

Fun fact zarf actually started with a command hierarchy but also had shortcut commands that were removed early on (before Zarf started doing ADRs). Zarf still has deprecation warnings in it's CLI almost 2 years on:

https://github.com/defenseunicorns/zarf/blob/11f6173b69678399abce87c0a43abaacb22f516a/cli/cmd/root.go#L26

from uds-cli.

@mjnagel I agree, I think it depends upon what will necessitate a bundle, as there is not a clear definition / ADR on that as of right now. Is bundle the only thing that UDS CLI will orchestrate? In order to update a single application in a bundle, are users going to re-build the bundle and re-deploy, or should UDS CLI support deploying Zarf packages and merging them into an existing bundle?

Even in Zarf there is a little bit of disrepency, zarf connect is technically zarf package connect.

from uds-cli.

Hey folks really appreciate all the discussion. We're making the call to keep the uds <action> syntax, with no bundle keyword. As for additional ADRs on the definition/purpose of a bundle, I'm all for sharing more words/context, but am admittedly unsure about what the content of that ADR should be (but that's for a different PR!)

from uds-cli.

helm install works because you're installing a "helm"

I'd push back on this example - helm install installs a helm chart, so its almost 1:1 the same scenario as uds create creating a uds bundle. I don't know that I could make the same case with terraform - so that's a fair example as best I can tell.

I don't have a strong opinion on this, but I am curious what this "other functionality" is that would necessitate clarifying its a bundle action. I guess I was expecting this would always just work on bundles, but there may be additional things that could be pulled into bundles (i.e. non-zarf things like IaC)? Maybe the point you're making is that we don't really know though so why risk it...

Edit: I think "what uds-cli will operate on" is really the crux of the matter. If uds-cli will always operate on bundles then imo there is no reason to explicitly require bundle in the command. That would be analogous to helm requiring you to do a helm chart install, helm chart template, etc, which feels like an unnecessary addition. Maybe to be more direct - would uds-cli ever create/deploy/... something other than a bundle? It may do other types of actions, but (and I could be off) I am thinking it would only ever create a bundle?

from uds-cli.

Just my 2 cents.

I feel that it is premature to remove clarity from such a naval tool. For example something like helm install, the action it performs on what is widely known as a helm chart has history. It's intuitive and it feels natural for chart to be implied when using the helm tool.

What is UDS-CLI? What is UDS to the world? At first glance with a little digging I find UDS is an acronym for Unicorn Delivery Service. Okay cool, that to me sounds like maybe UDS-CLI is a multi-purpose command line interface tool that makes software delivery much easier for me. What are all the cool things it can help me do? Well, it has one purpose and that is to create and deploy these things called Bundles which are well orchestrated collections of zarf packages. It also inherits a lot of zarf functionality. Well what is zarf? Why isn't this just a feature of zarf if thats all it does, someone may think to themselves? Its not the multi purpose Unicorn Delivery Service tool I initially assumed.

That is just an example of the thoughts that would go around in my brain when coming across this tool. Implying bundle just feels premature and possibly handcuffs the potential of the tool. That is all.

Edit: With that being said, removing it isn't that serious. I'm on team keep the bundle syntax and just wanted to say why.

from uds-cli.

Hello folks, as product architect, I approved this change when it happened, I think @Racer159 is right an ADR would be needed to change this going forward. I'll give you my take on why I am fine with it:

• UDS CLI will have more behavior than just bundles, but we dont know what or when
• But like Helm, the primary thing will be the bundle...the only reason anyone feels this normal is because helm made it so for that tool, and that's where we are with UDS-CLI, it's normal if we make it normal
• For additional things there may be a tree of subcommands pushed lower, similar to the zarf tools <command> pattern, but we don't know what those will be yet
• In the big picture, UDS CLI will be firstly a bundle handler and secondly, an view into the UDS Runtime Engine (name tbd), for which there will also be a UDS UI, both the CLI and UI will call effectively the same REST (tbd) endpoints. The only real in-CLI business logic will be that which must run locally, i.e. a zarf package <COMMAND> equivalent for bundles.
• No final decision on miscellaneous tools, but I suspect it might end up being something like kubectl plugins for those things.

FWIW, I originally had both zarf package create + zarf zarf.yaml and zarf package deploy + zarf package.tar.gz so you could shorthand--but lost that argument (can't seem to find it now)

from uds-cli.