Follow-up: discussion on archiving Kubefed

[Paul Morie]

Everyone-

In recent Kubecon SIG updates we have previously communicated that SIG leadership has been considering archiving the Kubefed[1] repository. This topic was given discussion recently in agenda meetings and Jeremy and I took an action item to discuss offline. This communication is a follow-up on that action item.

TLDR: Our current favored option is to archive the kubefed project but we are soliciting community input before making a final decision. Continue reading for rationale.

In our discussions, Jeremy and I considered the following questions:

Is the project serving a real, specific need?

• There is a clear need for managing config across clusters, but Kubefed may be too broad. For the past few years, the SIG has preferred more focused projects with concrete scope. There are also many widely-adopted tools for managing config that are applied in multi-cluster scenarios successfully today.

Does it have continuous velocity (or at least investment)?

• Originally planned beta EO2018, and promised beta several times since with contributor dropoff.

• There have been no regular status updates or SIG communication.

Is the community being served?

• Kubefed questions in Slack have usually been unanswered over the past several quarters.

Does it have a roadmap?

• The roadmap has not visibly changed or progressed since 2020.

• A beta release has been ‘coming soon’ since 2018.

Does it have maintainers from two or more companies?

• Current proposal is originating from a single company. Might be best served with a fork focused on specific needs.

What would we need to see in order to receive kubefed today?

• Engaged contributors from different vendors or independent

• Roadmap that aligned with community direction

• Need to see steady contributions

• Active community engagement on support questions

• Since our SIG is focused on exploring specific problems with small scope, a project like Kubefed might be a better fit for CNCF than Kubernetes community.

Archiving will allow us to send a clearer signal to our community about the state of the ‘federation’ concept and associated projects in Kubernetes and to better set expectations around development and support in the area. There are a number of legacy materials present on the internet that can be confusing given the present state of the project and SIG materials. Archiving will enable us to send a clear signal about the direction the SIG is headed in and how we will approach our work.

It’s important to note that archival is not deletion. The code will still be browseable and forkable on github. People and organizations will still be able to use existing kubefed images and maintain their own forks. People and organizations will still be able to collaborate and base new projects around forks of the source.

If we proceed with archival, we will communicate another notice including an archival date.

In keeping with the values of our community, Jeremy and I both felt it was important to share our rationale and solicit community feedback around this decision as the SIG leadership. Let’s take 2 weeks to think this over and discuss together and discuss in the upcoming SIG meetings.

Thanks,

Paul Morie

Jeremy Olmsted-Thompson

SIG Multicluster Chairs

[1] https://github.com/kubernetes-sigs/kubefed

[Josh Berkus]

On 8/9/22 08:18, Paul Morie wrote:
> In keeping with the values of our community, Jeremy and I both felt it
> was important to share our rationale and solicit community feedback
> around this decision as the SIG leadership. Let’s take 2 weeks to think
> this over and discuss together and discuss in the upcoming SIG meetings.
>

+1 on archiving. We should announce on k-dev first.

--
-- Josh Berkus
Kubernetes Community Architect
OSPO, OCTO

[Max Jonas Werner]

I agree with Paul and Jeremy. As a reviewer on the project I've been seeing very little general engagement on kubefed and when PRs occasionally turn up it's hard to bring them in line with the project's goals because there is no roadmap or anything like that.

+1 for archiving

/max

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-multicluster" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-mult...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/CANN1U8-T85FZPggeHjY6vVSoo2wiqxyRoHd5c5Z1gvCXFbX5tA%40mail.gmail.com.

[Davanum Srinivas]

+1 to Archiving!

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-multicluster" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-mult...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/8785ac0f-408c-fef7-4bc2-f144df799cb3%40redhat.com.

--

Davanum Srinivas :: https://twitter.com/dims

[David Oppenheimer]

Makes sense. In the broader announcement, can we point people to any still-active projects in that space?

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/CANw6fcGfwu2oFRVhPakN%3D_UbvNd%3DZ_%3DX3VuAHP0ZeJwaA3kfOA%40mail.gmail.com.

[Jimmi Dyson]

+1 to archiving. This has also been discussed briefly in Slack (https://kubernetes.slack.com/archives/C09R1PJR3/p1659434697827379) and has agreements from contributors and maintainers there.

We should absolutely point people to active projects, gathering a list of these and linking from kubefed README as part of the archival would be great.

Karmada (https://karmada.io/) seems the natural successor as it inherits a lot from kubefed it seems, but there is no migration path.

[Irfan]

+1 to archiving

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/a7c97ba6-1f4c-450e-a438-9da3d55f92d3n%40googlegroups.com.

[jpa...@redhat.com]

I'll throw https://open-cluster-management.io as another active community that could be a successor on the list. This community has also contributed code to kubefed.

[Mike Ng]

+1 on archiving.

The https://github.com/kubernetes-sigs/work-api is also worth a look. It's a SIG project that is trying to define a common API for delivering workload to multiple clusters. The repo contains a reference implementation and the design doc is here. Both previously mentioned projects ( https://karmada.io/ and https://open-cluster-management.io/ ) leverage the Work API.

[Junior]

I’m fine on archiving, but we cannot foster the feature. We need clear (or almost clear) options/alternatives on the main page, so people get directed to something instead to a dead end.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/33b0d943-b5b7-420d-ab1b-727658dad20dn%40googlegroups.com.

[Di Xu]

+1 to archiving. NB.

https://github.com/clusternet/clusternet is another alternative, which works as an out-of-the-box add-on to enable multi-cluster capabilities.

[Zach Zhu]

+1 to archiving.

In fact, it's hard to maintain the project as a SIG project under current state of activity and SIG goals.

Since our team at Ant Gourp is still actively using and maintaining KubeFed as an internal fork, if there's someone who still stick to using KubeFed due to various reasons and would like to make contributions to it, feel free to contact me (zqzten) on Kubernetes Slack.

[Hongcai Ren]

+1 to archiving.

I totally agree with Jimmi that we should absolutely point people to active projects from Kubefed README.

Karmada (https://karmada.io) is the natural successor as it inherits the main concepts from Kubefed and most of the features in Kubefed are reformed in Karmada.

Now you can see the migration guideline from https://karmada.io/docs/administrator/migration/migration-from-kubefed. 

In addition, the OCM(https://open-cluster-management.io/) is also a great alternative. Both Karmada and OCM are CNCF projects and are widely adopted by users.

[David Eads]

Related to this thread, we just published a CNCF blog article about Karmada and Open Cluster Management [1] as active projects tackling the multicuster space.  Check it out if you'd like to read about those alternatives.

[1] https://www.cncf.io/blog/2022/09/26/karmada-and-open-cluster-management-two-new-approaches-to-the-multicluster-fleet-management-challenge/ 

[ryan zhang]

Hi, I wonder if we have reached the conclusion to archive? If so, I wonder if there is a timeline to officially archive kubefed? 

[Carlos Santana]

When is the kubefed git repo going to be archived?

[Davanum Srinivas]

Wanna help with that Carlos? let's push for archival with an issue https://github.com/kubernetes/org/issues/new/choose

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-multicluster" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-mult...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/9f8d81d1-07d1-4985-a7bf-d76197deb971n%40googlegroups.com.

[Carlos Santana]

Dims !

I just joined sig-multicluster slack channel, trying to make new friends, ask stupid questions [1], and learn something from multicluster gurus

Now you want me to put the final nail in the coffin? :-)

Fine, here is the issue https://github.com/kubernetes/org/issues/4122

[1] https://kubernetes.slack.com/archives/C09R1PJR3/p1679165593641329