Open ezgidemirel opened 3 weeks ago
I've spent some time on this bug to find a quick fix, but got stuck after noticing that we're not passing default registry info to the lock obj. Therefore, storing the correct parent constraints on the edges is not possible with the current data structures.
I suggest to reimplement dependency management logic in Crossplane from scratch to handle package identification and constraint satisfactions in a better way.
What happened?
With the recent changes, we know see the resolver reconciler's error messages in the lock object's conditions. This allows us to understand why package manager does not proceed with dependency installations.
When there are multiple packages depending on the same package, we're trying to find a valid version which satisfies all constraints. If there is no such version, or if that version requires a downgrade, package manager gives and error and stores it in the lock object as a condition.
In the following case, multiple packages are depending on provider-nop with different constraints,
However, error message does not contain the first constraint
<=v0.3.0
. Also,=v0.2.0
constraint is displayed multiple times which can also be improved.How can we reproduce it?
To reproduce, we need to enable the alpha feature by passing
--enable-dependency-version-upgrades
and apply the following manifest:P.S: Feature flag is required because without this new behavior, resolver reconciler does not send an error since all dependencies are installed (even though the versions are not satisfying the constraints) and only the package revision reconciler displays the error.
What environment did it happen in?
Crossplane version: v1.18.0