manusa on master
chore(deps-dev): bump approvalt… (compare)
manusa on maven
Hi, this method of
SharedInformerFactory is deprecated in version 5.5.0
public synchronized <T extends HasMetadata> SharedIndexInformer<T> sharedIndexInformerFor(Class<T> apiTypeClass, OperationContext operationContext, long resyncPeriodInMillis)
This could be an alternative implementation to
OperationContext to watch labelled workloads?
SharedIndexInformer<Pod> podInformer = kubernetesClient.pods() .withLabels(DEFAULT_SELECTORS) .inform(podHandler, RESYNC_PERIOD);
My team is facing a new issue after uptaking 5.4.0 that we have not seen with previous versions. The problem comes when we have a SharedInformer for a class where the CRD has been loaded in the cluster but no actual CRD resources have been created.
We have some code to get the list of resources in a workspace from the informer cache:
final var indexer = resourceInformer.getIndexer();
final var resourcesListOptional = Optional.ofNullable(indexer.byIndex(Cache.NAMESPACE_INDEX, namespace));
This existing code is now with 5.4.0 producing an exception:
Caused by: java.lang.NullPointerException
Note that the byIndex method does a check for existence of indexName in "indexers" but does not do an equivalent check in "indices". There seems to be an assumption that indices would have the same keys as indexers and in the constructor they are both initialized with the same key "namespace". However in our scenario I am observing that indexers still contains the "namespace" key but indices is an empty map. Hence we get the null pointer exception on line 291.
I have observed that when the informer is starting the Cache::replace method is being called with an empty list parameter. Then on line 157 it sets indices to a new/empty map. Since there are no items there is no additional initialization performed on indices. The call stack looks like:
It appears that we don't have any mechanism to check for this condition since the Cache indices property is private.
Would anyone please suggest a check, work-around, or fix?
kubectl apply -f src/main/resources/cr.yaml
@rohanKanojia Hi... here with the same project again. https://github.com/jcechace/apicurio-model-generator
It's becoming gradually more important for us to generate this model for current revisions of apicurio. THe issue is that my understanding of that project (and gomodules in general) is on the low side. Would you be willing to schedule a call with me and go over the project? For example I'd very much like to understand the versioning as changing the version of github.com/fabric8io/kubernetes-client/generator to comment matching the v5.6.0 release tag breakes the project and so on.