rukpak
rukpak copied to clipboard
RukPak runs in a Kubernetes cluster and defines APIs for installing cloud native content
Enable patching of resources on cluster after a bundle deployment (and bundle) has been created. Users would like to be able to add a label to existing resources on cluster...
Currently, the image source for unpacking bundle images requires the use of Kubernetes and embeds a lot of, likely unnecessary, Kubernetes specific logic and parameters. The concept of unpacking from...
But we have a doc for it (and we link to that doc in a few places) here: https://github.com/operator-framework/rukpak/blob/main/docs/sources/local.md We should rename/refactor to align with its replacement, the `configmaps` source.
## Issue Deploying a helm chart into a different namespace than `rukpak-system` is not possible. If we deploy the following `bundleDeployment` where we defined using the property `spec.config.values.namespace` the target...
Placeholder for now: It looks like the core set of provisioners don't have a way to enable leader election mechanisms that are present in controller runtime.
The logic under `internal/source` is something that would be of use to [operator-framework/catalogd](https://github.com/operator-framework/catalogd). Currently catalogd more or less copies the implementation from rukpak. It would be much nicer if this...
I noticed the `Bundle` and `BundleDeployment` provisioners under `internal/provisioner` don't have unit tests. We should implement some unit tests that are based on running the `Reconcile()` function for each provisioner....
Goal: re-evaluate whether our installation process should have a direct dependency on the cert-manager project. The current rukpak stack has a hard dependency on the cert-manager project to manage the...
The idea is to offer something that is more resource efficient by sharing a common cache inside a single process. This is similar to what is done in kube-controller-manager. The...