RFE: Management cluster operator

kubernetes-sigs / cluster-api

Home for Cluster API, a subproject of sig-cluster-lifecycle

https://cluster-api.sigs.k8s.io

Apache License 2.0

3.5k stars 1.3k forks source link

RFE: Management cluster operator #3427

Closed vincepri closed 3 years ago

vincepri commented 4 years ago

Design and implement a clusterctl self-managing operator.

/kind feature /kind design /milestone v0.4.0

vincepri commented 4 years ago

Details TBD, opening this issue just to track for now.

vincepri commented 4 years ago

/area clusterctl

randomvariable commented 4 years ago

Just a note from Kubecon, that we should highlight self-managed clusters for use in gitops in the docs more.

fabriziopandini commented 4 years ago

I'm starting to work with this together with @wfernandes: The main goal the IMO this work should achieve are:

To make CAPI more git ops friendly by making it easier to handle the management cluster with git ops (vs opting out to clusterctl to do so)
To make clusterctl simpler to use for teams of admins by sharing the same settings in the cluster (vs manually synchronizing local settings across workstations)

Looking forward to hearing from others in order to better shape out goals and non goals

zawachte commented 4 years ago

I work on a team that built an operator which leverages clusterctl library to deploy and manage the management cluster.

Its closed source for now ... along with an infrastructure provider my team has been working on. Hopefully open sourcing soon!

Would love to bubble up some of the ideas and code we used to solve our usecase!

detiber commented 4 years ago

Feeding back in the suggestion from the Cluster API meeting today that we should probably call this "management cluster operator" or something similar to more accurately convey what the operator is managing.

vincepri commented 4 years ago

✅ Renamed the issue, it's super explicit now!

richardcase commented 4 years ago

@fabriziopandini @wfernandes - I'm really interested in this. We've been building GitOps+CAPI solutions for customers for a while now (since Dec 19). A "management cluster operator" would really help in simplifying the GitOps+CAPI story.....we have to write a lot of code that essentially replicates init (or move).

We've been toying with the idea of building something and created a very rough test operator that re-used the same package that clustectl uses for init so that the providers are declarative.

Would love to help out.

vukg commented 4 years ago

Oh, that would be cool to work out. @MaxRink was just scoping our operator to use clusterctl lib few weeks ago and we have been pumping up to start working on it for our use case, but we are also happy to contribute to community effort (specs, deployment and code contrib). Definitelly 👍

fabriziopandini commented 4 years ago

Thanks all for chiming in! I will try to set up a working group to define goals and non-goals and collects all the valuable experience you are bringing to this discusssion

MaxRink commented 4 years ago

I did some initial write-up of my Ideas in form of a HLD a few months ago ( https://github.com/MaxRink/cluster-api/blob/feature_clusterctl-improovements/docs/proposals/20200615-Clusterctl-Operator.md ), just hvent found the time to follow up on it.

wfernandes commented 3 years ago

Hey everyone! Thanks for being so patient.

We've updated the Management Cluster Operator CAEP. It now includes content regarding the proposed API and some examples of how it can be used.

We'd appreciate any feedback, comments, suggestions on the API.

fejta-bot commented 3 years ago

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

vincepri commented 3 years ago

/lifecycle frozen