-
Notifications
You must be signed in to change notification settings - Fork 154
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
Use S3 bucket's name as part of an object's name #10
Comments
joeduffy
added a commit
that referenced
this issue
Aug 4, 2017
This change fixes some issues that were previously blocking the Elastic Beanstalk tests, and reenables our tests for the sample. In summary: * Ingest two relevant fixes from the fabric and repos: - pulumi/pulumi@a160741 - pulumi/pulumi-terraform@7d52bd6 * Subtly, our projection of S3 objects is plain wrong. It attempts to create a name automatically by combining the bucket namd with the object key name. This suffers from an obvious issue: almost always, the bucket is going to be another resource, whose ID is computed. And therefore we attempt to generate a URN using a computed property, which cannot work (URNs are required before actually deploying things). This is a little unfortunate. A bucket's name itself is easy to "guess" based on the inputs, so there's no real reason it needs to be computed. Eventually, we can explore doing something smarter here, although there are a number of challenges with that. This is being tracked by #10. Instead, we'll give S3 objects a traditional name, and use said name as the key by default unless a separate key is also given. This is simple and intuitive for most cases, although the fact that two objects in the same module that share a key but are in totally different buckets is going to pop up and annoy/confuse people.
Merged
joeduffy
added a commit
that referenced
this issue
Aug 4, 2017
This change fixes some issues that were previously blocking the Elastic Beanstalk tests, and reenables our tests for the sample. In summary: * Ingest two relevant fixes from the fabric and repos: - pulumi/pulumi@a160741 - pulumi/pulumi-terraform@7d52bd6 * Subtly, our projection of S3 objects is plain wrong. It attempts to create a name automatically by combining the bucket namd with the object key name. This suffers from an obvious issue: almost always, the bucket is going to be another resource, whose ID is computed. And therefore we attempt to generate a URN using a computed property, which cannot work (URNs are required before actually deploying things). This is a little unfortunate. A bucket's name itself is easy to "guess" based on the inputs, so there's no real reason it needs to be computed. Eventually, we can explore doing something smarter here, although there are a number of challenges with that. This is being tracked by #10. Instead, we'll give S3 objects a traditional name, and use said name as the key by default unless a separate key is also given. This is simple and intuitive for most cases, although the fact that two objects in the same module that share a key but are in totally different buckets is going to pop up and annoy/confuse people.
@jen20 if this is obviously a bad idea, let's close out. Otherwise, just assigning to you for future consideration. |
I'm not exactly clear what the specific issue was here - but regardless we've lived in this state for 2+ years without new reports of this - so closing out for now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment, we just use the object name in its URN (and auto-propagate that to the key). Unfortunately, this means if you have two objects in the same module, with the same names but different buckets, they will get assigned the same URN. Ideally there would be a way to use a different property than
id
when referencing another resource object, in which case object could reference bucket'sname
property and then it would, in theory, not be computed (necessarily).The text was updated successfully, but these errors were encountered: