search

kubernetes-sigs / mcs-api

This repository hosts the Multi-Cluster Service APIs. Providers can import packages in this repo to ensure their multi-cluster service controller implementations will be compatible with MCS data planes.
Apache License 2.0
208 stars 40 forks source link

Conformance test: importing services #66

Open skitt opened 3 weeks ago

skitt commented 3 weeks ago

https://github.com/kubernetes/enhancements/blob/master/keps/sig-multicluster/1645-multi-cluster-services-api/README.md#importing-services

Using DNS (since accessing exported services relies on DNS), check that:

tpantelis commented 5 days ago
  • [ ] Exporting a ServiceExport results in the creation of a corresponding ServiceImport in each importing cluster hosting the corresponding namespace

This was done as part of https://github.com/kubernetes-sigs/mcs-api/pull/64.

  • [ ] Importing clusters without the corresponding namespace don’t get a ServiceImport (the namespace may be created automatically, so the test can’t assume that because it hasn’t created the namespace, the namespace doesn’t exist)

This test would have to be optional and should first wait a reasonable of time for the namespace to be created and, if not, then skip the test. It can also have a specific label (eg "Namespace") so users can skip it if they know their implementation doesn't support auto-creating namespaces.

  • [ ] EndpointSlices are labeled as follows: “multicluster.kubernetes.io/service-name” pointing to the ServiceImport, “multicluster.kubernetes.io/source-cluster” pointing to the source cluster

This should be covered by https://github.com/kubernetes-sigs/mcs-api/issues/70.

skitt commented 5 days ago
  • [ ] Importing clusters without the corresponding namespace don’t get a ServiceImport (the namespace may be created automatically, so the test can’t assume that because it hasn’t created the namespace, the namespace doesn’t exist)

This test would have to be optional and should first wait a reasonable of time for the namespace to be created and, if not, then skip the test. It can also have a specific label (eg "Namespace") so users can skip it if they know their implementation doesn't support auto-creating namespaces.

The test isn’t about automatically created namespaces; all it’s supposed to do is verify that clusters without a given namespace don’t get the corresponding ServiceImports. I suspect I came up with this based on Submariner’s old behaviour; in practice if the namespace doesn’t exist then the ServiceImport can’t either! The parenthetical about automatically-created namespaces is a caveat, that’s all.

So really this test is nonsensical and should be ignored.