What should Deppy be?

[perdasilva]

Hi everyone,

I'd like to start a discussion around the future of Deppy as a project. I think pivoting back to the idea of it being the "dependency manager for Kubernetes" resonates, but we haven't really developed it far enough to scope what that actually means.

I guess that, in terms of user outcomes, it would be nice to drop deppy into a Kubernetes package management project so that the it can easily add a breadth of dependency/constraint management features. This could be picking dependencies, or validating that the next state you want to move to is consistent in terms of the constraints imposed on the set of packages. These constraints could be user, or operator author defined, as well as taking into consideration any inherent constraints coming from Kubernetes (e.g. CRD uniqueness limitations).

Do we feel like there's enough juice to be worth the squeeze here? Alternatively, we could also sunset the project and put it back as a package within the operator-controller. But if we feel like Deppy as a project has legs, I'd be curious to know what you (as a kube engineer) would like to see out of it (i.e. features, behaviors, use-cases, outcomes, etc.).

Cheers,

Per

[m1kola]

We are no longer put effort into Deppy (mostly because we do not use it in OLM). So I think we can close this discussion for now.