istio: Multiple virtualservices on the same host do not merge

One option that we recommend is to use some form out out-of-band composition of these files into a single VirtualService resource which is then pushed. This requires you to roll your own composition today but this is something people do a lot with CI/CD systems using pretty much any text templating system.

@louiscryan this is not acceptable, and a clear regression of virtual services from the ingress resources that existed in 0.6. What is the complication of just supporting what was supported in 0.6? Doing this kind of post processing especially in dynamic systems causes a ton of edge cases for the post processor specifically around the removal and updating of routes.

This should be fixed ASAP, to be in parity with the way it worked in 0.6.

@ZackButcher ^^

cc @rshriram @louiscryan This is an issue for a customer. The customer uses helm to manage multiple services. These services share the host but use different URI matches on two virtual services. What should be the advice for people who use helm to manage ingress-type resources?

I understand the concern, but this argument is a clear strawman. The possibility of ambiguities is problematic, I will concede that.

The problem we are facing is not with ambiguous matches. We are currently blocked because Istio does not support merging routes at all. Give us enough rope to hang ourselves. That’s all I’m asking.

@nrjpoddar Well, I do not agree to the path of having to change files as services get installed. if that were the case, would just update the virtual service to include all needed URIs. My opinion is to give more thought and treat multiple files as pure conf files which can be merged.

Even if the matches were constrained to path segments and not other properties of the traffic you can still have ordering issues when merging.

Really? Does that mean merging the following examples would be nondeterministic?

• for host example.com match path /hello and route to X
• for host example.com match path /world and route to Y

@rshriram @vadimeisenbergibm Hostname per service seems a lot to ask customers to setup/configure if we have more than say 10 services to be exposed. Here is a scenario where a standard nginx has worked well for me in the past

1. Create a server nginx conf such that it can listen on just one host name
2. Have a bunch of config files included which can be used for redirection. The key is that each service just brings it’s own configuration for redirection but the access to service is always using one host name.

Wondering how this can be done using Istio ingress-gateway? i.e something like do not treat virtualservice with same host as error but really treat as a merge. This way each service can bring their own match parameters and not need to keep modifying the same Virtual service using something centralized. May be these last few statements are based on me not knowing if there is a way to achieve this already.

@louiscryan thanks for your response! I’ve provided a relatively contrived but as simple example as I can provide to help with context below.

Just a couple of comments before I describe the scenario:

1. The host * is not part of our specific requirements.
2. Order is not a concern because we’re not submitting nested routes.
3. If the user is going to submit nested routes where absolute ordering is necessary then that’s up to them to do that properly not the opinion of Istio because envoy supports this behavior.

The scenario is you have serviceA and serviceB each belong behind a single subdomain subdomain1 and are routed to unique input channels. The input channels cannot be added to the host because they would violate RFC-1035 size limits as we don’t have control over what they are.

---
- apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
     ...
    name: serviceA
    ...
  spec:
    gateways:
    - istio-gateway
    hosts:
    - subdomain1.some.host.com 
    http:
    - match:
      - uri:
          exact: /run/before/input-channel-6351547589003002
      - uri:
          exact: /ping/run/before/input-channel-6351547589003002
      route:
      - destination:
          host: serviceA.common-ns.svc.cluster.local
          port:
            number: 8080
---
- apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    ...
    name: serviceB
    ...
  spec:
    gateways:
    - istio-gateway
    hosts:
    - subdomain1.some.host.com 
    http:
    - match:
      - uri:
          exact: /run/before/input-channel-5361011480850776
      - uri:
          exact: /ping/run/before/input-channel-5361011480850776
      route:
      - destination:
          host: serviceB.common-ns.svc.cluster.local
          port:
            number: 8080

I would constrain scope here, leverage reasonable assumptions to get the job done. We’re/were EEP so I’m happy to come to MV or SF office and work with ya’ll.