Update nw-ingress-gateway-api-overview.adoc

[kchawlani19]

Version(s):
4.19+

Issue:
https://redhat.atlassian.net/browse/OSDOCS-18760

Link to docs preview:

QE review:

• QE has approved this change.

Additional information:
pr to remove the Gateway API implementations already raised here : #108811

[kchawlani19]

/label merge-review-needed

[ocpdocs-previewbot]

🤖 Fri Mar 20 18:42:03 - Prow CI generated the docs preview:

https://108814--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/ingress_load_balancing/configuring_ingress_cluster_traffic/ingress-gateway-api.html

[openshift-ci]

@kchawlani19: all tests passed!

Full PR test history. Your PR dashboard.

Details

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.

[stevsmit]

@kchawlani19 Would you please provide justification for this change? I'm not familiar with the content, and I think the original content owner has moved to a different product. These short descriptions were recently re-written.

We have new requirements for the first ~300 words of an assembly or a module. The requirements can be found here, https://docs.google.com/presentation/d/1cl5PFL0SRV7M6GHBJOZ1jNMAtbVI_85iHKe5XWMV0ek/edit?slide=id.g3798eed728e_0_6&pli=1#slide=id.g3798eed728e_0_6 . It's a little tricky to write these descriptions, but in general we want them to have the WHY (the purpose for doing something) and then the WHAT (the action or thing to do it). The revision that you've provided could use a little cleaning up to make sure that we address that point. For example:

Gateway API provides a standardized and modern way to manage ingress traffic in {product-title}. You can use it to align your networking configuration with widely adopted community and upstream practices.

or

To use a standardized and modern ingress approach in {product-title}, you can use Gateway API. Gateway API aligns your networking configuration with widely adopted community and upstream practices.

I recognize that this content may need rewritten; but we're really trying to make sure we hit the why/what in our re-writes.

[kchawlani19]

hello @stevsmit the whole section, taken out of context is misleading.

At this point in time, different versions of OCP have different versions of the stable Gateway API CRDs.
OCP 4.19 & 4.20 - v1.2.1
OCP 4.21 - v1.3,0

If they want to implement any 3rd party implementations, they have to match the stable versions listed here.  Starting in OCP 4.22 they can also use experimental CRDs.
We don't have any docs or support for 3rd party implementations, and following our docs to use 3rd party implementations will not work.

It might make sense to deemphasize the capability to use third-party implementations while the community/ecosystem sorts out these issues with compatibility and ownership.  However, enabling multiple implementations to co-exist is an important feature of Gateway API, and I hope we don't give up on it entirely.

It would make sense to add a note like, "A third-party implementation must be compatible with the Gateway API CRDs that the platform installs."  We should also continue to push back on third-party implementations that insist on controlling the CRDs or having a specific version of them installed.  Meanwhile, we are going to allow installing APIs in the experimental API group (this change to allow this is done for OpenShift 4.22, and we expect to backport the change), and we continue to work to get these non-experimental, alpha APIs promoted to standard.  That should solve a large part of the problem.

[openshift-ci]

PR needs rebase.

Details

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.

[jeana-redhat]

The branch/enterprise-5.0 label has been added to this PR.

This is because your PR targets the main branch and is labeled for branch/enterprise-4.22. And any PR going into main must also target the latest version branch (branch/enterprise-5.0).

If the update in your PR does NOT apply to version 5.0 onward, please re-target this PR to go directly into the appropriate enterprise- version branch or branches instead of main.