Operator-SDK skeleton

[tataruty]

Proposed changes

Write a clear and concise description that helps reviewers understand the purpose and impact of your changes. Use the
following format:

Problem: We need to create an operator to certify our offering in the OpenShift ecosystem catalogue. We should create a basic Helm-based operator using Operator SDK to get us started, as we do not require advanced functionality provided by the Go based operator at this time.
Acceptance Criteria:
Operator generated in a new operators/ directory within existing repo
Uses relative path ../charts/nginx-gateway-fabric to source chart
Basic operator structure includes watches.yaml, Makefile, config/ (all auto-generated)
make run starts operator locally without errors (can test on kind at this stage)

Solution:

mkdir -p operators
cd operators

# Generate the Helm-based operator
operator-sdk init --plugins helm --domain=nginx.org \
  --group=gateway --version=v1alpha1 --kind=NginxGatewayFabric \
  --helm-chart=../charts/nginx-gateway-fabric

Testing:

1. Install the gateway crds
2. Install the operator CRD make install from the operator repo
3. Run make run
4. Try running kubectl apply -f operators/config/samples/gateway_v1alpha1_nginxgatewayfabric.yaml in a new terminal window
5. See if there are errors in the make run window
6. See if an instance of NGF has been created kubectl get pods

created:

Please focus on (optional): If you any specific areas where you would like reviewers to focus their attention or provide
specific feedback, add them here.

Closes #3907

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the CONTRIBUTING doc
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

If this PR introduces a change that affects users and needs to be mentioned in the release notes,
please add a brief note that summarizes the change.

NONE

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.77%. Comparing base (24dee2b) to head (cc7c143).
⚠️ Report is 1 commits behind head on feat/openshift-support.

Additional details and impacted files

@@                    Coverage Diff                     @@
##           feat/openshift-support    #3944      +/-   ##
==========================================================
- Coverage                   86.85%   86.77%   -0.09%     
==========================================================
  Files                         128      128              
  Lines                       16559    16559              
  Branches                       62       62              
==========================================================
- Hits                        14383    14369      -14     
- Misses                       1997     2008      +11     
- Partials                      179      182       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sjberman]

Are all of these files auto-generated? Just trying to understand what all of these extra components are. I want to make sure we aren't adding a bunch of unnecessary stuff in here, but I also don't know what's needed for the operator.

[sjberman]

We are going to need to add the generation of these files to our CI workflow so we can ensure that they are always up to date with our helm chart, and return an error if they aren't. Our make generate-all target should include a target to generate these as well.

[tataruty]

Are all of these files auto-generated? Just trying to understand what all of these extra components are. I want to make sure we aren't adding a bunch of unnecessary stuff in here, but I also don't know what's needed for the operator.

yes, they are

[sjberman]

yes, they are

Ok, so if most of this is out of our control, I'm curious which pieces you manually added so I can specifically review those.

[tataruty]

yes, they are

Ok, so if most of this is out of our control, I'm curious which pieces you manually added so I can specifically review those.

.pre-commit-config.yaml and .yamllint.yaml for now

[tataruty]

We are going to need to add the generation of these files to our CI workflow so we can ensure that they are always up to date with our helm chart, and return an error if they aren't. Our make generate-all target should include a target to generate these as well.

for now it is autogenerated and i would add it to generate-all, but i don't know @ciarams87 plans about it, if there will be some change in this skeleton later then we cannot re-generate it and replace some important change, so, i need input from @ciarams87 here

[sjberman]

If the operators directory is going to have a mix of autogenerated and manual files/changes, then we'll need to figure out how to reconcile those. Since our helm chart is always changing, we don't want to forget to auto-generate the chart inside the operator directory, which is why we want that CI check and make target in place. Same as how all of our other example deployment files are checked, to ensure all deployment options are in sync.

So regardless, we do need a CI check and make target.

[ciarams87]

We are going to need to add the generation of these files to our CI workflow so we can ensure that they are always up to date with our helm chart, and return an error if they aren't. Our make generate-all target should include a target to generate these as well.

@sjberman @tataruty I have a separate task for automating all of this as it's not straight-forward, and we need to do the bundle generation task first #3912