Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple reference Types #95

Closed
donovanmuller opened this issue Sep 13, 2022 · 2 comments
Closed

Support multiple reference Types #95

donovanmuller opened this issue Sep 13, 2022 · 2 comments
Labels
enhancement New feature or request is:triaged

Comments

@donovanmuller
Copy link

donovanmuller commented Sep 13, 2022

What problem are you facing?

Currently, you can add a single, explicit reference, to another resource like this example for google_cloud_scheduler_job:

	p.AddResourceConfigurator("google_cloud_scheduler_job", func(r *config.Resource) {
		r.References["pubsub_target.topic_name"] = config.Reference{
			Type: "github.com/upbound/official-providers/provider-gcp/apis/pubsub/v1beta1.Topic",
		}
	})

However, some resources can accept references for multiple Types. In the example above, Both a Topic and a LiteTopic are supported. Upjet currently does not allow multiple references, of different Types, for a single argument.

How could Terrajet help solve your problem?

Allow specifying multiple supported reference Types for an argument. E.g.

	p.AddResourceConfigurator("google_cloud_scheduler_job", func(r *config.Resource) {
		r.References["pubsub_target.topic_name"] = []config.Reference{
			config.Reference{
				Type: "github.com/upbound/official-providers/provider-gcp/apis/pubsub/v1beta1.Topic",
			},
			config.Reference{
				Type: "github.com/upbound/official-providers/provider-gcp/apis/pubsub/v1beta1.LiteTopic",
			},
		}

Terrajet community example here.

@donovanmuller donovanmuller added the enhancement New feature or request label Sep 13, 2022
@csantanapr
Copy link

I hit this problem today with the SubscriptionFilter

The filter takes a destinationArnRef or destinationArnSelector is based on [destinationArn](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutSubscriptionFilter.html#API_PutSubscriptionFilter_RequestSyntax)
The ARN of the destination to deliver matching log events to. Currently, the supported destinations are:

  • An Amazon Kinesis stream belonging to the same account as the subscription filter, for same-account delivery.
  • A logical destination (specified using an ARN) belonging to a different account, for cross-account delivery.
  • A Kinesis Data Firehose delivery stream belonging to the same account as the subscription filter, for same-account delivery.
  • A Lambda function belonging to the same account as the subscription filter, for same-account delivery.
    The destination can be of kind Lambda, Kinesis Stream, Kinesis Firehose, or OpenSearch

I want to create a subscription for destination to Kinesis Data Firehose but only Amazon Kinesis stream is supported

I tried the following, having a Delivery system with labels

apiVersion: firehose.aws.upbound.io/v1beta1
kind: DeliveryStream
metadata:
  labels:
    crossplane.io/claim-name: test-logs-firehose-s3-lambda
    crossplane.io/claim-namespace: default
    firehoseapps.awsblueprints.io/app: firehose

...

I create a subscription with destinationArnSelector

apiVersion: cloudwatchlogs.aws.upbound.io/v1beta1
kind: SubscriptionFilter
metadata:
  name: dynatrace-aws-logs-test
spec:
  forProvider:
    destinationArnSelector:
      matchLabels:
        crossplane.io/claim-name: test-logs-firehose-s3-lambda
        crossplane.io/claim-namespace: default
        firehoseapps.awsblueprints.io/app: firehose
    filterPattern: ""
    logGroupName: "/aws/eks/crossplane-blueprints/cluster"
    name: "dynatrace-aws-logs-test"
    region: "us-east-1"
...

I get error

    message: 'cannot resolve references: mg.Spec.ForProvider.DestinationArn: no resources
      matched selector'
    reason: ReconcileError

@turkenh
Copy link
Member

turkenh commented Mar 30, 2023

I am afraid this is a limitation of how Cross Resource References are designed and implemented in Crossplane. Resource references are defined at build time and to only one other type.

Generic Cross-Resource References would be the solution for the problem described here and is one of our top priorities.

If your resources exist in the same composition, you can patch the value as a workaround today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request is:triaged
Projects
None yet
Development

No branches or pull requests

5 participants