cluster-api
cluster-api copied to clipboard
kubernetes-sigs
Support plugins in clusterctl to make provider-specific setup easier
User Story
As a user I would like to be able to use clusterctl to setup my provider with as few commands and scripts as possible, perhaps, just one command.
As a [developer/user/operator] I would like to [high level description] for [reasons]
Detailed Description
As of now, a user of a given cloud provider must use a set of scripts and / or other command line tools to setup a provider. For example, the Azure provider requires a user to use the Azure CLI or the Azure Portal to create an identity for the provider and set a bunch of environment variables in a script that requires base64 encoding. There are a lot of moving pieces that could go wrong. There is a very narrow pit of success.
At this point, to provide a great experience for a user, one must either wrap clusterctl with a set of scripts or another command line, or one must create a new command line tool which would use clusterctl as a library. I don't think either of these paths will end well... I think this leads to a splintered experience for tooling in Cluster API.
What can we do about this?
One solution we could consider is to create a plugin system for clusterctl so that providers could hook into command execution and provide provider specific behaviors, like auth, configuration, customization, etc. Perhaps, we could use something like https://github.com/hashicorp/go-plugin.
/kind feature
I'm generally +1 with the idea, I like seeing clusterctl supporting new use cases.
I think that the discussion should focus on use cases & on defining the required hooks during the full lifecycle of providers (init/upgrade/delete). Also having some sequence diagrams (or better a CAEP) will shape out the idea / document how plugins should work.
Yeah, this is a good idea imo , seems like over time it seems like this is going to be increasingly important as folks run CAPI in production, and are looking to extend it with cloud specific staples (cloud managed databases, object stores are the obvious day 0 requirements that folks often want to integrate w/ vanilla clusters)...
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
@devigned @CecileRobertMichon Should we start working on a proposal for this?
I'm not sure I understand how this fits in with management cluster operator and worry that may have some impact on how this should be designed.
@devigned according to my understanding of this issue, those plugins are responsible for all the provider-specific actions done before running clusterctl init
the Azure provider requires a user to use the Azure CLI or the Azure Portal to create an identity for the provider and set a bunch of environment variables in a script that requires base64 encoding.
Given that, I don't see this work impacting the operator effort, but happy to discuss this if you think this will help. Instead, this effort IMO requires some synchronization with https://hackmd.io/Z9tzIkGJQUaU9VbFuo6I7Q
(doing some cleanup on old issues without updates) /close unfortunately, no one is picking up the task. the thread will remain available for future reference
@fabriziopandini: Closing this issue.
In response to this:
(doing some cleanup on old issues without updates) /close unfortunately, no one is picking up the task. the thread will remain available for future reference
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
