Use S3 bucket's name as part of an object's name #10
Assignees
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
idwhen referencing another resource object, in which case object could reference bucket'snameproperty and then it would, in theory, not be computed (necessarily).The text was updated successfully, but these errors were encountered: