Proposal: Introduction of `skipDependencyResolution` Field for dependsOn in `Configurations`

[haarchri]

What problem are you facing?

This proposal suggests introducing a skipDependencyResolution field for the dependsOn attribute within configurations. In current practice, dependency resolution can be skipped only at a global configuration level. However, this often does not suffice for the nuanced needs of complex platform projects, especially in large companies where fulfilling all dependencies in a configuration can be challenging (Security, External Registries, same APIs Inhouse with additional features). The proposed feature aims to provide more granular control over dependency resolution within individual configurations.

Many companies, especially those with large platform projects, frequently encounter difficulties in managing dependencies within their configurations. The current approach allows for skipping dependency resolution for the entire configuration, which is often a blunt tool for what requires a more precise solution. https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/Configuration/[email protected]#spec-skipDependencyResolution

How could Crossplane help solve your problem?

The proposed solution is to introduce a new field, skipDependencyResolution, that can be used within the dependsOn attribute in configuration. This field would allow platform builders to specify if dependency resolution should be skipped for particular dependencies, rather than applying this skip to the entire configuration.

apiVersion: meta.pkg.crossplane.io/v1alpha1
kind: Configuration
metadata:
  name: test-configuration
spec:
  crossplane:
    version: ">=v1.14.1-0"
  dependsOn:
    - configuration: xpkg.upbound.io/upbound/configuration-aws-eks-karpenter
      version: "v0.5.0"
      skipDependencyResolution: true
    - configuration: xpkg.upbound.io/upbound/configuration-aws-eks-irsa
      version: "v0.5.0"
      skipDependencyResolution: true
    - provider: xpkg.upbound.io/upbound/provider-aws-sqs
      version: "v0.47.1"
    - provider: xpkg.upbound.io/upbound/provider-aws-cloudwatchevents
      version: "v0.47.1"
    - provider: xpkg.upbound.io/crossplane-contrib/provider-helm
      version: "v0.16.0"
    - provider: xpkg.upbound.io/crossplane-contrib/provider-kubernetes
      version: "v0.10.0"
    - provider: xpkg.upbound.io/upbound/provider-aws-ec2
      version: "v0.47.1"
    - provider: xpkg.upbound.io/upbound/provider-aws-eks
      version: "v0.47.1"
    - provider: xpkg.upbound.io/upbound/provider-aws-iam
      version: "v0.47.1"
    - function: xpkg.upbound.io/upbound/function-patch-and-transform
      version: "v0.2.1"

The primary benefit of this feature is the increased control it offers platform builders over their configurations. By allowing dependency resolution to be skipped on a per-dependency basis, teams can manage their configurations more effectively, especially in scenarios where certain dependencies are known to be unnecessary or problematic. This flexibility is particularly valuable in large-scale platform projects where managing a vast number of dependencies can be challenging.

Implementation Considerations

• This change should be backward compatible, not affecting existing configurations that do not use the new field.
• Care must be taken to ensure that the introduction of this field does not introduce unexpected behavior in dependency resolution in package manager
• Documentation and examples should be updated to reflect this new feature.

[negz]

By allowing dependency resolution to be skipped on a per-dependency basis, teams can manage their configurations more effectively, especially in scenarios where certain dependencies are known to be unnecessary or problematic.

Can you give some examples of a dependency being unnecessary or problematic? If a dependency was unnecessary, wouldn't you just not list it as a dependency of the configuration?

  dependsOn:
    - configuration: xpkg.upbound.io/upbound/configuration-aws-eks-karpenter
      version: "v0.5.0"
      skipDependencyResolution: true

Does this then become information purely for human consumption? Should I read it as:

• This package depends on configuration-aws-eks-karpenter...
• ...but the package manager should ignore this dependency.

If so, I would suggest skipDependencyResolution is probably not the most intuitive name for the field in this context.

[bobh66]

I had the same reaction when I read the description, but I think the skipDependencyResolution is referring to the dependencies of the dependency. So it is trying to tell the package manager to skip the dependencies of the configuration-aws-eks-karpenter and configuration-aws-eks-irsa dependencies.

It seems a little odd to specify this inside the definition of the Configuration itself - it seems like something that the package deployer would want to control more than the package author. What happens if this Configuration is installed in a Crossplane cluster that doesn't have the skipped "sub-dependencies" installed?

[haarchri]

Add a PR for this https://github.com/crossplane/crossplane/pull/5285 add description and some live tests - feel free to discuss

[github-actions[bot]]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[haarchri]

/fresh

[github-actions[bot]]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

[ytsarev]

/fresh

[github-actions[bot]]

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.