kubernetes/cluster-registry appears to be abandoned

[Christoph Blecker]

Can the sig please take a look at https://github.com/kubernetes/org/issues/1499 ?

Cheers,

Christoph

[Klaus Ma]

Hi team,

Any conclusion there? we'd like to use this report as cluster-api for multi-cluster scenario.

xref: volcano-sh/volcano#880

[Paul Morie]

Thanks for bumping this thread, Klaus. We discussed this in a recent meeting and I made a status update on the github issue but forgot to respond in this thread. RainbowMango has indicated they want to discuss further, so I have added an agenda item to the July 07, 2020 meeting for us to discuss. We'll set a date for lazy consensus after that point.

Thanks,

Paul

--
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/7614211f-5e56-478d-90f1-4d47862b8660n%40googlegroups.com.

[Klaus Ma]

Hi Paul, 

Thanks very much. I may also join the meeting to share our cases :)

On Tuesday, June 30, 2020 at 3:27:51 AM UTC+8, Paul Morie wrote:

Thanks for bumping this thread, Klaus. We discussed this in a recent meeting and I made a status update on the github issue but forgot to respond in this thread. RainbowMango has indicated they want to discuss further, so I have added an agenda item to the July 07, 2020 meeting for us to discuss. We'll set a date for lazy consensus after that point.

Thanks,

Paul

On Sat, Jun 27, 2020 at 8:04 PM Klaus Ma <klaus...@gmail.com> wrote:

Hi team,

Any conclusion there? we'd like to use this report as cluster-api for multi-cluster scenario.

xref: volcano-sh/volcano#880

On Monday, May 25, 2020 at 6:08:53 AM UTC+8 Christoph Blecker wrote:

Can the sig please take a look at https://github.com/kubernetes/org/issues/1499 ?

Cheers,

Christoph

--
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-multicluster+unsub...@googlegroups.com.

[Nikhita Raghunath]

Hey folks,

Was there any conclusion on how to proceed with the cluster-registry repo?

The issue about the repo being inactive has been open for more than a year - https://github.com/kubernetes/org/issues/1499.

Recently, there was a PR created to remove 2 of the 4 approvers of the repo - https://github.com/kubernetes/cluster-registry/pull/292.

Thanks,

Nikhita (on behalf of the GitHub Admin team)

[Paul Morie]

We had some discussion but not a conclusive one. I've added it to the agenda for this week's meeting.

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/027b8ccc-ad46-4d3c-9c3b-048621702f61n%40googlegroups.com.

[Paul Morie]

It will be archived per our lazy consensus. I'll work on cutting the tombstone commit today.

[Paul Morie]

Hi Nikhita-

I've cut a tombstone commit in https://github.com/kubernetes/cluster-registry/pull/293 which has been merged. How do we proceed with archiving the repo?

Thank you,

Paul

[Nikhita Raghunath]

I'll take care of archiving the repo :)

[Gabriel Rosenhouse]

Hi SIG Multicluster,

I put this on the agenda for next week's meeting, but figured I'd drop an email too.

I'm looking at KEP-1645 and really like the APIs … but there's one little thing...

Our users want to enable sharing of services across clusters even (especially?) when those clusters are administered by different teams, and the cluster admins don't fully trust each other.

So, depending on how you frame it, it's either about exporting/importing services between different clustersets, or just doing it entirely without reference to clustersets. 

I think a solution would start with some preliminary step of "federate this namespace with that one", and that intent goes into the multicluster controller(s) somehow.  But once that's out of the way, I'd hope that the existing in-cluster ServiceExport API (and ServiceImport + Endpoints) should still make sense for the application teams who are using the clusters, and that would result in DNS + kubeproxy doing the right thing.

So I suppose my question is: does this idea of ServiceExport-beyond-the-Clusterset raise red flags, like "oh, no, that's a bad idea"?  Or is the reaction more like "of course, we always expected people would extend in that direction"?

Anyhow, I put it on the call for next week, and can probably show up with a quick demo, just to get the idea across, if folks are interested.

Thanks!

Gabe

[Aswin Suryanarayanan]

We do have an implementation of MCS-API in the Submariner [1] project and we now restrict the serviceExport to only the clusters which have the namespace of the service. This do give control to destination clusters which service can be imported, but not the source which exports the service

Now if we allow exporting the service beyond a clusterset, it would add a set of challenges like the datapath connectivity between the Clusterssets , should we give all members in a Clustersset access to the others and if so why all the clusters can't be in the same clusterset rather than creating a "superclusterset" and so on. So It seems like it would make the implementation much more complex

[1]https://github.com/submariner-io/lighthouse

Thanks!

Gabe

--
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/MWHPR0501MB3689323EC14FFD4E6D994E91C9599%40MWHPR0501MB3689.namprd05.prod.outlook.com.

[Tim Hockin]

I think that what you're proposing is reasonable and probably in-bounds, but has not been thoroughly explored.  I think it mostly comes down to the implementation and what assumptions it can make.  If your pod networks are flat and fully-connected, you can definitely use the k8s Service concept as a cross-cluster LB.  If they are not, then you need something more purpose-built to bring traffic in.  But that can all be hidden impl details -- users don't need to see anything more that ServiceExport/ServiceImport.

Now - go try it and report back when it explodes :)

Tim

--
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/MWHPR0501MB3689323EC14FFD4E6D994E91C9599%40MWHPR0501MB3689.namprd05.prod.outlook.com.