aws/aws-sdk-ruby

The official AWS SDK for Ruby.

Robin van Wijngaarden

@robinvw1

but i'm receiving Aws::S3::Errors::NotFound

is the documentation up-to-date?

Trevor Rowe

@trevorrowe

@robinvw1 That is a documentation bug / limitation. Normally, if you perform an operation against an object that does not exist, e.g. a GET object, Amazon S3 will return a response with an XML body indicating that there is no such key. However, per the HTTP spec, the response to a HEAD request may not have a body. For this reason, the SDK has no error message or code to parse, so it falls back on NotFound.

I've considered guessing, but this proved problematic, as it is not possible to know if the 404 is a result of a no such bucket or no such key.

We need to change this in the docs to reflect the SDK will raise a NotFound.

chrishawk

@chrishawk

Does anyone know if there is a way of writing data to an s3 object? It looks like object.write was gotten rid of in place of object.upload_file in the new v2 sdk

Trevor Rowe

@trevorrowe

You can call Aws::S3::Client#put_object, or Aws::S3::Object#put

chrishawk

@chrishawk

wow awesome thanks

I don't know how I missed that

What about object.move_to

what's the equivalent in v2

I've been trying copy_object but it produces a Aws::S3::Errors::AllAccessDisabled error I can't figure out

Trevor Rowe

@trevorrowe

The #move_to method was a wrapper around #copy_object. If you share a gist, then I can see if I can help debug your call.

Robin van Wijngaarden

@robinvw1

@trevorrowe thanks for your answer :)

Trevor Rowe

@trevorrowe

@robinvw1 No problem!

chrishawk

@chrishawk

I actually have a stackoverflow question with it

http://stackoverflow.com/questions/28655936/aws-sdk-v2-allaccessdisabled-error-for-s3-file-copy

Trevor Rowe

@trevorrowe

I responded there, but in short, your copy_source option is formatted incorrectly. It must be “#{source bucket}/#{sourcekey}”.

chrishawk

@chrishawk

cool thanks, I'll give that a try in a little bit

Andrew Frank

@sirmxanot

Where is the documentation specifying which waiters are available for which services and what params those waiters expect? For instance the only examples I see are relating to EC2, and the RDS waiter documentation doesn't specify which waiters are available for rds clients http://docs.aws.amazon.com/sdkforruby/api/Aws/RDS/Client.html#wait_until-instance_method

Trevor Rowe

@trevorrowe

@sirmxanot In the “Parameters” section of the #wait_until method you linked documentaiton for, it indicates that the accepted waiter names and the operations they call are specified in the #waiter_names method. It is linked from there. In the #waiter_names method, it shows the API call being pulled and links to that:

For RDS:
http://docs.aws.amazon.com/sdkforruby/api/Aws/RDS/Client.html#waiter_names-instance_method

Daniel Collis-Puro

@djcp

So I've scripted stack creation via the ruby API. One odd thing - when I create an instance_profile I don't see it in the web console but I do when I call iam_client.list_instance_profiles

and it's associated with the stack properly - but this makes me think I'm missing something.

associated with the stack in the web console, that is.

Andrew Frank

@sirmxanot

@trevorrowe Thank you! Also, sorry for the obvious question :-)

Trevor Rowe

@trevorrowe

@sirmxanot No problem. Your question is valuable feedback. I’ve considered making this table more prominent, and I should probably move it from #waiter_names to #wait_until where people are looking.

@djcp I think the console has some magic around the creation of instance profiles. If I recall correctly, you have to create a role policy, and a role, associate them, then create an instance profile and associate the policy to that. The console profiles a single wizard for creating them all together. I suspect, though I don’t know, that only displays the policies that it manages.

Daniel Collis-Puro

@djcp

@trevorrowe Huh, interesting. I'll keep that in mind, IIRC I've arrived pretty much at what you layed out above. If I'm doing something wrong, I bet it'll be apparent when I get to adding instances.

Trevor Rowe

@trevorrowe

@djcp If I recall correctly, the only tricky for me was setting the correct assume role policy document. Its a json document that grants EC2 the right to assume a role on behalf of your account. There is a boilerplate document that I used. I haven’t set one up in a while.

Daniel Collis-Puro

@djcp

It seems like a bunch of clients lack waiters - Aws::IAM::Client for example. Is implementing a new waiter as easy as creating a new json definition and registering it with a service via Aws.service() or is there more to it? I am driving some operations that definitely need waiters and I would rather get them into the SDK than implement the semantics myself by hand.

@trevorrowe

Trevor Rowe

@trevorrowe

@djcp It is simply a matter of creating the waiter definitions as a json document and then add it to the add_service call.

Daniel Collis-Puro

@djcp

So should I do that and send you a PR, @trevorrowe ?

Trevor Rowe

@trevorrowe

@djcp Absolutely.

Daniel Collis-Puro

@djcp

@trevorrowe - I'm attempting to add a waiter to the IAM client to ensure the Instance Profile is available but I am getting Aws::Waiters::Errors::NoSuchWaiterError: no such waiter :instance_profile_available; valid waiter names are: no matter what. Link: harvard-dce/aws-sdk-ruby@bd9510c

The list of valid waiter names is always empty. What am I missing?

Daniel Collis-Puro

@djcp

It's weird because what I'm doing looks very similar to this commit: aws/aws-sdk-ruby@0d054b6

Daniel Collis-Puro

@djcp

forget it - I've got it working. It was an issue with binstubs in my testing environment. We're good!

lisabien

@lisabien

Resource metadata seems inconsistent. For example, EC2.resources.json gives us something like this for resources:

    "DhcpOptions": {
      "identifiers": [
        {
          "name": "Id",
          "memberName": "DhcpOptionsId"
        }
      ],

This is great for determining the underlying resource ID name. However CloudFormation.resources.json looks like this:

    "Stack": {
      "identifiers": [
        { "name": "Name" }
      ],

There's no memberName to reveal the underlying name (e.g. "StackName"). Which example is the standard, and what is the best way to determine the underlying resource ID name?

Trevor Rowe

@trevorrowe

The memberName is only populated when the identifier is echoed as part of the named “shape” from the API model. If the resource has no shape (additional properites) or if the property does not repeat the identifier, it has no shape “memberName”.

Trevor Rowe

@trevorrowe

@lisabien I took a look at the cloudformation resource model, and it appears that some of the resources, like Stack, were missing memberName traits where they should have been applied. See: aws/aws-sdk-ruby@e5d5eae

lisabien

@lisabien

Cool, thx! It appears that other resource files, like OpsWorks (and maybe others, but didn't check) have the same missing memberName issue. Would it be possible to get the resource files updated with memberName, too?

Trevor Rowe

@trevorrowe

Its possible for the services where the value is present in the shape, which is not always. If you know of any service missing them, please let me know.

lisabien

@lisabien

Will do. I'll go back and take a look. Thx!

Trevor Rowe

@trevorrowe

Out of curiosity, what are you consuming the files for?

lisabien

@lisabien

I'm working with @tve, our use case is a proxy that exposes a standardized json interface and also a restful interface. this will be used by a set of other services and we want to feed everything through the proxy for a variety of reasons.

Trevor Rowe

@trevorrowe

Sounds cool, keep the questions coming.

lisabien

@lisabien

Why does API metadata (e.g. EC2's DescribeKeyPairs) specify their parameter names in CamelCase, when the underlying call actually expects snake_case?

KeyNames vs. key_names

Where communities thrive

People

Repo info

Activity