Skip to content

Conversation

@shaun-nx
Copy link
Contributor

Proposed changes

This change adds a new page to the NGF Install section on how to install the NGF on OpenShift using the RedHat Operator Hub.

This guide also includes Operator specific configurations as well as troubleshooting.

Closes nginx/nginx-gateway-fabric#3911

Checklist

Before sharing this pull request, I completed the following checklist:

Footnotes

  1. Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content.

sarthyparty and others added 11 commits September 3, 2025 10:16
Update compatability doc with Port for ParentRef
Update gateway addresses compatibility document.
…omment (#1126)

Add a small comment on IP families to gateway addresses compatibility document.
Added mention about unsupported fields for RouteRules and Gateways
Closes nginx/nginx-gateway-fabric#3784
feat: Update advanced routing guide for regex path
…cs (#1284)

* Add details on BuildOS and InferencePoolCount to Product Telemetry docs
* Add InferencePoolCount
* Move InferencePool resource into "Count of Resources" section
@shaun-nx shaun-nx requested a review from a team as a code owner October 20, 2025 09:20
@github-actions github-actions bot added documentation Improvements or additions to documentation product/ngf Issues related to NGINX Gateway Fabric labels Oct 20, 2025
@github-actions
Copy link

Deploy Preview will be available once build job completes!

Name Link
😎 Deploy Preview https://frontdoor-test-docs.nginx.com/previews/docs/1332/

@shaun-nx shaun-nx requested a review from a team October 20, 2025 15:03
@shaun-nx shaun-nx changed the base branch from ngf-release-2.2 to main October 21, 2025 16:12
@shaun-nx
Copy link
Contributor Author

Changing the base branch to main as we need to wait until we have fully published the Operator to Openshift before making this doc available

Comment on lines 41 to 42
Please note that while we make every effort to reflect the support status of experimental fields in our code and documentation, there may be instances where this is not explicitly
indicated. Support for such fields is provided on a best-effort basis.{{< /call-out >}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Please note that while we make every effort to reflect the support status of experimental fields in our code and documentation, there may be instances where this is not explicitly
indicated. Support for such fields is provided on a best-effort basis.{{< /call-out >}}
Please note that while we make every effort to reflect the support status of experimental fields in our code and documentation, there may be instances where this is not explicitly indicated. Support for such fields is provided on a best-effort basis.{{< /call-out >}}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets avoid making this update here as it's not part of the new document

Copy link
Contributor

@salonichf5 salonichf5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mentioned a couple of nits but overall looks good. I think this branch needs a rebase with main

great job 🥳

@tataruty
Copy link
Contributor

Changing the base branch to main as we need to wait until we have fully published the Operator to Openshift before making this doc available

Did you change base branch too? or only the aim of merge? I see many commits difference

Copy link
Member

@ADubhlaoich ADubhlaoich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Broadly speaking, the new page needs to be restructured.

It doesn't adhere to our contemporary page standards:

  • It's missing the documentation metadata
  • The requirements section is not named correctly
  • It uses the NGF three letter acronym: we do not use TLAs in public-facing documentation
  • It uses bash as a formatting language, when shell has been the norm for months
  • It doesn't use Hugo for list enumeration

Many of the structural issues could have been avoided by using Hugo archetypes, for which we maintain documentation which is part of the Contributing guidelines as the first item in the PR checklist.

Effectively no commits on this branch adhere to the Git conventions as the second item in the PR checklist, though this does not need to be fixed in retrospect as long as the eventual merge message is correct.

1. Navigate to Operators → OperatorHub.
2. Search for "NGINX Gateway Fabric".
3. Select the NGF Operator (provider: NGINX, Inc) and click Install.
4. Choose an update channel (for example, stable 2.x), installation mode (All namespaces or a specific namespace), and approve automatic updates as desired.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't currently support specific namespace or automatic updates

## Optional: NGINX Plus licensing

If you plan to use NGINX Plus, you will need to:
- Set `spec.nginx.nginxOneConsole.plus: true`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Set `spec.nginx.nginxOneConsole.plus: true`
- Set `spec.nginx.plus: true`


## Create the NginxGatewayFabric CR

Minimal example for OpenShift:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the pre-populated or empty fields can be omitted - keep the image ones etc as makes sense, but all these fields just correspond to the helm command and don't need to be explicitly set. We display them in the UI for user convenience, but they are not required for a minimal example.


Wait for the Operator to reconcile. It will provision the NGF controller and data plane deployments, services, and related resources.

## OpenShift-specific exposure options
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this section required?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like it would be helpful just for anyone starting out on Openshift. Happy to remove it if we feel it adds to much to the document

- `terminationGracePeriodSeconds`: Default 30 seconds.
- `topologySpreadConstraints`, `tolerations`, `nodeSelector`, `affinity`: Pod scheduling controls.

## Pod scheduling and security (OpenShift)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a useful section, thanks! SCCs are a headache 😅

```
- For TLS passthrough, use `--passthrough` and target the appropriate service port.

## Operator-specific configuration options (NginxGatewayFabric spec)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced we should maintain a list here - I think the Helm values should be the source of truth, with generic guidelines on how these values are translated into the NginxGatewayFabric CRD fields

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good 👍


- NGF Helm chart defaults (values): See `helm-charts/nginx-gateway-fabric/values.yaml` in the NGF repository.

## Notes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on my previous comments, these notes can probably be removed also

@shaun-nx
Copy link
Contributor Author

shaun-nx commented Oct 24, 2025

I made changes to the PR to reflect these points of feedback:

  1. It uses the NGF three letter acronym: we do not use TLAs in public-facing documentation
  2. It uses bash as a formatting language, when shell has been the norm for months

I'm confused by these points

Effectively no commits on this branch adhere to the Git conventions as the second item in the PR checklist

The second items says My branch adheres to the Git conventions. This relates to just the branch, and not the individual commit messages from what I understand. This was never called out as a problem before.

It's missing the documentation metadata

There is a Title and Description in this document. Is there other metadata missing? The most reset set of commits adds nd-content-type, nd-product and nd-docs. Were you referring to these?

The requirements section is not named correctly

This document doesn't have a requirements section at all, so it's not clear what you mean by this. Should we have a requirements section?

It doesn't use Hugo for list enumeration

Again, not sure what this means. The Hugo Content page says **The ordered notation automatically enumerates lists when built by Hugo** but it's still not clear what that relates to.
I did run make docs locally but I'm not sure if that really affected anything regarding this point.

As a point of feedback for the feedback,
If the use shell instead of bash is really important then it feels like that should be enforced by a pre-commit check, especially if it's something that we are willing to block a PR on.

Copy link
Contributor

@mjang mjang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty good. I'm guessing that go.mod and go.sum are not part of your proposed change.


## Overview

This guide details how to install F5 NGINX Gateway Fabric on Red Hat OpenShift through OperatorHub and configure it with the `NginxGatewayFabric` custom resource.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General style: shorter sentences are easier to read

Suggested change
This guide details how to install F5 NGINX Gateway Fabric on Red Hat OpenShift through OperatorHub and configure it with the `NginxGatewayFabric` custom resource.
This guide details how to install F5 NGINX Gateway Fabric on Red Hat OpenShift through OperatorHub. You can then configure it with the `NginxGatewayFabric` custom resource.

- F5 NGINX One dataplane API key if you plan to integrate with [F5 NGINX One Console](https://docs.nginx.com/nginx-one/).
- F5 NGINX Plus entitlements if you plan to run NGINX Gateway Fabric with F5 NGINX Plus.

NGINX Gateway Fabric provides first-class OpenShift support with Universal Base Image (UBI)-based images. Use the `-ubi` tags shown in the custom resource definition (CRD) examples. Defaults are compatible with OpenShift Security Context Constraints (SCCs) for non-root operation. If your cluster enforces custom SCCs or policies, bind the appropriate SCC to NGINX Gateway Fabric service accounts.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I discourage marketing terms in docs. It hurts credibility with our target audience

Suggested change
NGINX Gateway Fabric provides first-class OpenShift support with Universal Base Image (UBI)-based images. Use the `-ubi` tags shown in the custom resource definition (CRD) examples. Defaults are compatible with OpenShift Security Context Constraints (SCCs) for non-root operation. If your cluster enforces custom SCCs or policies, bind the appropriate SCC to NGINX Gateway Fabric service accounts.
NGINX Gateway Fabric provides OpenShift support with Universal Base Image (UBI)-based images. Use the `-ubi` tags shown in the custom resource definition (CRD) examples. Defaults are compatible with OpenShift Security Context Constraints (SCCs) for non-root operation. If your cluster enforces custom SCCs or policies, bind the appropriate SCC to NGINX Gateway Fabric service accounts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ciarams87 @mkingst what are your thoughts on this one?

-n nginx-gateway-fabric
```

### Integrate with NGINX One (optional)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume you mean the UI, not the product (which includes NIM, N Plus, etc.)

Suggested change
### Integrate with NGINX One (optional)
### Integrate with NGINX One Console (optional)


### Integrate with NGINX One (optional)

If you want NGINX Gateway Fabric to connect to NGINX One, create a secret for the dataplane key (replace VALUE with your key).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If you want NGINX Gateway Fabric to connect to NGINX One, create a secret for the dataplane key (replace VALUE with your key).
If you want to use NGINX One Console to monitor NGINX Gateway Fabric, create a secret for the dataplane key (replace VALUE with your key).


### Create the NginxGatewayFabric custom resource

Create a minimal `NginxGatewayFabric` custom resource for OpenShift.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Create a minimal `NginxGatewayFabric` custom resource for OpenShift.
Create a minimal `NginxGatewayFabric` custom resource for OpenShift. Include this code in a file named `nginx-gateway-fabric.yaml`.


### Validate the installation

Verify that deployments and services are running, and confirm the GatewayClass:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a thing called GatewayClass? If not, I'd rephrase this to the actual directive:

Suggested change
Verify that deployments and services are running, and confirm the GatewayClass:
Verify that deployments and services are running, and confirm the `gatewayclass`:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, GatewayClass is an Object in the Gateway API.
https://gateway-api.sigs.k8s.io/api-types/gatewayclass/


### Perform a functional check (optional)

9. Create a simple Gateway and HTTPRoute to validate routing:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies steps 1-8.
Also, our style guide discourages words like "simple"

Suggested change
9. Create a simple Gateway and HTTPRoute to validate routing:
Create a Gateway and HTTPRoute to validate routing:

shaun-nx and others added 3 commits October 24, 2025 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation product/ngf Issues related to NGINX Gateway Fabric

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create OpenShift installation documentation

8 participants