mattmoor
commented
4 years ago If an API change might be needed it might be best to at least design it out prior to v1.0 when the API is locked down.
A nit, this is only true if a breaking API change is needed. The core kube APIs (e.g. Pod) have continued to evolve long past v1 to incorporate new (non-trivial) functionality. An example of this is projection of secrets and configmaps into environment variables, which didn't land until 1.3 (IIRC), and this is far from the last change.
Do you have a reason to think that this would require a breaking API change?
route requests to certain versions based on some metadata in the message (e.g. perhaps some http header)
I am keen to add a new abstraction that can do these kinds of things as well:
- Headers
- Paths (e.g.
/v1/foo/bar) - Method (e.g.
GET,POST)
I've always seen this as a higher-level abstraction (atop Service) because often the things you are switching over are fairly different. e.g.
- Different methods of an API (e.g. different paths or methods)
- Authorization handler (e.g. no auth header)
- An early version of a new application (your example)
My feeling is that this should target Addressable things, which includes Service and Route, but opens the possibility for this to target other abstractions implementing Addressable. I also think it itself should be Addressable so it can be composed with consumers of Addressable (e.g. Eventing).
We should be careful about folding everything into a single abstraction as Istio's VirtualService has, as it can become incredibly hard to use properly. This is (part of) why my bias is towards much more focused and clear abstractions that can be composed.
Another notable challenge this introduces is that it will require an expansion of our networking interface. Istio's API can clearly handle it, but I'm unsure of Gloo (or others I have heard are in the works).
duglin
markusthoemmes
knative-housekeeping-robot
knative-prow-robot
vagababov
aliok
evankanderson
mapleeit
mkloveyy
In what area(s)?
/area API /area networking
/kind spec /kind proposal
Describe the feature
One of the things we hear from customers is that routing between revisions based on percentage isn't really of interest to them once in production. In practice they tend to lean more towards a model where only a select group of users are expected to use the latest versions so that everyone else (who need more stability) are not impacted during the testing phase. We call that "Feature Flag Routing". Where the routers (e.g. istio) route requests to certain versions based on some metadata in the message (e.g. perhaps some http header) rather than the random % based stuff. We'd like for Knative to eventually support this as an option. It's not clear if this can be done solely under the covers or whether it might result in an API change. If an API change might be needed it might be best to at least design it out prior to v1.0 when the API is locked down.
Some of the uses for the "select group":