Namespace resources are tracked by graph

[bjee19]

Refactor code such that Namespace resources are tracked by the graph, thus letting us remove dependency on using the Capturer to do so.

Problem: The Capturer is currently tracking relevant Namespaces and we would like to instead use the Graph.

Solution: Refactor codebase so Graph tracks referenced namespaces and remove dependency on the Capturer.

Testing: Added additional unit tests to graph, change processor, and new tests to namespaces. Ensure tests pass.

Closes #1263

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

[netlify]

✅ Deploy Preview for nginx-gateway-fabric ready!

Name	Link
🔨 Latest commit	3372c8b4c8d57d8dcc3ba616a931f8105045f8c4
🔍 Latest deploy log	https://app.netlify.com/sites/nginx-gateway-fabric/deploys/657b59f4e962cf0008a1fd2e
😎 Deploy Preview	https://deploy-preview-1320--nginx-gateway-fabric.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[bjee19]

Have a couple of questions:

1. Do you think having a separate Namespace resource and subsequent namespaceHolder resource stored in namespace.go is necessary? I was trying to follow the Secret resource stored in secret.go but realized that since I hadn't planned for any validation of namespace resources, I could make ReferencedNamespaces in graph.go a map[types.NamespacedName]*v1.Namespace and just have a helper function in graph.go which populates ReferencedNamespaces with the Kubernetes resource namespace instead of our own.
2. A follow up / related question to the above question, is validation on namespaces necessary? I wasn't sure if that was covered in a different place in the code such that the ClusterState's Namespaces were validated. If so I would keep the separate Namespace resource I created.
3. Where should I put test cases that cover some of the logic that I removed from capturer_test.go? I was thinking they would go in the change_processor.test but wasn't sure.
4. With the recent changes in PR Fix attaching of HTTPRoutes to Gateway Listeners #1275 and the addition of the Attachable field, does that change how I currently check for referenced namespaces? Also should I be checking for the Valid field and not consider it a referencedNamespace if the Listener isn't Valid?

[sjberman]

@bjee19

1. I feel like we don't need to have our own namespace resource, it's probably overkill.
2. Validation on namespaces isn't necessary. These aren't resources that we are generating config for, we're purely looking at labels.
3. change_processor_test.go probably makes sense, seems like that's where we do a lot of the resource event testing.
4. Since we don't generate any config for namespaces specifically, we can keep tracking them even if the Listener isn't Valid. Ultimately, the state of the Listener is what determines the config we generate, the namespace is essentially metadata.

[bjee19]

Have a couple of test cases that were removed from capturer_test that deal with changing the label selector on a Gateway Listener to match/unmatch a Namespace's labels and seeing if that is reflected accordingly. In the Capturer it would test to see if a relationship existed, but with the new changes, I'm unsure where to put these test cases or if they are needed at all.

change_processor_test doesn't seem to fit as upserting a gateway to update its listener's selector would trigger the change itself.

[sjberman]

Is this testing things in namespace.go? If so, you can create namespace_test.go.

[pleshakov]

great refactor!
please see my comments, suggestions and requests

[kate-osborn]

🚀 🚀 🚀