Ability to specify target version, alternative to traffic-splitting

[iiian]

Ask your question here:

I've got (perhaps) a less conventional workflow, where the ability to, for instance, call http://hello@{version}.default.127.0.0.1.sslip.io (note the additional @{version}) adds value and abstracts complexity I'd otherwise have to introduce and manage myself.

• Has anybody considered doing something like this?
• Is there already a POC?
• Does this seem like an anti-pattern?
• If it's a good idea but just not implemented, where is the proper place to discuss what it would take to implement?

[iiian]

For added context, I've got a multi-tenant environment, and it's sort of an assembly line ETL system.

With the above feature, I could lock each tenant to a version or range of semantic versions, thereby adding the quality assurance of not having a unrelated bugs damage stable tenant workflows.

The solution that comes to mind today is to "GA" certain versions of the application, and then to fork each version as its own service. This means that as time goes on, my list of services starts to look like:

service-a-1-0-0
service-a-1-1-0
service-a-2-0-0
service-a-2-0-1
service-b-1-0-0
service-b-1-0-1
service-c-1-0-0
...

Now, I can't tell you the first thing about knative's internal implementation, but to my mind this approach is polluting a global namespace. I assume there's a service registry of some sort, and I assume it has some sort of upperbound. I'm sure it's exceedingly hard in practice to exceed that upperbound as well.

Maybe a proper service per version isn't the worst thing in the world.

[psschwei]

Not sure it's an exact match for what you're looking for, but would tag header based routing be an option?

[iiian]

Nice. Thanks a lot @psschwei .

Now the only question is does gcloud support it with Cloud Run? Seems like not yet, but still good to know there's a technique available in knative itself

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.