TCE experience for packages

[jorgemoralespou]

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

• As a user, I want to know all the available packages that I can use in my cluster #434

• As a user, I want to know details about the package #433

• As a user, I want to install a package in my current cluster. #432

• As a user, I want to install multiple instances of a (multi-instance) package in my current cluster #431

• As a user, I want my (multi-instance) installed package to have a random name to prevent conflicts #430

• As a user, I want to get installation feedback when I install a Package #429

• As a user, I want to know the installed packages that I have in my current namespace #428

• As a user, I want to know the installed packages that I have in my current cluster #427

• As a user, I want to know the status and version of my installed packages #426

• As a user, I want to know what package configuration can be used #425

• As a user, I want to get an error in the CLI if I provide invalid package configuration #424

• As a user, I want a way to provide “global” common configuration. #423

• As a user, I want to update an installed package to a new version #422

• As a user, I want to update an installed package to a new version with new configuration #421

• As a cluster admin, I want to enforce specific version/versions of a package to all cluster users #420

• As a user, I want to dry-run and pre-requirements check a package install #419

• As a user, I want to know if my installed package is using customized configuration. #418

• As a user, I want my package to be updated if I update the configuration for the package #417

• As a user, I want to be able to delete an installed package #416

• As a user, I want details on new configuration of a package update #415

• As a user, I want to know the status of an upgrade process of a package in an easy way #414

• As a user, I want to customize some package configuration/behaviour. #413

• As a user, I want to consume packages from private repositories. #412

• As a cluster admin, I want to be able to provide global configuration #411

• As an cluster admin, I want to provide package customizations clusterwide #410

• As a cluster admin, I want to taint a specific package from being installed #409

• As a cluster admin, I want to taint a specific package version from being installed (e.g. a buggy version) #408

• As a cluster admin, I want to be able to install packages in an airgapped environment. #407

• As a package author, I want to be able to create a package that can affect an existing package’s provided resources. #406

• As a package author, I want to be able to discover cluster information so that I can use it to customize my package during install #405

• As a package author, I want to have a single configuration resource that will configure multiple packages #404

• As a user and package author I want to be able to provide my own packages. #403

• As a user I want to know which package provides specific software component #402

• As a user, I want the materialized resources of a package. #401

• As a user, I want to know package dependencies and if they can be satisfied before installation #394

• Provide an easy way to set mutable/unmutable resources for packages #1700

[ahuffman]

• 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]

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]

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]

@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]

@ahuffman added item 35 to above list

[jvalkeal]

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]

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]

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