You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
context.getSecondaryResource not containing some generated resources #2310
I have a simple Managed dependent reconciler with the following configuration
@ControllerConfiguration(
name = "workload-reconciler",
dependents = {
@Dependent(name = "namespace", type = NamespaceDependentResource.class),
@Dependent(name = "role", type = RoleDependentResource.class, dependsOn = {"namespace"}),
@Dependent(name = "role-binding", type = RoleBindingDependentResource.class, dependsOn = {"namespace", "role"})
})
i.e. the dependency chain is – role depends on namespace & role-binding depends on role & namespace. All dependends extend the CRUDKubernetesDependentResource
What did you expect to see?
Inside the RoleBindingDependentResource, I have implemented the desired method that calls context.getSecondaryResource to get the role & namespace.
What did you see instead? Under which circumstances?
Weirdly, context.getSecondaryResource is only able to return the Namespace but not the role
System.out.println(context.getSecondaryResource(Namespace.class).orElse(null)); // Namespace object
System.out.println(context.getSecondaryResource(Role.class).orElse(null)); // prints null
Environment
Kubernetes cluster type:
kind ( local )
$ Mention java-operator-sdk version from pom.xml file
4.8.1
$ java -version
openjdk version "21.0.2" 2024-01-16 LTS
OpenJDK Runtime Environment Corretto-21.0.2.13.1 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Corretto-21.0.2.13.1 (build 21.0.2+13-LTS, mixed mode, sharing)
$ kubectl version
Client Version: v1.29.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.2
Possible Solution
Additional context
I probably don't consider this as a bug and could be a genuine misunderstanding of the dependsOn and context.getSecondaryResource
Hi, is your project open source? Would be great in that case if you could provide a link, if not than provide a reproducer please. Would be much easier to figure it out. Thx!!
while i would like to know why this happens, for my purpose, i could get away by not using secondaryResource. however i keep getting the following error on controller restart or CR updates
Caused by: io.fabric8.kubernetes.client.KubernetesClientException: Failure executing: PATCH at: https://10.96.0.1:443/apis/rbac.authorization.k8s.io/v1/namespaces/helloworld/roles/helloworld:admin?fieldManager=workload-reconciler&force=true. Message: Operation cannot be fulfilled on roles.rbac.authorization.k8s.io "helloworld:admin": the object has been modified; please apply your changes to the latest version and try again. Received status: Status(apiVersion=v1, code=409, details=StatusDetails(causes=[], group=rbac.authorization.k8s.io, kind=roles, name=helloworld:admin, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Operation cannot be fulfilled on roles.rbac.authorization.k8s.io "helloworld:admin": the object has been modified; please apply your changes to the latest version and try again, metadata=ListMeta(_continue=null, remainingItemCount=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=Conflict, status=Failure, additionalProperties={}).
I tried disabling useSSA, but then i get error on POST
Just to maybe give you a heads up, my use case involves creating a new namespace whenever my CR ( cluster scoped ) is created.
My operator starts with watching all namespaces, but since I create new namespaces, will the josdk track events from them? That could explain why the operator never finds out about the resources created inside this namespace @csviri
@fhalde The reason is not working because the SecondaryToPrimaryMapper by default is configured to handle namespace scoped primary resources in dependent resources. What you have to do is this (for all dependent resources - especially for namespace scoped dependents):
Activity
csviri commentedon Mar 23, 2024
Hi, is your project open source? Would be great in that case if you could provide a link, if not than provide a reproducer please. Would be much easier to figure it out. Thx!!
fhalde commentedon Mar 23, 2024
yes https://github.com/fhalde/operator-pg
fhalde commentedon Mar 23, 2024
while i would like to know why this happens, for my purpose, i could get away by not using
secondaryResource. however i keep getting the following error on controller restart or CR updatesI tried disabling
useSSA, but then i get error onPOSTfhalde commentedon Mar 24, 2024
Just to maybe give you a heads up, my use case involves creating a new namespace whenever my CR ( cluster scoped ) is created.
My operator starts with watching all namespaces, but since I create new namespaces, will the josdk track events from them? That could explain why the operator never finds out about the resources created inside this namespace @csviri
fhalde commentedon Mar 25, 2024
when i try to update a custom resource
upon creating the workload
csviri commentedon Mar 25, 2024
@fhalde The reason is not working because the
SecondaryToPrimaryMapperby default is configured to handle namespace scoped primary resources in dependent resources. What you have to do is this (for all dependent resources - especially for namespace scoped dependents):In this part:
A cluster scope aware
SecondaryToPrimaryMapperwill be created. (Note thetrueflag)Will document this. And for v5 we will take a look how to handle this automatically.
The original mapper is created here:
java-operator-sdk/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/kubernetes/KubernetesDependentResource.java
Line 90 in 0b17878
Note the
falseflag.fhalde commentedon Mar 25, 2024
ah @csviri thanks a lot ! let me test it out :)
fhalde commentedon Mar 25, 2024
@csviri if our CR was namespaced, do we need to make the above changes?
e.g. we can have a "public" namespace where our CR gets created. Then our reconciler creates a separate namespace,role e.t.c
csviri commentedon Mar 25, 2024
In that case you don't have to do this change.
csviri commentedon Mar 25, 2024
related improvement issue: #2311
fhalde commentedon Mar 25, 2024
this worked 🙇 closing it