CRDInfo doesn't properly support multiple CR versions
#3371
Comments
metacosm
added a commit
that referenced
this issue
Aug 2, 2021
Since several classes can take part in the CRD generation, one per CR version, we need to record all associated class names so that dependents for each of these classes can then be recorded during the generation traversal process. We also need to aggregate all the dependents for all the classes associated with each CR version when we want to retrieve the transitive closure of dependents affecting the generation of a given CRD. Added tests. A downside of this is the fact that we needed to revert the publication of additional information on CRDInfo because this was actually incorrect since the mapping of CRDInfo to one CR class / spec / status is actually invalid. To properly provide that information, we would need to create a more elaborate CRDGenerationInfo structure which would go deeper: this is currently a 2-level Map, indexed first by CRD name, then CRD spec version. We would need a third level to also record the CR version so that we have a unique mapping for between a [CRD name, CRD spec version, CR version] key and related CR class information. As this would be complex to implement, we're deferring this until a need actually arises. Fixes #3371
11 tasks
manusa
pushed a commit
that referenced
this issue
Aug 4, 2021
Since several classes can take part in the CRD generation, one per CR version, we need to record all associated class names so that dependents for each of these classes can then be recorded during the generation traversal process. We also need to aggregate all the dependents for all the classes associated with each CR version when we want to retrieve the transitive closure of dependents affecting the generation of a given CRD. Added tests. A downside of this is the fact that we needed to revert the publication of additional information on CRDInfo because this was actually incorrect since the mapping of CRDInfo to one CR class / spec / status is actually invalid. To properly provide that information, we would need to create a more elaborate CRDGenerationInfo structure which would go deeper: this is currently a 2-level Map, indexed first by CRD name, then CRD spec version. We would need a third level to also record the CR version so that we have a unique mapping for between a [CRD name, CRD spec version, CR version] key and related CR class information. As this would be complex to implement, we're deferring this until a need actually arises. Fixes #3371
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you have multiple versions of a given CR, represented by different classes, one CRD is generated per CRD spec version but this CRD contains multiple versions. In this situation, the set of returned dependent classes is incorrect as the
ClassDependenciesVisitoronly records one CR class name per CRD name.The text was updated successfully, but these errors were encountered: