search

carvel-dev / kapp-controller

Continuous delivery and package management for Kubernetes.
https://carvel.dev/kapp-controller
Apache License 2.0
269 stars 105 forks source link

Taint old/faulty Packages from being installed #201

Open jorgemoralespou opened 3 years ago

jorgemoralespou commented 3 years ago

Describe the problem/challenge you have I need a way to reject attempts to install an older version of a package because it has a critical bug, and there is a newer version of the package available w/the fix. When I have a package that has a bug I will probably create a new version that fixes it, and I want to prevent any new consumer of the package to install the faulty version.

Describe the solution you'd like I would like a way to define in a Package definition that the package is obsolete/faulty so that it would show in the output of the CLI. Alternatively I would desire that kapp-controller rejects installing Packages marked as faulty.

cppforlife commented 3 years ago

one thing we need to consider is what it means for InstalledPackages that already use "bad" package version. from k8s perspective it's typically not recommended to differentiate between create vs update behaviour so distinguishing between user installing this version from scratch and user is changing values for already installed "bad" version is problematic.

so may be more concretely, we are looking at 2 aspects: messaging to the user that "bad" version is in use, and separately ensuring that we are able to "skip bad version" when going through automated upgrades. i think latter part influences how auto upgrades are implemented -- today for InstalledPackages that opt into auto updates, publishing new version would do the job (for now we always skip to the latest version).

neil-hickey commented 2 years ago

I created a PR to get things started on this idea of a Package indicating it should not be used

https://github.com/vmware-tanzu/carvel-kapp-controller/pull/624

It does not handle upgrades. It allows a Package author to indicate the Package is bad, and the PackageInstall will show a new condition also.

neil-hickey commented 2 years ago

Here's a summary of the current field name we are thinking about:

Author: cppforlife (dmitriy)

any other alternative terms to deprecated. coming from api consumption land, deprecate does not typically mean "wont install/upgrade", but rather be aware that it will be removed.

Author: neil-hickey

Some potential words:
discontinued, unsupported, unstable, removed, revoked

Author: cppforlife

removed/revoked to me aligns more if you want to "skip" installing them for new installs. e.g. v5 (revoked) v4 v3
new users asking for latest version will only get v4. existing users who already have v5 installed will continue to be on v5.

Author: joe-kimmel-vmw

obsoleted, abandoned, orphaned, disallowed, blocked, undesirable, do-not-install, rated-0-on-rotten-tomatoes, 0-out-of-10-stars, ...

Author: neil-hickey

I am liking revoked, It semantically aligns with our idea of "this was explicitly marked as undesired by the author" and also "I should skip over something that was revoked". If no-one objects, I will re-word the PR to reflect "revoked". I think it also conveys that, "I am on a revoked version, that's probably not good and I should move off of it"
pivotaljohn commented 2 years ago

"invalidated" ?