Some days later, of trying a lot of things, I simple can't go further anymore, but! for records, here's what I tried, in a dedicated machine with 64GB of ram and 4/8 cores:
- Installed *Openstack* using devstack, with the apache services enabled, like swift. - Installed *nova-compute-lxc* as default hypervisor (also tried the *docker* driver). And the instances where working fine, after some tweeks and a lot of effort I make it worked. - Installed in my local pc, Juju with an openstack environment credentials configured. - sshuttle installed to make the lxc containers private ips, like 10.0.0.2 available to the Juju. (oh! and qemu as weel, i was desperate) When I bootstrap, its all going well till the juju wants to upload the juju tools to the swift, gives me a time-out error, and all the other things I reported in this thread. The thing is, that I want to have remote linux containers as machines for my juju orchestrated apps, through Openstack, making a tenant for every project we have in our company. And all this project is going to be case of success to show to our clients how Juju, Maas and Openstack can change how companies manage their private and public clouds. Please, I'm asking for some kindly help! I really can't believe that you must have 13 machines to deploy Openstack successfully to work with Juju. Thanks in advance! :) Abs, Sebas. 2014-03-28 5:08 GMT-03:00 Sebastian <sebas5...@gmail.com>: > 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 <j...@ubuntu.com>: > > 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 <sebas5...@gmail.com >> > <mailto:sebas5...@gmail.com>>: >> > >> > 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 <hui.xi...@canonical.com >> > <mailto:hui.xi...@canonical.com>>: >> > >> > 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 <sebas5...@gmail.com >> > <mailto:sebas5...@gmail.com>> 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 >> > <david.che...@canonical.com >> > <mailto:david.che...@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 >> > <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 >> > <sebas5...@gmail.com <mailto:sebas5...@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.nieme...@canonical.com >> > <mailto:gustavo.nieme...@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 >> > <sebas5...@gmail.com >> > <mailto:sebas5...@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.nieme...@canonical.com >> > <mailto:gustavo.nieme...@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@lists.ubuntu.com >> > <mailto:Juju@lists.ubuntu.com> >> > >> Modify settings or unsubscribe at: >> > >> >> https://lists.ubuntu.com/mailman/listinfo/juju >> > > >> > > >> > >> > >> > >> > -- >> > gustavo @ http://niemeyer.net >> > >> > >> > >> > -- >> > Juju mailing list >> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com >> > >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> > >> > >> > >> > >> > -- >> > Juju mailing list >> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> > >> > >> > >> > >> > >> > >> >> -- >> José Antonio Rey >> > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
