Is this repo maintained?

[rosenhouse]

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?

[enisoc]

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.

[intlabs]

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?

[enisoc]

@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.

[piersharding]

@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.

[AmitKumarDas]

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?

[arielb135]

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?

[intlabs]

@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.

[enisoc]

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.

[mikebryant]

I would be interested in helping to maintain this, we've found it to be a really useful abstraction

[DirectXMan12]

@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.

[DirectXMan12]

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

[AmitKumarDas]

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.

[DirectXMan12]

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.

[kmova]

@enisoc @DirectXMan12 @AmitKumarDas - just wondering if this could be a kubernetes sig project?

[DirectXMan12]

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)