incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Debugging communication between Deltacloud and specific providers
Date Mon, 30 May 2011 06:12:42 GMT
I don't know if its trivial/possible to capture the communication 
between deltacloud and a given provider since that communication 
typically happens in a third party ruby gem (e.g. the 'aws' gem in the 
case of ec2). However I agree that this needs some thought as whenever I 
implement something new, part of my process is to 'see' what is being 
sent/received from the provider.

fwiw, I always use 'ruby-debug' ('gem install ruby-debug' <then in 
source code> 'require ruby-debug' <and any point you want to set a 
breakpoint> 'debugger' - see

This allows me to see exactly the values of variables, requests, 
responses, step through code etc etc.

If you give us some more info about the point at which you're having 
problems with the ec2 driver (i.e. which functionality? for instance 
listing images? etc) I can try and be more specific about where you 
might want to set a breakpoint in the actual aws gem code (gems live in 
/usr/lib/ruby/gems/1.8/gems on my machine).


On 28/05/11 15:12, Sang-Min Park wrote:
> Hi Justin,
> Actually I'd use tcpdump as it worked pretty well for me. Try:
> tcpdump -i eth0 -A -s 4096 -l 'tcp port [EC2 PORT #]'
> On 5/28/11, David Lutterkort<>  wrote:
>> On Sat, 2011-05-28 at 06:42 +1000, Justin Clift wrote:
>>> Hi guys,
>>> Is there a way to turn on debug level logging verbosity
>>> for the deltacloud daemon?  Trying to see what is actually
>>> being sent to a cloud provider we're having trouble with (EC2),
>>> and what is being returned. (ie ssl errors, error messages in
>>> general, whatever)
>> The Deltacloud code itself doesn't have any hooks to turn up logging;
>> for EC2 specifically, we use the aws gem[1] - that might give you some
>> ways to see in more details what's happening.
>>> *Might* be able to use something like tcpdump, but that
>>> seems pretty overkill and I'm not personally all that
>>> familiar with it these days.
>>> Ideas?
>> I'd use a reverse HTTP proxy and just turn logging on it up all the way
>> to 11. Point the proxy at one of the Amazon URL's (e.g.,
>> and then set the API_PROVIDER env variable
>> to the URL of your proxy. Sadly, you can't provide URL's for ec2, s3 and
>> elb in one fell swoop with this. We should look into enhancing the drive
>> to support this.
>> David

View raw message