boto/boto3#71
s3_bucket.presigned_post(key: …) in v1 gives a fancy object with fields and url that accepts a multipart post. is there an equivalent in v2? s3_bucket.object(key).presigned_url(:put) gives a string url that stores the body as the object, which isn't ideal
will there be any feature additions to the CloudFormation.resources.json? I am finding some of the actions (like GetTemplate, GetStackPolicy, etc) are missing. Some of the resource schema do not have path information.
For example,
"Stacks": {
"request": { "operation": "DescribeStacks" },
"resource": {
"type": "Stack",
"identifiers": [
{ "target": "Name", "source": "response", "path": "Stacks[].StackName" }
]
}while the EC2 API returns the attributes in response in lower-camel cased (e.g.
keyName)?it may not matter for ruby SDK since it transforms everything to snake_case. But wouldn't it be nice if the resources.json files could mimic the AWS response casing as much as possible?
@nitinmohan87 The casing of attributes as they appear in the EC2.resources.json document is consistent with the names as they appear in the EC2.api.json document. They do not reference the names as they appear on the wire. This is standard with all of the various AWS protocols. ALL of the AWS SDKs, Java, .Net, PHP, Ruby, Python, CLI, JavaScript, and Go, use the member names as they appear in the API instead of the wire format name. For example, when working with Amazon EC2, if you describe instances, you get back over the wire something like (nested in the response):
<reservationSet>
<item>
<instanceSet>
<item>
<instanceId>i-1234578</instanceId>
…
</item>
</instanceSet>
</item>
</reservationSet>
…None of our SDKs represent the “item” in the reservation list, or in the instance list. Also, none of our SDKs returns these two lists as “reservationSet” or “instanceSet”. They all use the names “Reservations” and “Instances”. This information is how it is documented in the EC2.api.json document. These deltas are not limited to Amazon EC2 either. These changes appear in many/most of the APIs.
Essentially, the API document describes a webservice’s public interface, with just enough information to marshall and unmarshall requests and responses given information such as the protocol, and the shape and shape reference traits.
For consistency, the resource models all references the API names, not the wire format names.
resp = sqs.receive_message(
queue_url: "...",
attribute_names: ["All"],
#message_attribute_names: ["MessageAttributeName", '...'],
max_number_of_messages: 10,
visibility_timeout: 1,
wait_time_seconds: 1,
)
aws configure on the command line
Aws::S3::Resources
def exists?(key)
object(key).metadata
true
rescue ::Aws::S3::Errors::NotFound
false
end
s3.client.get_bucket_location(bucket: ‘bucketname’) && true rescue false — https://github.com/aws/aws-sdk-ruby/blob/master/aws-sdk-core/features/s3/step_definitions.rb#L75
#exists? check methods are on the public backlog (https://github.com/aws/aws-sdk-ruby/blob/master/FEATURE_REQUESTS.md#adding-exists-method-to-resource-classes). There is a reasonable plan in place, its mostly down to augmenting the resource definitions with reference to which waiter should be invoked.
@trevorrowe @jbr I have come up with this one for now:
$s3 = Aws::S3::Resource.new(region: 'us-east-1')
def exists?(bucket) begin $s3.bucket(bucket).wait_until_exists do |w|
w.interval = 1
w.max_attempts = 1
end
true
rescue Aws::Waiters::Errors::WaiterFailed
false
end
endWorks well for now.
#exists? is going to be implemented in terms of #wait_until_exists instead of the other way around? Would have expected #wait_until_exists to poll #exists? instead of the latter being the single-attempt special case of the former
@jbr There is not. I’m open to discussion on the implementation. The reason I’m inclined to have the #exists? method poll an exists waiter once is two fold:
- Expands the number of waiters available for polling from the client level
- The
#exists?check benefits from the inherited waiter ability to have multiple success and failure states that can match on http status codes, exracted response data, error codes, etc.
The solution should also avoid one-off hand-coded solutions that can not be shared between the other AWS SDKs.
The example from @abalakersky is in line with what I am envisioning.
#exists?, which might not be desirable overall
