Skip to content

RFE-7406: Include the K8s ingress resource in namespace inspect collection #2004

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

RFE-7406: Include the K8s ingress resource in namespace inspect collection #2004

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
785bc65
Include the K8s ingress.networking resource in namespace inspect coll…
oarribas Apr 9, 2025
1a0e177
Include the K8s ingress.networking resource in namespace inspect
oarribas Nov 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions pkg/cli/admin/inspect/namespace.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@ func namespaceResourcesToCollect() []schema.GroupResource {
{Resource: "secrets"},
{Resource: "servicemonitors"},
{Resource: "userdefinednetworks"},
{Resource: "ingresses.networking"},
Copy link

@coderabbitai coderabbitai bot Nov 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify the resource format and collection.

The format {Resource: "ingresses.networking"} may not correctly specify the Kubernetes Ingress resource from the networking.k8s.io API group. Standard schema.GroupResource usage would be {Group: "networking.k8s.io", Resource: "ingresses"}. While other entries also omit the Group field, it's unclear if the dot-notation in the Resource field will be properly resolved by the code consuming this list.

Run the following script to verify how this resource is consumed and whether ingresses are actually collected:

Additionally, please test the inspect command with a namespace containing Ingress resources to confirm they are collected in the output.

🏁 Script executed:

#!/bin/bash
# Find where namespaceResourcesToCollect is called and how the GroupResources are processed
rg -n -C5 'namespaceResourcesToCollect'

# Search for other usage patterns of schema.GroupResource in the codebase
rg -n -C3 'schema\.GroupResource.*Group:.*Resource:'

# Check if there's any parsing logic for dot-notation in resource names
rg -n -C3 'Resource.*\.'

Length of output: 239324

Fix resource specification for Kubernetes Ingress resource.

The format {Resource: "ingresses.networking"} is incomplete. The Kubernetes Ingress resource belongs to the networking.k8s.io API group (full group), not just networking.

Change line 34 to one of these correct formats:

{Group: "networking.k8s.io", Resource: "ingresses"}

Or if the resource can be discovered by name alone:

{Resource: "ingresses"}

The current dot-notation ingresses.networking may not resolve correctly during resource discovery and collection. Testing the inspect command with a namespace containing Ingress resources is necessary to confirm the fix works.

🤖 Prompt for AI Agents 
In pkg/cli/admin/inspect/namespace.go around line 34 the resource spec uses an
incorrect dot-notation "{Resource: \"ingresses.networking\"}"; replace it with a
proper Kubernetes resource spec such as either "{Group: \"networking.k8s.io\",
Resource: \"ingresses\"}" or simply "{Resource: \"ingresses\"}" so the Ingress
API group is correctly identified during discovery; update the line accordingly
and run the inspect command against a namespace with Ingresses to verify
collection succeeds.

Copy link
Member

@ardaguclu ardaguclu Nov 20, 2025

Choose a reason for hiding this comment

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

It sounds like ^^ comment is valid. Is there any particular reason of using ingresses.networking?.

Copy link

@coderabbitai coderabbitai bot Nov 20, 2025

Choose a reason for hiding this comment

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

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Find where namespaceResourcesToCollect is called and how it's used
echo "=== Usage of namespaceResourcesToCollect ==="
rg -n "namespaceResourcesToCollect" --type go -A10

echo -e "\n=== How GroupResource is processed in inspect code ==="
# Look at the inspect package to understand how these resources are processed
rg -n "GroupResource" pkg/cli/admin/inspect/ --type go -B2 -A5

echo -e "\n=== Check for dot-notation patterns in resource names ==="
# Search for other resources using dot notation
rg -n 'Resource:\s*"[^"]+\.[^"]+"' --type go

echo -e "\n=== Look for kubectl/oc resource name conventions ==="
# Search for comments or documentation about resource naming
rg -n "networking" pkg/cli/admin/inspect/ --type go -B2 -A2

Length of output: 8012

🏁 Script executed:

#!/bin/bash

# Check if there are other files that use dot-notation for resource specifications
echo "=== Search for dot-notation in resource specifications across codebase ==="
rg -n '"[a-z]+\.[a-z]+"' --type go | grep -i "resource" | head -20

echo -e "\n=== Look for examples in test files ==="
rg -n "ingresses\.networking" --type go

echo -e "\n=== Check how 'all' special resource works and other patterns ==="
rg -n 'Resource.*"all"' pkg/cli/admin/inspect/ --type go -B3 -A3

echo -e "\n=== Search for networking.k8s.io references ==="
rg -n "networking\.k8s\.io" --type go | head -15

echo -e "\n=== Look for examples of servicemonitors or other CRDs ==="
rg -n "servicemonitors" pkg/cli/admin/inspect/ --type go -C3

Length of output: 1632

🏁 Script executed:

#!/bin/bash

# Look for test files that might show proper GroupResource usage
echo "=== Search for test files with GroupResource examples ==="
fd -e go test | xargs rg -l "GroupResource" | head -5

echo -e "\n=== Check test examples ==="
rg -n "schema\.GroupResource" --type go -A2 | head -40

echo -e "\n=== Look for how networkpolicies are handled (they're also in networking.k8s.io) ==="
rg -n "networkpolicies" --type go -C2

echo -e "\n=== Check if there are any imports or usages of networking API ==="
rg -n "networking" --type go | grep -i "import\|k8s.io\|api" | head -20

Length of output: 3626

@ardaguclu Great question! After investigating the codebase, I found that {Resource: "ingresses.networking"} is inconsistent with the established pattern in this file.

Key Finding

Look at line 29 in the same function:

{Resource: "networkpolicies"},

NetworkPolicy is also from the networking.k8s.io API group, yet it's specified as just {Resource: "networkpolicies"} without any group specification. This proves that simple resource names work fine for networking.k8s.io resources through kubectl/oc's resource discovery mechanism.

How the Code Works

In pkg/cli/admin/inspect/util.go:90-94, the groupResourceToInfos function constructs the dot-notation only when the Group field is populated:

resourceString := ref.Resource
if len(ref.Group) > 0 {
    resourceString = fmt.Sprintf("%s.%s", resourceString, ref.Group)
}

Recommendation

To match the existing pattern and be consistent with networkpolicies, change line 34 to:

{Resource: "ingresses"},

Alternatively, if explicit group specification is preferred:

{Group: "networking.k8s.io", Resource: "ingresses"},

The current {Resource: "ingresses.networking"} hardcodes what should be constructed by the code, breaking the established pattern where all other entries use simple resource names.

🧬 Code Graph Analysis Results

[File: pkg/cli/admin/inspect/namespace.go, Lines 19-36]

func namespaceResourcesToCollect() []schema.GroupResource {
	return []schema.GroupResource{
		// this is actually a group which collects most useful things
		{Resource: "all"},
		{Resource: "configmaps"},
		{Resource: "egressfirewalls"},
		{Resource: "egressqoses"},
		{Resource: "events"},
		{Resource: "endpoints"},
		{Resource: "endpointslices"},
		{Resource: "networkpolicies"},
		{Resource: "persistentvolumeclaims"},
		{Resource: "poddisruptionbudgets"},
		{Resource: "secrets"},
		{Resource: "servicemonitors"},
		{Resource: "userdefinednetworks"},
		{Resource: "ingresses.networking"},
	}
}

Copy link

@palonsoro palonsoro Nov 20, 2025

Choose a reason for hiding this comment

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

API group must be specified because there is more than one ingress resource in OpenShift clusters and in some old versions, the priorities were different, so API group must be explicitly specified.

Copy link

@coderabbitai coderabbitai bot Nov 20, 2025

Choose a reason for hiding this comment

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

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

Copy link

@palonsoro palonsoro Nov 20, 2025

Choose a reason for hiding this comment

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

@oarribas maybe you can just use the form with group and resource as suggested by the bot.

Copy link
Contributor Author

@oarribas oarribas Nov 20, 2025

Choose a reason for hiding this comment

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

@ardaguclu , as @palonsoro commented, it was added as there are more than one ingress resource with different APIs.
On the other hand, I haven't see the form with group used anywhere else, so not sure if the suggested one is the correct way. If it is, I can change it.

Copy link
Member

@ardaguclu ardaguclu Nov 20, 2025

Choose a reason for hiding this comment

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

Could you please try ingresses.networking.k8s.io whether it works or not?

Copy link

@palonsoro palonsoro Nov 21, 2025

Choose a reason for hiding this comment

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

Checking the GroupResource type, it looks like the right way to go is the first suggested by the bot, as the GropuResource has the Group for API group and the Resource for the resource name.

@oarribas maybe you didn't see it because it was not required for the collected API groups. But if you do it like the bot suggests (with group and resource) and it fails, that would be a bug by itself, because the GroupResource type is something coming from upstream Kubernetes that should be usable in the way expected by upstream alongside oc.

}
}

Expand Down