Component-References w/ "ignore-transitive"-hint

[ccwienk]

Context / Motivation

In gardener project, we have the following case:

There is a large component (github.com/gardener/gardener), with a lot of resources + component-references. For installation purposes, we have an aggregation component, which references one version of said github.com/gardener/gardener component; As our installer will always resolve the transitive closure starting from aforementioned root/landscape-component, this works perfectly well.

Since some time, we have a new component which depends on a resource from github.com/gardener/gardener, and is also included in our landscape-component. Whenever referenced github.com/gardener/gardener-versions from landscape-component and the new component get out of sync, we end up w/ two different versions of github.com/gardener/gardener.

While this works, in this specific case, this causes our BoM (which always honours transitive closure of all component-references) to contain a lot of component-versions that are not actually used (as explained, the mentioned new component only requires one resource from github.com/gardener/gardener, and none of its referenced component-versions). Considering aspects such as compliance-scans, having entries in our BoM that is not actually part of the payload I consider as a disadvantage.

Improvement Proposal

If we would allow Component-References to be declared with a marker to not resolve transitive component-references, this could be improved. This could be done by either a simple enum/boolean, like so:

componentReferences:
- name: do-not-follow
  componentName: github.com/gardener/gardener
  version: 1.100.0
  followTransitiveReferences: no

Obviously, such a flag will only be honoured for the special-case of resolving a component-graph starting from a root-component. The thus-referenced component does not itself bear a similar indication (and it should not, as it could of course also be referenced from other components), therefore this marker will only be useful in certain cases.

Nevertheless, I consider it useful, at least in the described (real) case of Gardener-Delivery. I would very much like to see such an attribute honoured by Component-CLI. However, this flag might be introduced as optional (so not all tooling would be required to implement it). This flag should also be backwards-compatible; ignoring it will just - unnecessarily - increase transitive closure of referenced componentversions.

[morri-son]

@fabianburth @hilmarf can you please check this and size it correctly? Although not high priority, it may make sense to assign it as possible task to Frederik in the next sprint (similar to #755)?

[fabianburth]

@ccwienk could you explain why the new component has to reference the gardener component even though it only depends on one of its resources? Why wouldn't you model it differently? So, why wouldn't you model that resource within its own component which is referenced by both, the new component and the gardener component?

[ccwienk]

@fabianburth : generally I agree. However, given current circumstances, such remodelling will not feasible and does not work well with existing project-setup

[ccwienk]

I (or actually @8R0WNI3 ) just brought to my attention that the functionality requested in this issue might also be covered by #902 - so feel free to consolidate.

[ccwienk]

as discussed /w @mandelsoft : allowing for incomplete ocm-components (which cannot be identified as such w/o knowing the referencing component) does in fact not seem like such a good idea. Hence I am closing this issue.