Skip to content
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.

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

Kind is null in for GenericKubernetesResource informer `ResourceEventHandler #5729

Closed
csviri opened this issue Jan 29, 2024 · 2 comments · Fixed by #5731
Closed

Kind is null in for GenericKubernetesResource informer `ResourceEventHandler #5729

csviri opened this issue Jan 29, 2024 · 2 comments · Fixed by #5731
Assignees
Labels
Milestone

Comments

@csviri
Copy link
Contributor

csviri commented Jan 29, 2024

Describe the bug

When I create an informer that uses GenericKubernetesResource the kind of the existing resources is null, sample:

var informer = client.genericKubernetesResources("v1","ConfigMap").inAnyNamespace().runnableInformer(0);
        informer.addEventHandler(new ResourceEventHandler<GenericKubernetesResource>() {
            @Override
            public void onAdd(GenericKubernetesResource configMap) {
                System.out.println("config map kind "+configMap.getKind());
            }

            @Override
            public void onUpdate(GenericKubernetesResource configMap, GenericKubernetesResource t1) {
            }

            @Override
            public void onDelete(GenericKubernetesResource configMap, boolean b) {
            }
        });
        informer.start();

It is already null in cache.
It is strange that, if I create a new ConfigMap with the client, it gets propagated properly.

Fabric8 Kubernetes Client version

6.10.0

Steps to reproduce

See sample above. Try it with minikube for example.

Expected behavior

Kind field is propagated

Runtime

Kubernetes (vanilla)

Kubernetes API Server version

1.25.3@latest

Environment

Linux

Fabric8 Kubernetes Client Logs

No specific logs

Additional context

No response

@shawkins
Copy link
Contributor

@csviri the issue seems to be that off of a list operation the api server populates the list kind, but not the individual item kinds, so this would affect any generic list operation not just what the informer is using.

When you receive an event, that's just a single resource and does have the kind populated.

We can probably workaround this by setting the kind ourselves.

shawkins added a commit to shawkins/kubernetes-client that referenced this issue Jan 29, 2024
closes fabric8io#5729

Signed-off-by: Steve Hawkins <shawkins@redhat.com>
@shawkins shawkins self-assigned this Jan 29, 2024
@manusa
Copy link
Member

manusa commented Jan 30, 2024

so this would affect any generic list operation not just what the informer is using.

This doesn't affect standard resources because the kind is hard-coded in the model.

We can probably workaround this by setting the kind ourselves.

I assume this is the only way to go.

@manusa manusa added this to the 6.11.0 milestone Jan 30, 2024
@manusa manusa added the bug label Jan 30, 2024
manusa pushed a commit that referenced this issue Jan 30, 2024
closes #5729

Signed-off-by: Steve Hawkins <shawkins@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants