smi-spec icon indicating copy to clipboard operation
smi-spec copied to clipboard

Service Mesh Interface

Results 86 smi-spec issues
Sort by recently updated
recently updated
newest added

**Describe the proposal** When defining TrafficTarget sources and destinations, the elements name and namespace are not validated to ensure that the user has access to those resources. This can lead...

proposal

**Describe the proposal** TCPRoute should include TCP specific matches, including SNI (host) matching. This would allow further matching and filtering to be done on TCP services. **Scope** - [ ]...

proposal

## The issue Currently, the namespace field in trafficTargets are not mandatory: [source](https://github.com/servicemeshinterface/smi-sdk-go/blob/master/crds/access.yaml#L72) [destination](https://github.com/servicemeshinterface/smi-sdk-go/blob/master/crds/access.yaml#L28) But there is no guidance for how to handle these fields if they are empty. ##...

question

**Describe the proposal** For now, there is no specification for UDP traffic. A simple spec could look like that (similiar to the TCPRoute) Example: ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata:...

proposal

I keep hearing from members of the community that "ingress and service-mesh is hard". From a quick sweep of ingress documentation across the different implementers of SMI, users either have...

In the last SMI community meeting, we presented what [Hamlet OSS project](https://github.com/vmware/hamlet/blob/master/spec/service-discovery.md) is and per LinkerD suggestion, we are opening an issue here to continue the discussion. We would love...

Users would like to optionally enable/disable mTLS between services. SMI should have an authentication policy that allows users to configure whether mTLS is enabled at different scoping levels - global...

proposal

In August 2019, @nicholasjackson opened a WIP PR https://github.com/servicemeshinterface/smi-spec/pull/60. Given that it has numerous merge conflicts at this point and no recent discussion on the PR, I'm closing the WIP...

It would be great to have some kind of formal specification for the APIs in this repo; swagger, for example.