metacontroller
metacontroller copied to clipboard
GoogleCloudPlatform
Is this repo maintained?
The abstractions provided by MetaController look really nice. I'd love to use it for a project.
However, it looks like a PR hasn't been merged since March, and the maintainers haven't replied to an issue in about that long.
Is this maintained?
In short, no. I was the only maintainer at the time when I left Google at the end of March. I don't have access to merge anything on this repo since Google still owns it.
Metacontroller is a great project, and it would be terrible to see it wither. @enisoc do you know who, in addition to yourself, would be the most appropriate contact to discuss possible futures for this effort?
@AmitKumarDas has been doing experiments on a fork (https://github.com/AmitKumarDas/metac) and has mentioned that he'd be interested in upstreaming that work if a new home is found for the project.
@enisoc - thanks for all your efforts on this project, I also think it is a great one. I hope you remain involved in some capacity.
I would be glad to contribute and maintain MetaController in whatever form the community decides. Is there anyone who can start a new home/repo etc? Do we need any approvals from its current owner?
Same here, ive actually finished developing a rabbitmq controller, that creates rabbit resources based on my crd. I intend to add it into production - is this a risk?
@AmitKumarDas @enisoc I think the airship project (https://www.airshipit.org/) may happy to host this project and provide CI, but that would also depend on the current owner's desires.
Perhaps @droot can comment on whether Google intends to do anything with this repo.
As for myself, much to my own surprise, it turned out that between a startup and a toddler, I don't have enough free time to maintain this as a side project. However, if someone decides to take on the maintainer role on their own fork, I would be interested in contributing.
I would be interested in helping to maintain this, we've found it to be a really useful abstraction
@droot and I have been talking about this in the background a bit. I think our team (the KubeBuilder team) can take over maintenance here, but we've got some logistics to figure out about long-term maintenance, new features, etc.
In the short-ish term, we'd like to investigate rebasing the internals on controller-runtime, so that we're not maintaining two similar but distinct codebases.
but we're also very happy to have community help as well from anyone who is interested, especially those who are already familiar with the codebase
e.g. @AmitKumarDas @mikebryant
It will be really good to have this embedded into controller-runtime and get more community support. Let me know if there are any proposals with this investigation & I will be happy to join.
Let me know if there are any proposals with this investigation
I did some hacking last night on replacing the internals with controller-runtime. There are currently some blockers (e.g. no way to "stop" controllers easily in controller-runtime w/o stopping the entire set of informers). Some of these might be mitigated if the proposal to move to a sidecar-based approach is moved to (e.g. sidecar means you're not starting and stopping controllers on demand).
I'd like to figure out a plan to move towards controller-runtime internals, so any input there would be super-helpful. If anyone's super-interested in tackling it themselves, I'm happy to provide guidance.
In the mean time, we'll figure out how to get correct permissions set up for this repo.
Additional things that would be helpful immediately from community members:
- Issue triage: there are a lot of issues in this repo that seem inactive. It'd be good to get questions answered, up-to-date bug reports tagged as such, and enhancement requests tagged as such.
@enisoc @DirectXMan12 @AmitKumarDas - just wondering if this could be a kubernetes sig project?
Quite possibly -- we'd need to figure out the logistics, but I think it makes sense to put it under the server-sdk subproject (a.k.a. the KubeBuilder subproject)
Just wondering, if all of us agree to continue with the original purpose of MetaController. In other words, it provides us with couple of controller implementations (abstracts the developers from programming to k8s) and lets us focus only into business logic side of things.
I'll let others weigh in too, but my take is this:
metacontroller lets you program your controllers in any language, in a "pure" (in the functional programming sense) way, without having to worry about side effects. You're always going to have to worry about k8s to some degree (e.g. finalizers), but you shouldn't have to worry about trying to connect to k8s directly, make API requests directly etc -- you should just be able to take inputs and return what you want to happen (i.e. the state of the world).
Hi - My hope is that MetaController would retain the spirit of it's original ethos, in that it enables people like me to program essentially stateless controllers in any language of my choice, only caring about emitting a JSON document (I like the existing format) to describe the resources that I want associated with my CRD.
In it's existing state, it has created a toolkit that gives a very low barrier to entry (for instance I don't need to understand much about controllers, Go, or k8s libraries), and makes it easy as a DevOps/SysAdmin to create "throwaway" operators for my organisation/workplace/life/etc. For example, an acid test of it's future would be that any changes made going forward would not break existing MetaController operators in the wild (or at least without very good reason...).
It would be good to see some sort of new MetaController road map (https://github.com/GoogleCloudPlatform/metacontroller/issues/9) come out of this, which would help clear up any ambiguities around aspirations. Thanks, Piers Harding.
I'd add to the roadmap a support to bring more objects with the sync request, For example, I have a crd with sensitive values, so I saved them in a secret, addad a ref field in my crd, gave rbac clusterrole permissions to that specific secret (for my custom controller), then used kubernetes API to retrieve the secret in the controller.
Would be nice to define resources that metacontroller will bring to the request (like according to annotations)
So, will this project be moved to the kubernetes-sigs org?
We need to decide that, and there's logistics to work out, but it seems reasonable to me.
@piersharding I think we're mostly in agreement there, and I don't think any breaking changes would be made w/o introducing a new major version.
Sounds like we should get on call to discuss further on the logistics and the roadmap/approaches? Is there a sig community meeting where we can add this as a agenda topic? or setup a new call?
You can propose it for the kubebuilder meeting next month, but I think there's some stuff to figure out on our end too.
@DirectXMan12 I wanted to propose MetaController for kubebuilder meeting. However, I am not sure of the meeting/doc link.
join the kubebuilder mailing list listed in https://github.com/kubernetes-sigs/kubebuilder#resources and you'll get a calendar invite with the details
We discussed this a bit in the KubeBuilder meeting today. The KB community is supportive of this.
I think the next step here would be to have someone from the metacontroller side write up a little proposal for this that we can submit to kubernetes. I'd be happy to review or provide guidance.
Maybe @AmitKumarDas since he's maintaining the only active fork of metacontroller??
metacontroller is just enough abstraction for non GO programmers like me. it would be great to see this project maintained
All. Just wanted to give an update w.r.t submitting a proposal to add metacontroller to KB community.
I have been busy all these days and have not been able to write the proposal. It will be great if anyone in the community can send out the proposal. I have been talking with some of the metacontroller users to do the same without any success.
Happy New Year Everyone. Some of us including @alaimo @piersharding @kmova have put together the initial draft proposal to maintain Metacontroller as a project in kubernetes-sigs.
Here is the link to the draft. We would like to hear what others think about this proposal. I would definitely need help from @DirectXMan12 @enisoc @mikebryant @luisdavim & others with their suggestions to help move this proposal forward.
cc @rosenhouse @debianmaster @arielb135 @intlabs @grzesuav