chore: carriedNamespace/carriesIgnoredNamespace account for Namespace object

[cmwylie19]

Description

CarriedNamespace did not account for Namespace objects which caused some strange behaviors in #1610

After Fix:

[14:20:13.943] DEBUG (44989): Ignoring Watch Callback: Object carries namespace 'pepr-demo-2' but ignored namespaces include '["pepr-demo-2"]'.

Related Issue

Fixes #1618

Relates to #

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Unit, Journey, E2E Tests, docs, adr added or updated as needed
• Contributor Guide Steps followed

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.40%. Comparing base (1955962) to head (1bad7de).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1619      +/-   ##
==========================================
+ Coverage   81.31%   81.40%   +0.09%     
==========================================
  Files          43       43              
  Lines        1969     1979      +10     
  Branches      435      438       +3     
==========================================
+ Hits         1601     1611      +10     
  Misses        340      340              
  Partials       28       28              

Files with missing lines	Coverage Δ
src/lib/filter/adjudicators/adjudicators.ts	98.57% <100.00%> (+0.10%)	⬆️
src/lib/filter/filter.ts	100.00% <100.00%> (ø)

[btlghrants]

Wait, but... Namespace objects don't "carry" namespaces -- they have no metadata.namespace prop, nor should they -- because they "are" namespaces. Namespaces shouldn't carry namespace props, right? So why would we want this method to present like they do?

Also, this edit makes the carriedNamespace() give back what carriedName() already gives back but only for Namespaces which is confusing, IMO. Why was this update needed, exactly?

[cmwylie19]

Wait, but... Namespace objects don't "carry" namespaces -- they have no metadata.namespace prop, nor should they -- because they "are" namespaces. Namespaces shouldn't carry namespace props, right? So why would we want this method to present like they do?

Also, this edit makes the carriedNamespace() give back what carriedName() already gives back but only for Namespaces which is confusing, IMO. Why was this update needed, exactly?

The reason this is need is due to the fact that if you are using alwaysIgnore.namespaces, then you should not execute any callback on anything in the namespace, including the namespace object. For instance, In the below binding I am ignoring the pepr-demo-2 namespace, however, the callback gets executed. Due to the currently implementation we are not ignoring the namespace that we should.

When(a.Namespace)
  .IsCreated()
  .WithName("pepr-demo-2")
  .Watch(async ns => {
    Log.info("Namespace pepr-demo-2 was created.");

RE- carriedName() - Yes- good callout - maybe we need to make carriedName check if the object is a namespace too and return the metadata.name

[btlghrants]

Seems like the uncarryableNamespace() func would be a better place to put the new check -- this method lives one-level above the carriesNamespace and carriedNamespace methods & is the actual method responsible for using available information to give a final determination on whether a forbidden namespace is in use or not.

If we want to update our definition of what it means to "use a forbidden namespace" from only "has a forbidden metadata.namespace defined" and have it also include "or IS a Namespace with a forbidden name" then I think that would be the place.

[btlghrants]

Yep, seems like that should do it.