Yes! I already try it, but only mysql worked, so Im trying again hehe What would be the best version of ubuntu to be the this big host? the machine haves 4/8 processors, 64G of RAM, 2T of space, so I think is ok, right?
Abs, Sebas. 2014-03-28 4:58 GMT-03:00 José Antonio Rey <[email protected]>: > When deploying Juju charms, you can execute this to put everything on > the bootstrap machine: > > juju deploy --to 0 [charmname] > > Just prefix the name of the charm you're deploying with "--to 0" > (without quotes) and it will deploy it to machine 0, which is the > bootstrap machine. > > The environment, of course, has to be already bootstrapped. Make sure > the machine will have enough resources to run smoothly. > > On 03/28/2014 02:56 AM, Sebastian wrote: > > There is someway I can deploy openstack using Juju all-in-one-machine ? > > I tried once and only mysql go green, maybe is not good to the juju > > agent being installed in the same machine of the openstack. > > > > Thanks! > > > > Abs, > > Sebas. > > > > > > > > 2014-03-28 1:57 GMT-03:00 Sebastian <[email protected] > > <mailto:[email protected]>>: > > > > Hui yes swift is working!, actually, I did an upload using the swift > > command, and even appeared in the havana dashboard. > > > > The problem seems to be in the proxy-server i think. > > > > thanks!! > > > > Abs, > > Sebas. > > > > > > > > 2014-03-28 1:37 GMT-03:00 Hui Xiang <[email protected] > > <mailto:[email protected]>>: > > > > Hey Sebas, > > > > Can you use the command of "swift list"? > > At lease now I have the swift result as below, check yours, > > and you can move on and help each other . > > > > ubuntu@havana:~$ swift list > > 2ae43fe4-eb72-4402-9c5c-4a42749cfee3 > > dfc9e845-2d67-4be4-892a-648a7a13e881 > > > > Regards. > > Hui > > > > > > > > On Fri, Mar 28, 2014 at 9:05 AM, Sebastian <[email protected] > > <mailto:[email protected]>> wrote: > > > > 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 > > <[email protected] > > <mailto:[email protected]>>: > > > > 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 > > <tel: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 > > <[email protected] <mailto:[email protected]>> > 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 > > <[email protected] > > <mailto:[email protected]>>: > > > > 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 > > <[email protected] > > <mailto:[email protected]>> 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 > > > <[email protected] > > <mailto:[email protected]>>: > > >> > > >> 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 > > >> [email protected] > > <mailto:[email protected]> > > >> Modify settings or unsubscribe at: > > >> > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > > > > > > > > > > -- > > gustavo @ http://niemeyer.net > > > > > > > > -- > > Juju mailing list > > [email protected] <mailto:[email protected]> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > > > > > > -- > > Juju mailing list > > [email protected] <mailto:[email protected]> > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/juju > > > > > > > > > > > > > > -- > José Antonio Rey >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
