Many-to-many relation with read-only dependent resource #2423
-
|
Hi, I have a use case very similar to the PrimaryToSecondaryDependent example. The difference is, however, that in my case a CRD (called Benchmark) refers to a list of ConfigMaps and a ConfigMap can be referred to from multiple Benchmarks. That means when a ConfigMap, for example, changes, 0 to many Benchmarks have to be reconciled. I modified the PrimaryToSecondaryDependent example accordingly, but get the error:
Is this behavior expected? If yes, what would be a possible workaround for this use case? If not, I can also share more details on what I implemented to identify what I did wrong. Thanks in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment · 7 replies
-
|
Hi @SoerenHenning , When do you get exactly this error? Pls paste the logs that might be enough. Is it happening from a dependent or you calling Note that if you calling it from reconcile there is simply a version of this method that returns multiple configMaps: |
Beta Was this translation helpful? Give feedback.
-
|
Do I understand correctly that Benchmark can reference multiple config maps? If yes, then I guess you have one dependent representing a configMap, is there one particular that you want to reference or this should be actually a BulkDependetResource? |
Beta Was this translation helpful? Give feedback.
-
|
Note that read only bulk dependent resources are not supported in v4.x (will be in v5, already implemented). see also: https://javaoperatorsdk.io/docs/dependent-resources/#read-only-dependent-resources-vs-event-source |
Beta Was this translation helpful? Give feedback.
-
|
I think, the pointer to BulkDependetResource is already a good hint. To answer your questions: Yes, a Benchmark can reference multiple ConfigMaps. Whenever any of these ConfigMaps changes, I need to reconcile all the Benchmarks that do reference this ConfigMap. My class ConfigMapDependent : KubernetesDependentResource<ConfigMap, BenchmarkCRD>(ConfigMap::class.java) {
}Would I simply have to extend from I am currently still on v4.x (we are migrating a self-built operator with an older fabric8 version to JOSDK), but if it solves the problem, I can directly try to go with v5.x |
Beta Was this translation helpful? Give feedback.
-
|
Hi I would just not use dependents for now, as it described. Version 5 is not released and not sure when it will be, might be few months there are some decisions around still hanging. So I would just not use dependents, use the informer from example that triggers the reconciliation, and implement the logic with low level API. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much, it looks like this solved by simply removing the |
Beta Was this translation helpful? Give feedback.
-
|
So, it is useful I think if you use some other workflow features in in combination, like adding a ready condition or reconcilePrecondiotion to it. Otherwise it is not that useful. |
Beta Was this translation helpful? Give feedback.
Hi I would just not use dependents for now, as it described. Version 5 is not released and not sure when it will be, might be few months there are some decisions around still hanging.
So I would just not use dependents, use the informer from example that triggers the reconciliation, and implement the logic with low level API.