[chef] Re: what cookbook are people using to interact with AWS these days?

[Kevin Nuckolls < >]

At one point I delved deep into the ruby aws gem code. The trick was to find where it constructs the URL for API access and instead change that to you internal eucalyptus API endpoint. One more interesting note that took me awhile to discover was that eucalyptus matches an older aws API version. That needed to be overridden as well.

I found the innards of the ruby aws code to be a bit over complicated as far as fixing that bug was concerned, which makes sense as the original author likely never meant for that part to be patched. Anyway I ended up using fog for my purposes. It already exposed the API endpoint and API version as parameters I could just pass in. Rather convenient. 

I did the minimal amount of work to get this working. We had to patch the knife-eucalyptus plugin. In retrospect I wish I had spent time making the knife-ec2 plugin more general instead of continuing to perpetuate the Balkanized tooling that knife-ec2 and knife-eucalyptus represent. One of my co-workers is actively working on getting the aws cookbook working with eucalyptus as well using the fog gem. The dependencies aren't that big of a deal IMO.

That said, yeah I'd prefer that the library cookbooks for aws interop use the official ruby aws gem. Someone just needs to roll up their sleeves and get that gem patched so you can use it with eucalyptus. Maybe that'll be me? Maybe some other brave soul?

Hope that's helpful context. 

Kevin Nuckolls

@knuckolls

https://github.com/knuckolls/knife-eucalyptus

On Sunday, January 13, 2013, Hector Castro wrote:

@Kevin – I think the main opposition to using Fog for the AWS cookbook
is the number of gem dependencies it introduces.  Your point about
Eucalyptus interoperability is certainly valid – not sure how well the
Ruby AWS SDK handles this.

--
Hector


On Sat, Jan 12, 2013 at 5:36 PM, Kevin Nuckolls
< > wrote:
> I have one data point that may be of use. We use eucalyptus internally,
> which is intended to be API compatible with AWS. It works exceedingly well.
> The only thing we've had any trouble with is swapping these gems to point to
> eucalyptus instead. The newest versions of the fog gem have made this very
> simple, and it's what we've built our aws cookbook, tooling, etc around.
>
> I think it's likely best to keep in mind that these tools will be used with
> Eucalyptus too. The more they interop, the better.
>
>
> On Fri, Jan 11, 2013 at 4:10 PM, Hector Castro < > wrote:
>>
>> For the record, it appears that RightScale is actually keeping up with AWS
>> feature additions – they just aren't cutting new versions of the gem.  This
>> is why I had to take a snapshot of their GitHub repository and create a .gem
>> from that.
>>
>> All of that said, I agree that moving to the official AWS Ruby SDK is the
>> best long-term solution.
>>
>> --
>> Hector
>>
>>
>> On Thu, Jan 10, 2013 at 1:54 PM, Mike < > wrote:
>>>
>>> What say you, Joshua/Opscode? Would taking a stab at replacing the
>>> right_aws gem with the AWS-supported one be something you'd consider?
>>>
>>> On Thu, Jan 10, 2013 at 11:54 AM, Greg Symons < >
>>> wrote:
>>> > Agreed. right_aws is also missing support for VPCs, so things like
>>> > autojoining load balancers won't work in a VPC.
>>> >
>>> > Greg
>>> >
>>> >
>>> > On 01/10/2013 10:23 AM, John E. Vincent (lusis) wrote:
>>> >>
>>> >> It might be worth considering moving to the official AWS ruby gem
>>> >> instead of right_aws and waiting for it to support features?
>>> >>
>>> >> On Thu, Jan 10, 2013 at 11:12 AM, Joshua Timberman
>>> >> < >
>>> >> wrote:
>>> >>>
>>> >>> Thanks Ben. Do you have any code for those? Or if anyone else does, a
>>> >>> pull
>>> >>> request would be great :).
>>> >>>
>>> >>> On Wednesday, January 9, 2013 at 16:42, Ben Hartshorne wrote:
>>> >>>
>>> >>> yup, that's the one.  I didn't look in detail at the three open
>>> >>> requests,
>>> >>> so
>>> >>> I'm glad to hear that they're being watched.
>>> >>>
>>> >>> As requested:
>>> >>> http://tickets.opscode.com/browse/COOK-2193 - Support for PIOPS
>>> >>> http://tickets.opscode.com/browse/COOK-2194 - Support for EBS
>>> >>> Optimized
>>> >>> instances
>>> >>>
>>> >>> :)
>>> >>>
>>> >>> -ben
>>> >>>
>>> >>>
>>> >>> On Wed, Jan 9, 2013 at 3:19 PM, Joshua Timberman < >
>>> >>> wrote:
>>> >>>
>>> >>> What cookbook are you referring to? Our Aws cookbook has three open
>>> >>> pull
>>> >>> requests. One was reviewed to be merged, one is a dupe that didn't
>>> >>> have a
>>> >>> CLA so a different one was merged and the third is a whitespace
>>> >>> change
>>> >>> but
>>> >>> no ticket so we hadn't reviewed it yet.
>>> >>>
>>>

-- 
Sent from my cellular telephone