NE-1946: ingress: Add CRD Lifecycle Management for Gateway API #1756
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@shaneutt: This pull request references NE-1946 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
/cc @knobunc @JoelSpeed @dgn |
|
@shaneutt: This pull request references NE-1946 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
5 times, most recently
from
7af99b6 to
a4db666
Compare
| #### Using a third-party Gateway API implementation | ||
|
|
||
| As a cluster-admin, I want to install a third-party Gateway API implementation | ||
| on my OpenShift 4.19 cluster, and use the third-party implementation without | ||
| any interference from the first-party implementation. Relatedly I want to be | ||
| able to utilize both the first-party and any third-party solution alongside | ||
| each other simultaneously and independently without any interference between the | ||
| two. |
There was a problem hiding this comment.
This seems to conflict with "Validate and allow a range of CRD versions" alternative which concludes that CRDs will be pinned to concrete schema versions. Or you mean that the third party implementations should be able to work with the versions pinned by OCP?
There was a problem hiding this comment.
This is less about the CRDs specifically, and more just the user story about wanting to be able to have multiple implementations co-existing on the cluster. To your question though, yes the idea is they must be able to work with the versions pinned by OCP in order to do this as an implementation detail.
| the mismatching schema and report a `Degraded` status condition with status | ||
| `True` and a message explaining the problem. |
There was a problem hiding this comment.
Did you mean Upgradeable=false or I'm missing something?
There was a problem hiding this comment.
It is my understanding that we will set the condition named Degraded and set it (itself) to True.
There was a problem hiding this comment.
I see now. You were talking about the post-upgrade when CIO already took over the CRD.
There was a problem hiding this comment.
Yes. Let me know though if you think any further clarification is needed!
There was a problem hiding this comment.
Well, yeah, after reading the EP, I think I didn't understand the fact that pre-upgrade check and admin gate go to 4.18 while starting from 4.19 the CIO takes over the CRD management.
There was a problem hiding this comment.
Sounds good, I added further clarification in the notes for the workflow in e66cab0, LMKWYT?
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
3 times, most recently
from
50fcb98 to
7fa4c25
Compare
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
2 times, most recently
from
3e79760 to
e66cab0
Compare
* enhancements/ingress/gateway-api-crd-life-cycle-management.md: New file. * enhancements/ingress/gateway-api-with-cluster-ingress-operator.md: Add cross-reference to the new file.
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
Signed-off-by: Shane Utt <[email protected]>
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
from
e66cab0 to
8db12e8
Compare
|
@shaneutt: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
This proposes the mechanisms by which we will deliver Gateway API as a "core-like" API on the platform going forward.
This covers all the work being done in the NE-1898 epic and is a hard requirement for delivering Gateway API support in 4.19.