Add provisioner visibility API

[exdx]

See #447 (comment) for discussion and background.

There may be a need for a new first-class API to reflect which rukpak provisioners are installed on-cluster and currently running, to make it clear to cluster admins and users what types of bundle they can expect to install successfully. Especially as more provisioners get added to the project. For example, this could be called RukPakConfig as part of the core API group. The existing rukpakctl tool can integrate with this API as well, to make it easy to modify or read the status of rukpak as a collection of provisioners.

As a user, I would like to:

• Easily know which provisioners are installed and running on my cluster
• Disable certain provisioners from running, freeing up resources
• Enable certain provisioners to run, because I am interested in their added functionality

[joelanford]

Do you think we could (mostly) solve this problem by adding a ProvisionerClass API? Then cluster admins could see which provisioners are available by simply listing the provisioner classes?

[timflannagan]

Is the ProvisionerClass API sufficient for higher level components that consume and/or configure rukpak APIs? What happens if I don't like the behavior of an individual provisioner and wish to use another provisioner that works with my arbitrary bundle format? Is this mapping something we'll need to support, or even provide through any visibility APIs?

[timflannagan]

I guess what I'm trying to wrap my head around is how can a user (e.g. controller) determine which ProvisionerClass resource is needed when I configure a BundleDeployment resource? And whether this is something that could leverage using a visibility API of some sort.

[tylerslaton]

If we added a ProvisionerClass API would the controller for reconciling that API be responsible for also deploying the provisioner's needed resources (Deployments, RBAC, etc)? If it does, then we're able to easily add/remove/view provisioners that are currently installed on the cluster. What's more, rukpakctl has an easy target for understanding/adding to the functionality on a cluster.

I guess what I'm trying to wrap my head around is how can a user (e.g. controller) determine which ProvisionerClass resource is needed when I configure a BundleDeployment resource? And whether this is something that could leverage using a visibility API of some sort.

To me this sounds like when we talked about our need for a metadata definition in Bundles to be able to intuitively self-declare what type of Bundle it is. This could also be fixed by the wrapping API that uses Deppy resolutions to then create BundleDeployments where the cataloging component details what Bundle it is so admins know which provisioners they need.

[timflannagan]

As a side note: It would be nice to be able to have a rukpakctl status (naming TBD) command that outputs which provisioners are available on the cluster. Whether that command hooks into a net new visibility API, or just reads ProvisionerClass resources is fine with me.

[akihikokuroda]

To me, the ProvisionerClass sounds like usable for the plugin provisioner. It defines the provisioner, map provisioner name to the provisioner deployment, describe the dependencies to the other provisioner, and etc...

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.

[tylerslaton]

I'm going to go ahead and freeze this issue. Its been open for awhile and we haven't had any explicit need for this yet. However, there have been questions about being able to turn on/off certain provisioners at will with the recent aggregation of provisioners into a single binary. We should address this as it becomes more pertinent for the project.