Openstack and Juju not working

[Sebastian]

Hey David! thanks for the tips.

I did another search trying to find something about this or someone else
having this problem, but nothing founded yet.
The strange thing is that I can upload through the command line, so must be
related only with the proxy server, right?

So now Im going to log capturing the traffic to see if we find something.

Thanks for the help guys!

Cheers!,
Sebas.



2014-03-27 5:23 GMT-03:00 David Cheney <david.cheney at canonical.com>:

> From the log file
>
>
>    1. ==> /var/log/apache2/proxy-server <==
>    2. [Wed Mar 26 23:41:28 2014] [error] [client x.x.x.x] Requested
>    content-length of 9223372036854775807 is larger than the configured limit
>    of 5368709122
>
>
> 9223372036854775807 is MAX_INT for an int64 value
>
> Further down in that log apache is segfaulting
>
>    1. ==> /var/log/apache2/error.log <==
>    2. [Wed Mar 26 23:42:00 2014] [notice] child pid 10445 exit signal
>    Segmentation fault (11)
>
> which is very worrying.
>
> If this service is *not* talking over https I recommended getting out a
> copy of ngrep and capturing the traffic on the wire. In their way it sounds
> like your Swift services is ill and that is where the problem lies.
>
> Cheers
>
> Dave
>
>
>
> On Thu, Mar 27, 2014 at 3:30 PM, Sebastian <sebas5384 at gmail.com> wrote:
>
>> Yes! thats right, there's something not working.
>>
>> I tried to upload a file to a container through the havana dashboard and
>> I get this error: "UnicodeDecodeError at
>> /project/containers/[container-name]/upload".
>> Here are the logs of apache: http://pastebin.com/7iaf3tHg
>>
>> Thank for the help! I know this seems to be non a juju issue
>>
>>
>> 2014-03-26 20:05 GMT-03:00 Gustavo Niemeyer <
>> gustavo.niemeyer at canonical.com>:
>>
>> There's probably something else not quite okay with that deployment.
>>> Note that apparently all the interactions fail with several minutes of
>>> delay, until apache sends the 408. Some of these operations are GET
>>> requests, for files that tend to be very small. For example, one of
>>> the timeouts was from:
>>>
>>> 2014-03-26 18:52:13 ERROR juju.cmd supercommand.go:300 failed to GET
>>> object provider-state from container juju-dist
>>>
>>> How was the event reported in the logs of Apache and Swift?
>>>
>>>
>>>
>>> On Wed, Mar 26, 2014 at 7:24 PM, Sebastian <sebas5384 at gmail.com> wrote:
>>> > Yes!! it seems that the apache is giving the time out, for too long
>>> uploads.
>>> >
>>> > Maybe apache tweeks to increase time out?
>>> >
>>> > thank you people! :)
>>> >
>>> > Abs,
>>> > Sebas.
>>> >
>>> >
>>> >
>>> > 2014-03-26 18:54 GMT-03:00 Gustavo Niemeyer
>>> > <gustavo.niemeyer at canonical.com>:
>>> >>
>>> >> The response was cut out:
>>> >>
>>> >> > It's worth noting the timing between the first and the second
>>> entries
>>> >> > in the log above. It's taking quite a while for apache to respond
>>> with
>>> >> > the 408 timeout, which might indicate that the
>>> >>
>>> >> ... swift in the backend isn't communicating properly for some reason.
>>> >>
>>> >>
>>> >> gustavo @ http://niemeyer.net
>>> >>
>>> >> --
>>> >> Juju mailing list
>>> >> Juju at lists.ubuntu.com
>>> >> Modify settings or unsubscribe at:
>>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> gustavo @ http://niemeyer.net
>>>
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140327/a887ee8e/attachment.html>