On Fri, Jul 01, 2011 at 10:04:16AM -0400, Hugh Brock wrote:
On Thu, Jun 30, 2011 at 10:30:20AM -0400, wes hayutin wrote:
> woot!!!
>
> On Tue, 2011-04-12 at 11:58 -0400, Matt Wagner wrote:
> > Hi all,
> >
> > I spent a bit of time tracking down the remnants of #671 / BZ 651562, in
> > which Apache throws proxy timeout errors because the backend does not
> > respond in time as a result of API calls timing out.
> >
> > Most of these errors were fixed a bit ago in deltacloud-client, but it
> > seems that the versions yum and gem know about don't have this fix, so
> > the issue was seemingly not fixed. I spent a bit getting deltacloud
> > 0.3.0 running, and was unable to reproduce any errors with Apache
> > timeouts after attempting to simulate unreachable providers and other
> > cases where a timeout may occur. The timeouts in deltacloud-client are
> > slightly shorter than Apache's timeout value.
> >
> > I'm attaching a patch that cleans up error handling in Conductor
> > slightly. There were a few spots (e.g., adding a new ProviderAccount
> > when the provider was unreachable) where the timeout exception was
> > reaching the user unhandled. This exception now triggers as a
> > flash[:error] message when raised, in lieu of a hard error.
> >
> > You will need the 0.3.0 version of deltacloud to test this. (Some older
> > versions may work, but best not to chance it.) You can build this from
> > their source, although I suspect some of you already the 0.3.0 RC
> > installed.
> >
Matt, are these correct versions now installed by configure?
On a fresh RHEL 6.1 install of aeolus-all, I get:
deltacloud-core.noarch = 0.3.9999-1308927004.el6
rubygem-deltacloud-client.noarch = 0.1.0-2.el6_0
Fedora seems to have rubygem-deltacloud-client.noarch = 0.3.1-1.fc14, so
I think we just need to get the client updated for RHEL.
-- Matt