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

Reconcile Route53 ResourceRecordSet Dependencies When Applying Multiple Resources #423

Closed
phantasm66 opened this issue Nov 9, 2020 · 6 comments
Labels
enhancement New feature or request

Comments

@phantasm66
Copy link

phantasm66 commented Nov 9, 2020

It would be great if Crossplane could reconcile Route53 dependencies when applying multiple resources at the same time.

For example:

The following manifest defines multiple resources for Crossplane to provision an AWS Security Group, ElastiCache (redis) cluster and a vanity DNS CNAME Route53 record:

apiVersion: ec2.aws.crossplane.io/v1beta1
kind: SecurityGroup
metadata:
  name: redis-cache-kubernetes-lab
spec:
  providerConfigRef:
    name: default
  forProvider:
    description: "testing crossplane"
    region: us-east-1
    vpcId: vpc-abc123
    groupName: redis-cache-kubernetes-lab
    ingress:
      - fromPort: 6379
        toPort: 6379
        ipProtocol: tcp
        ipRanges:
          - cidrIp: 10.208.0.0/16

---

apiVersion: cache.aws.crossplane.io/v1alpha1
kind: CacheCluster
metadata:
  name: redis-sidekiq
spec:
  providerConfigRef:
    name: default
  forProvider:
    region: us-east-1
    engine: redis
    engineVersion: "5.0.6"
    cacheParameterGroupName: redis-50-staging-useast1
    cacheNodeType: cache.t2.small
    numCacheNodes: 2
    cacheSubnetGroupNameRef:
      name: kubernetes-cache-lab
    securityGroupIdRefs:
      - name: redis-cache-kubernetes-lab

---

apiVersion: route53.aws.crossplane.io/v1alpha1
kind: ResourceRecordSet
metadata:
  name: redis-sidekiq.my-domain.com
spec:
  providerConfigRef:
    name: default
  forProvider:
    type: CNAME
    ttl: 300
    resourceRecords:
      - value: ${the AWS generated endpoint FQDN of the CacheCluster resource}
    zoneIdRef:
      name: my-domain.com

The advantage of applying everything all at the same time is that we can template out all resources for an application and apply/provision everything in a single automated deployment pipeline.

The problem with the above manifest is that the spec.forProvider.resourceRecords.value is not actually known until after the CacheCluster resource is created and AWS has generated an endpoint FQDN we can then reference in this ResourceRecordSet resource.

Ideally, this feature should be generic enough that a ResourceRecordSet's spec.forProvider.resourceRecords.value reference to a dependency resource being applied at the same time will work for CacheCluster, RDSInstance, etc...

@phantasm66 phantasm66 added the enhancement New feature or request label Nov 9, 2020
@muvaf
Copy link
Member

muvaf commented Nov 19, 2020

There are two possible solutions to this:

  • We have the usual reference&selector fields but they are strongly types, so you can't use different managed resource kinds for the same field. We can have an additional way in references where you can specify the type as well assuming provider-aws knows how to take the value from that type, too. Additionally, there could be a DSL-like way of saying go get this field from that type and format it that way.
  • In Composition, we have that patch & format mechanism. However, it doesn't support inter-resource value propagation yet. But once Composite resources should support bidirectional patching crossplane/crossplane#1639 is implemented, users will be able to say RDSInstance.status.atProvider.fqdn should be propagated to composite.status.atProvider.rdsURL and ResoruceRecordSet.spec.forProvider.resourceRecords[0].value should be patched by the value in composite.status.atProvider.rdsURL after applying some format transforms.

I believe the second solution is cleaner and keeps the managed resources simple, however, it works only if you use composition. To cover your use case, I believe hard-coded sets (there would be a set of kinds you can refer, similar to today but you control the kind as well) could be better compared to a small DSL.

@chlunde
Copy link
Collaborator

chlunde commented Apr 12, 2021

It looks like this issue will be fixed once crossplane/crossplane#2180 is merged

@haarchri
Copy link
Member

@phantasm66 is it still relevant since crossplane/crossplane#2180 and crossplane/crossplane#1639 are merged it is possible and we also use this with other resources like your example

@phantasm66
Copy link
Author

I’m good. I’ll close this….

@jcputter
Copy link

@muvaf are there any docs or examples of how to do this? i'm trying to create an rds via composition and create a vanity dns for it

@ashishkurian
Copy link

@muvaf or @haarchri

I have created a NLB using the LoadBalancer CRD. But now I want to attach a specific DNS entry to it. How can I acheive that using the ResourceRecordSet CRD.

I could not find any documentation anywhere as to how to achieve that connection using the resource name or selectors.

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

No branches or pull requests

6 participants