Upgrades & Dependency Management

[vibhas]

Some advanced were out of scope for the MVP. This epic tries to capture the use cases for two things: 1) Advanced Scenarios for Package Distribution, Installation, & Upgrades and 2) Dependency Management

Advanced Package Distribution, Installation & Upgrades User Stories

Distributing new versions of Packages

• [Docs Improvement] Package author needs a recommended way to package newer versions of their packages. For example: how to version them, etc
• [Docs Improvement] Package author needs a recommended way to distribute their newer versions of their packages
  • Package authors might have questions like “Should we update the same package repository or create a new one when releasing new packages?”, etc.
• Package authors should be able to specify if a particular version of the package has breaking changes
• Package authors should have a way to specify that a package has a bug/fault and should not be installed
• Package authors should be able to specify when a version goes out of support
• For packages that have an operator and instance images, Package authors want to make sure that the operator does not upgrade if the installed images are incompatible with the new version of the operator.
• Package authors should be able to specify how a package needs to be upgraded
  • For example: In order for a package to upgrade from version 1 -> 3, it needs to go from 1 -> 2 and then 2 -> 3.
  • The system needs to take into consideration details such as breaking changes.

Distributing and installing a set of opinionated packages

• Package authors should be able to define a recommended set of packages (specific versions and configurations) that are tested and work well together
  • Consumers should be able to install this set of packages in one go
• Package authors should be able to logically nest package repositories according to their use case

Installing and upgrading packages

• When two repositories contain the same package, consumers should be able to distinguish the origin of those packages
  • More importantly, kapp-controller should not fail when adding a repository that contains a package that is already available on the cluster
• Package consumer should be able to install the latest version of a package without specifying the version and without the package being auto-upgraded
• Package consumer should be able to install the latest version of a package and keep it updated when new versions are available
  • The system needs to take into consideration such as breaking changes
• Package consumer should be able to view what is latest package version available for packages that were explicitly locked at a particular version
  • Users might want to know what is the latest version available that their installed package is upgradable to. For eg: the installed version of package Foo is v1.1.1 and it's upgradeable to v1.4.1.
• Consumers want to learn more about what's in an update so that they can decide what to do with the update. For example, are there breaking changes? Is there a CVE fix? Are there new dependencies?
• Consumers would like to see an audit trail around updates (especially when the system chooses to update a package/dependency.) In general, customers like to see differences between system initiated updates and user initiated updates.

Dependency Management

Package Depends on Another Carvel Package

• [Required Dependency] Creating a package that depends on one or more Carvel packages
  • Package authors should be able to define a dependency to other package(s) in their Package CR. They also should be able define the version of the dependency.
• [Required Dependency] Installing a package that depends on one or more Carvel packages
  • If the dependencies are already installed on the cluster, the package is installed successfully.
  • If the dependencies are not already installed on the cluster, the dependencies should be first installed.
    • Package consumers need a way to configure values for the dependencies as well.
• [Required Dependency] Updating a package that depends on one or more Carvel packages
  • If the new version of the package needs new dependencies or newer versions of the existing dependencies, then they should be installed first.
• [Required Dependency] Updating a package that is a dependency to another Carvel package
  • When updating a dependency directly, we need to take into consideration all the packages that are dependent on it. For example: If Harbor v1.0 depends on Cert-Manager v2.x, I should not be able to upgrade Cert-Manager to v3.0 because Harbor will stop working.
• [Required Dependency] Deleting a package that depends on one or more Carvel packages
• [Required Dependency] Deleting a package that is a dependency to another Carvel package
  • It should not be allowed!
• [Optional/Conditional Dependency] Creating a package that depends on one or more Carvel packages conditionally (when a specified condition is met)
  • Package authors should be able to define an optional dependency to a Carvel package
• [Optional/Conditional Dependency] Installing, updating or deleting a package that depends on one or more Carvel packages conditionally (when a specified condition is met)
• [Optional/Conditional Dependency] Updating or deleting a package that is an optional dependency to another Carvel package

Package Depends on specific APIs (not a Carvel package)

• Package authors should be able to describe which APIs are provided by their package
• Creating a package that depends on specific APIs. Authors should be able to define a dependency in the Package CR.
  • A specific CRD (i.e. ‘kubectl get crd/foo’ equivalent)
  • A specific GroupResource / GroupVersionResource (i.e. check /apis/foo.bar.com/v1/ and make sure it has widgets)
• Installing, updating or deleting a package that depends on specific APIs.