Router defined multiple times during rolling deployment

[parberge]

Scenario;
One service in consul that has 6 nodes, with appropriate tags to setup routing.
Let's say the tag is:

traefik.http.router.example.rule=PathPrefix(`/example/v1/`)

Now we want to:
Update the existing route example to:

traefik.http.router.example.rule=PathPrefix(`/example/v1/`,`/example/v2/`)

If we apply a rolling deployment, that is in charge of setting up the appropriate tag (for example using hashicorp nomad) we will for some time (depending on how fast the deployment is etc) have two tags on the same service in consul that matches traefik.http.router.example.rule.

This will result in the following error:

Router defined multiple times with different configurations in [xxxx]

This ofc is expected to have given the circumstances.
The problem is that traefik will remove the route all together.
Is this by design?

I would like traefik to be able to handle this situation by choosing one of the routes. Preferably the old until the old is gone.

[tvld]

+1 We are getting "Router defined multiple times with different configurations in" all the time, even just updating the current service docker-compose file.

[parberge]

Since we don't rely on the routes name we solved the problem by making sure that the new routes have an unique name.

Now we have however ran into the exact same problems with middleware. And that's quite a big issue;

We have middleware that are used by many routes. If we want to update the middleware configuration we can't do that without either:

1. Accept downtime when the middleware disappears when duplicate names are present
2. Add a new middleware and update all consumers to use the new middleware name.

Second option will not cause downtime, but it doesn't scale well with large environments that have many services using the middleware.

[parberge]

So we use consul. Traefik has both the consulCatalog and the consul K/V provider.

Our solution will be:

1. Our routes will be defined using consulCatalog. To circumvent duplicates we will make sure that the routes will always be unique by adding a hash in the name and let our pipeline handle creation of these routes.
2. Our middlewares will be defined using consul K/V, which ofc resolve the problem about duplicate middleware names.

If and when this ticket is solved (Weighted Round Robin for all providers · Issue #5673 · traefik/traefik · GitHub) the need for hashing the routes etc might become unnecessary