I have a question about how to handle circular dep...
# general
m
I have a question about how to handle circular dependency between an S3 Bucket and an S3 Bucket Policy. Is this the place to do so?
c
You need the name of the S3 bucket to mention it in the bucket policy, but need to have the bucket policy in order to create the S3 bucket. Do I have that right? If it is just the name of the S3 bucket, you can rely on the harded-coded value you provide for
bucketName
e.g. “uploads-bucket” and “s3://uploads-bucket”. But that obviously won’t work if you are relying on Pulumi to name the bucket for you.
You can control the ordering of resource creation by specifying the `pulumi.ResourceOption`’s
dependsOn
property. But I don’t believe there is any way for us to break a circular dependency like that. (@white-balloon-205 would know for certain.)
m
You understand the problem precisely.
So if I supply the name of the bucket in BucketArgs, does that avoid the autogened ID suffix on the bucket name?
c
Yes, precisely. That will set the name property of the resource directly, which also means that it needs to be globally unique since the “S3 bucket namespace” is shared with all other S3 buckets.
m
Excellent. That'll do the trick. Thank you very much.
For the record, assigning
BucketArgs.bucket
to a hard-coded value avoids the circular dependency. Of course, as @colossal-beach-47527 mentioned, you'll have to devise a naming scheme that is globally unique. Furthermore, if you don't want to recreate the bucket every time, you'll need to keep the bucket name consistent across build & deploy cycles.
p
@modern-diamond-82589 You may want to look at the
aws.s3.BucketPolicy
resource, which allows you to attach a bucket policy to an existing bucket.
m
That could be what I was looking for all along. The example looks like the very thing I'm trying to accomplish. I'll report back with success/failure.
Success -
aws.s3.BucketPolicy
works great.
👍 2
s
There was a marked change in the design of the Terraform provider for AWS about ~3 years ago when separate resources started being preferred for things like policies and (e.g.) security group rules vs nested blocks - precisely because of this problem