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
http://pivotallabs.com/users/chad/blog/articles/366-ruby-debug-in-30-seconds-we-don-t-need-no-stinkin-gui-).
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).
marios
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<[email protected]> 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.,
ec2.us-east-1.amazonaws.com) 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