Only unique values for domains are permitted error with Istio 1.1.0 RC1 about flagger HOT 19 CLOSED

I think this can be done simply enough by putting a quick for loop over the gateways supplied by the canary in the syncVirtualService function?

from flagger.

Hey @tzilist is this a typo?

gateways:
- www.myapp.com
- mesh

The gateway address can't be an external domain, maybe you are referring to the the hosts array?

from flagger.

Here is how i tested this:

web app canary maps to <domain>/:

apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: app
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
    match:
      - uri:
          prefix: /
    rewrite:
      uri: /

api canary maps to <domain>/api

apiVersion: flagger.app/v1alpha3
kind: Canary
metadata:
  name: api
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
    match:
      - uri:
          prefix: /api
    rewrite:
      uri: /

I use the same external domain and I have 2 virtual services attached to it, one for / and another for /api

from flagger.

@stefanprodan oh shoot, yes! The examples should have

host:
- www.myapp.com
gateways:
- my-gateway
- mesh

I believe the issue when you add the - mesh into your gateway with istio. Your examples will certainly work.

To give a bit of background - we are creating an api of a few microservices. All of them are exposed via a singular hostname (and subsequently routed with a namespaced uri prefix). If we want to do canary deploys that allow the gateway and the microservices to both interact with the new canary pod, I am not sure that your example will work (since you have bound the VirtualService only to a gateway and not the internal mesh).

from flagger.

I think that we would also be ok with just having the gateway exposed to the canary for now. The simple solution (for now) might also be to remove the - mesh from gateways if one is supplied? Entirely up to you though! :)

from flagger.

This really is an istio issue at it's core. Here are the docs about it:

https://preliminary.istio.io/help/ops/traffic-management/deploy-guidelines/#multiple-virtual-services-and-destination-rules-for-the-same-host

Note on this section here:
3. A VirtualService can only be fragmented this way if it is bound to a gateway. Host merging is not supported in sidecars.

from flagger.

If we want to do canary deploys that allow the gateway and the microservices to both interact with the new canary pod, I am not sure that your example will work (since you have bound the VirtualService only to a gateway and not the internal mesh)

@tzilist Flagger bounds the virtual service to the mesh gateway no matter if you specify a custom gateway or nor.

from flagger.

A VirtualService can only be fragmented this way if it is bound to a gateway.

This is what Flagger does, if you don't specify a gateway it will bound the service to the mesh gateway. If you specify a gateway, Flagger will bound the service to that gateway and the mesh one.

from flagger.

@stefanprodan Sorry, I think my message was kind of confusing after re-reading it. Here is an example of my canary file

gateways:
    - istio-system/my-gateway
    # Istio virtual service host names (optional)
    hosts:
    - www.myapp.com
    # Istio virtual service HTTP match conditions (optional)
    match:
      - uri:
          prefix:  /api
    # Istio virtual service HTTP rewrite (optional)
    rewrite:
      uri: /

The issue occurs when the generated virtualservice looks like this

host:
- www.myapp.com
gateways:
- my-gateway
- mesh

If I generate multiple virtualservices with the same host and gateway sections, then istio throws the error above.

It might be worth just having flagger add the mesh key to gateways only if there isn't a gateway specified.

from flagger.

What version of Istio are you using? with Istio 1.0.3 I don't see any errors. My example posted above works with both virtual services bound to the mesh gateway.

from flagger.

Ah that might be the issue. We are using Istio 1.1-rc1

from flagger.

I’ll try reverting to Istio 1.06 and see what happens :)

from flagger.

Let's have a call later today so I can better understand your use case. Can you please join the Weave Slack https://slack.weave.works I'm @stefan on Slack.

from flagger.

Ok so the error Only unique values for domains are permitted is due to a regression bug in Istio 1.1.0 RC istio/istio#11510

from flagger.

With Istio 1.1.5 there is a workaround for this. The virtual service merging works if the virtual services are not attached to the mesh gateway. You can use the same host for multiple canaries by removing the mesh gateway from canary.service.gateways.

from flagger.

I think canaries are currently added to the mesh gateway by default. How does one specifically remove the mesh gateway?

service:  
  # container port
  port: 8080
  # service port name (optional, will default to "http")
  portName: http-proxy
  # Istio gateways (optional)
  gateways:
    - test-gateway.istio-system.svc.cluster.local

I defined the above and when i check the generated virtualservices, mesh is still in there.

from flagger.

@JoelDamata-pcc what Flagger version are you using? Starting with v0.11 the mesh gateway is used only if you don't specify any gateways in the canary.

from flagger.

@stefanprodan Yep, thanks :D

from flagger.

Closing this as virtual service merging is possible when not specifying the mesh gateway. (requires Flagger > v0.11)

from flagger.