Configuration & Route lifecycle operations are required #36
Conversation
This allows for portability of these resources for advanced users who do not use Knative Service
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: dprotaso The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
knative-prow-robot
added
the
size/S
|
I don't think we should change this too required. Can you provide more rationale regarding making this change? Portability could arguably be applied to every API setting and call. |
|
I do agree with @dprotaso in the sense that Knative clients like the CLI tools are already using those APIs. |
Configuration & Route were never marked internal so integrators always had the option to drop to these APIs for flexibility. There's already an example of this where projectriff (now archived) was using configuration and route directly. I believe this was done to get around some issues with revision management. A use case I'm aware of is the need for stable routing over configurations instead of revisions |
There was a problem hiding this comment.
I think it's okay for some clients (and maybe even the OSS CLI) to use operations which aren't marked as REQUIRED in the spec.
For a specific example, I think this may break Cloud Run (Fully Managed), because I'm not sure that they have support for free-range Configurations without an associated Service. @whaught to confirm here, since I honestly don't remember.
| The table below details which operations must be made available to a developer | ||
| accessing a Knative Route using a minimal profile. For any non-minimal profile, | ||
| the POST, PUT, or DELETE operations MUST be enabled as a group. This ensures | ||
| that the developer has the ability to control the complete lifecycle of the | ||
| object from create through deletion. |
There was a problem hiding this comment.
Why remove this verbiage?
There was a problem hiding this comment.
POST, PUT, or DELETE operations were marked as REQUIRED in tandem. The only remaining OPTIONAL operation is PATCH so it didn't seem necessary to keep this clause
This would likely break Cloud Run. Internally we do support actions on Configurations and Routes and it's likely they could be made public, but doing so is out of scope for the simple experience we are intending to provide. Ideally this would not be required. |
This would offer integrators, who might need to drop to lower levels, portability |
|
From knative/serving#412, I think the de-composed resource model wasn't compatible with our ability to deliver a great developer experience so we introduced |
I agree that
I'm suggesting these resources are for 'integrators' of Knative who understand the extra complexity in exchange for flexibility |
|
Serving overview has an interesting description thats relevant here |
|
Right. Integrators should be fine to use Route and Configuration directly in their implementation of the spec if they choose. However we also think offerings like Cloud Run which aim to offer a simplified experience should also be allowed to lock down the experience to one single endpoint (Service) without it being required that we allow further complexity from clients. Either should still be considered in compliance with Knative which allows for diversity in the experiences vendors wish to offer. This difference ought not be required of any vendor lest a particular implementation become the de-facto specification. |
|
/LGTM |
To clarify, I understood ☝️ that as |
|
/LGTM |
|
This was veto'd by Google (@spencerdillard) |
This allows for portability of these resources for advanced users
who do not use Knative Service