feature(BlueGreen): Allow preview service to point ONLY at preview ReplicaSet

[marcinjahn]

Summary

Currently, the preview service point either at preview ReplicaSet (if we're in the middle of a rollout), or at the active ReplicaSet (any other time).
I think it'd be useful to have an option to specify that the preview service would never point at the active ReplicaSet. Therefore, if there's no rollout going on, the preview service would not connect you to any pods. It could return something like HTTP 503 instead.

Use Cases

• running tests on preview environments - it'd be a good feedback to know that there is no preview service being deployed at the moment
• it'd be convenient to have confidence that the response I'm seeing for an API request to a preview service is actually coming from the preview service. Currently, I can never be sure.

---

Message from the maintainers:

Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.

[kostis-codefresh]

Hello

This is a breaking change for people who have the following scenario (me as well)

I am doing a blue/green deployment and I want an internal service to connect to the new version as soon as possible. Maybe this service is controlled by my QA team or it is my own intranet.

The use case is that I want them to have a look at the new version as soon as possible to detect errors that would allow me to decide if I actually want to promote the new version or not.

With the current behavior I just point everybody to the preview service and it automatically works at all instances.
With the suggested change I am now forced to change manually the URL of the rollout. When a rollout is in progress I need to point everybody to the preview service and when a rollout is not in progress I need to manually change everybody to the stable service (other wise my intranet users will get 503)

Frankly if you want to know what a rollout is doing you need to query the rollout itself directly and not use the preview service. Assuming that no rollout is happening because preview service throws 503 is a side effect and not the source of truth.

running tests on preview environments - it'd be a good feedback to know that there is no preview service being deployed at the moment

Why point those tests to the preview service and not the stable service if you want to avoid scenarios where a rollout is in progress?

it'd be convenient to have confidence that the response I'm seeing for an API request to a preview service is actually coming from the preview service. Currently, I can never be sure.

You should see in your metrics that the preview pods are getting requests. Your Analysis as well. That is the whole point of adopting Argo Rollout (to use with metrics).

[marcinjahn]

Well, I definitely would not suggest to introduce it as breaking change. If my feature request would get implemented, it should be as a non-default option.