Correlation between two canary active deployments

[jeusdi]

Imagine the next situation:

• two services:
  • users service
  • audit service

user service talks with audit service in order to journal auditories.

So, both services are running a canary deployment strategy at the same time, one for users service and one another for audit service.

When both canary deployment strategies are active means that two versions of each service are running: a canary and a primary.

So, when users service receives a request could be handled by canary or primary.

ISSUE: Once a request is handled by users service canary, derived requests to audit service should be handled by audit service canary.

So, how could I keep this correlation:

• users canary -> audit canary
• users primary -> audit primary

I hope I've explained so well.

[grampelberg]

The most sustainable way to do this would be with an ingress controller which adds a header based on where it should be going. Propagate the headers and clients down the chain can make decisions about where to send it. Take a look at the A/B test example - https://github.com/servicemeshinterface/smi-spec/blob/master/traffic-split.md.

Adding a source selector to TrafficSplit seems like an interesting idea and would allow for matching based on where the traffic is originating.

[jeusdi]

I think this approach doesn't fit at all.

I mean, audit service is an internal service, it's never reached directly by user requests.

Trafic flux->

               +---> canary user service +---------> canary audit service
               |
Incomming requests
               |
               +---> primary user service +--------> primary audit service

As far as I've been able to figure out I get what you mean. Adding a header to incoming requests and then traffic will be directed according to match spec.

But,

• which header and value could you add on incoming requests?
• How this header is conserved on derived internal requests between services?

[grampelberg]

which header and value could you add on incoming requests?

The matcher is generic, so you really could do anything you wanted here.

How this header is conserved on derived internal requests between services?

You'd have to propagate the headers, it isn't a fantastic solution unfortunately.

Another option would be to add a pod selector to the apex so that you could select both a service and where those requests are originating. The more I think about it, the more I don't like this as precedence is gonna get ugly on the implementation side.

Any other ideas for how we could get it done?