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. |
|
/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
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
3 times, most recently
from
e66cab0 to
8db12e8
Compare
|
Replaces #1740 |
|
/assign |
|
/assign @alebedev87 @alebedev87 thank you for agreeing to lead the review and be the final approver. |
| #### Single-node Deployments or MicroShift | ||
|
|
||
| The CRDs themselves use minimal resources. Creating a GatewayClass CR can cause | ||
| the Ingress Operator to install OpenShift Service Mesh, which in turn installs |
There was a problem hiding this comment.
You could create a VAP set to WARN that would notify a user that their action implicitly enables service mesh, and give them some feedback there, might be a useful addition
There was a problem hiding this comment.
Interestingly we don't enable service mesh. It's kinda weird, but we're literally just using Istio for it's ingress Gateway capabilities (i.e. we don't deploy istio-cni, or allow any use of service mesh features, etc). We're wanting more distinctive support for this use case in the future, which the OSSM team has been helping us with. For the deployment of OSSM we'll be doing, the Gateway API resources are the only API surface we will be supporting (in fact we want to soft block someone trying going around this). All that said, we recently split the feature gates for the gateway API CRDs and the OSSM implementation, so OSSM is no longer a part of this and the EP was a bit out of date. This is now updated to remove references to OSSM, LMKWYT
There was a problem hiding this comment.
Point still stands about the implicit installation of Istio, you could provide a warning, maybe that's relevant for a different EP now though?
There was a problem hiding this comment.
We intend to make the service mesh components of OSSM inaccessible in this deployment, could you help me to better understand what you envision this warning saying, and what explicit action would trigger it?
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
from
00bbe2d to
492ab0c
Compare
|
/lgtm @JoelSpeed: unhold if you are fine with this EP. |
openshift-ci
bot
added
do-not-merge/hold
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
from
7d8ca43 to
5b825a9
Compare
|
/lgtm |
| - Install incompatible CRDs; verify that the operator reports `Degraded` | ||
| - Install experimental CRDs; verify that the operator reports `Degraded` |
There was a problem hiding this comment.
Is this correct, or is the operator removing these now?
There was a problem hiding this comment.
This is correct, specifically this is for the tests: if the experimental APIs somehow become present we go degraded. We want to make experimental available in a later release, but for initial release we're being very strict about it not being present because it can cause some issues. We are considering a very deliberate way to enable Experimental later, where the cluster gets set to TechPreviewNoUpgrade and then the user can do what they like with Experimental, but that's expected to be a future enhancement proposal and for now 🔒.
* 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 <shaneutt@linux.com>
Signed-off-by: Shane Utt <shaneutt@linux.com>
Signed-off-by: Shane Utt <shaneutt@linux.com>
Signed-off-by: Shane Utt <shaneutt@linux.com>
shaneutt
force-pushed
the
ingress-add-gateway-api-crd-lifecycle-management-enhancement
branch
from
83c5c3e to
18baca0
Compare
|
/lgtm |
openshift-ci
bot
removed
the
do-not-merge/hold
|
@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.