TCE experience for packages

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

On item 8, something like tanzu package list --installed would be great, and could also add output columns for namespace, version, and status to address item 7 and 9.
On item 10, tanzu package <package-name> man would be nice to be able to display the package docs and explanation of configurable values.
13, maybe something like tanzu package <package-name> preflight would be nice to check for required resources/storage requirements.
14 seems like you could do a diff between default rendered package templates and existing in cluster rendered package templates. This could potentially be wrapped into the status of item 8 up above.
22 would be good to have something to init a repository, but would/should probably be a whole other plugin
23, is definitely important if we're ever going to have integrations, i.e. I want a 3rd party secret management system, and I want all my packages to auto-consume/auto-populate secrets in said system. There's many of these problems in how apps get constructed, and a single app isn't always a single solution. I think the way to solve this is to add something like package groups/collections in Linux packaging systems, where if I say I want some integrated thing, the package group handles installing all the deps + the integrated configs. Maybe also some additional metadata to list incompatible things that would prevent the integrated application components from being installed. I think this applies to 30 as well.
26, 27, 28, 29 would probably be best solved by having a management tool (think RHT Satellite) to be able to handle available packages, versions, patches, configs allowed in an environment. Basically allowing to download and import/deploy a package repo locally, with syncing capabilities from upstream source.
31, we've considered building something like a mutating webhook that uses a template/marker driven system to perform in-cluster lookups of existing resource values. I think @scottd018 has started something on this at one point that could prove useful.
33 Something like tanzu package install <package-name> --source ./my/package/repo/clone
34 Seems like a metadata issue. Probably would need to have standardized "categories/building blocks" that address components of a platform that are interchangeable, and could enforce limits to how many of the things from a particular category could be installed. I think this applies to 23 as well.

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.

vmware-tanzu / tanzu-framework

TCE experience for packages #1570

Use cases