vmware-tanzu / tanzu-framework

Tanzu Framework provides a set of building blocks to build atop of the Tanzu platform and leverages Carvel packaging and plugins to provide users with a much stronger, more integrated experience than the loose coupling and stand-alone commands of the previous generation of tools.
Apache License 2.0
196 stars 193 forks source link

TCE experience for packages #1570

Open jorgemoralespou opened 3 years ago

jorgemoralespou commented 3 years ago

List of scenarios that have any relation to Carvel Packaging, status and links to their tracking. This list is currently not prioritized/ordered in any specific way.

Carvel's Package MVP API tracking issue

Use cases

ahuffman commented 3 years ago
ahuffman commented 3 years ago

In addition, I'd like to be able to easily pull all the installed components of an app from my cluster in one shot, and either download or output to stdout as yaml/json. tanzu package fetch <package-name>. This is important when it comes to users providing overlays, as an end user needs to be able to inspect all the resources of an application to determine what they additionally want to customize, especially if the app's templates do not expose the desired configuration.

This leads to item 21, which I think should be as pluggable as possible. Meaning an end user may be a developer or platform operator, and may be doing things in very different ways and accustomed to very different tools, or desire very different tools. I would say this is one of the most important issues to gaining adoption of packages, because if a user can't customize the applications in the way they want, they're not going to use the solution.

jorgemoralespou commented 3 years ago

In addition, I'd like to be able to easily pull all the installed components of an app from my cluster in one shot, and either download or output to stdout as yaml/json. tanzu package fetch

@ahuffman what do you mean here? Do you mean the rendered resources after the package goes through templating, image relocating, etc...? Would it be different from a dry-run command that would give you the output of what would be installed on the cluster or is there a need to fetch what's being installed (where you would also get kubernetes defaulted values and annoying k8s/kapp annotations)? I want to add this use case to the list if not already present, so trying to understand better what you mean. Does it

ahuffman commented 3 years ago

@jorgemoralespou essentially grab the rendered ytt templates of the kubernetes manifests that are being deployed directly to the kubernetes api. So this could either be a dry-run, or a fetch (what's already been deployed) in an easy one-shot command.

This would allow the user/operator to quickly determine if additional overlays need to be authored, and provide a means to test the overlays on locally prior to attempting to configure the application on the cluster itself.

jorgemoralespou commented 3 years ago

@ahuffman added item 35 to above list

jvalkeal commented 3 years ago

One annoying thing for a user is to map a package version to a product version.

Lets say your product is acme and it has a long lifecycle and just released acme 1.2.3. You create a package 1.2.3 for it and you made a mistake in package and will need to release a new package version. Either you keep package and product versions completely misaligned(which is confusing) or if you need to update a package you get misaligned versions(which is even more confusing).

Would there be any way to keep package/product versions aligned and have some kind of a package version postfix denoting fixes to packaging?

Essentially telling user that this package 1.2.3 is for product 1.2.3 but there's a new updated package for same product version.

jorgemoralespou commented 3 years ago

One annoying thing for a user is to map a package version to a product version.

Agreed. There's been a lot of discussion around this topic, and so far conclusion is that packages versioning should be decoupled form product versioning. The latter should be part of the package metadata. Not sure when or how will be implemented, but definitely a problem not specific to TCE but related to the whole Carvel Packaging space. cc/ @vibhas

shyaamsn commented 2 years ago

@renuy You might want to take a look at this.