[00:00] <lazyPower> Docker is a software delivery mechanism. You're effectively creating (arguably...) an immutable container image that you run in production with everything pre-configured. This is just the deployment phase. Nothing in docker-core tells it how to connect to complimentary/required services. Given teh mediawiki example - docker by itself has no notion of a mysql db, now to create credentials in mysql, or how to get that information back to the running
[00:00] <lazyPower>  docker container. Juju is an orchestration language that can wrap these components and provide that information/expertise to any service that understands how the declarative relationship model works.
[00:00] <lazyPower> sebas5384: thats preaching to the choir - but we're prototyping around it.
[00:00] <lazyPower> and you may see some interesting things emerge out of virtual services which will be discussed at our upcoming sprint in malta.
[00:01] <sebas5384> ooh great
[00:01] <sebas5384> lazyPower: so there is some work to get docker as a provider ?
[00:02] <lazyPower> sebas5384: eh, 'as a provider' is a bit of a stretch
[00:02] <sebas5384> just specified the docker daemon info
[00:02] <lazyPower> keep your eyes peeled for mention of virtual services and once the spec is finalized someone may be able to shed more light about it.
[00:02] <lazyPower> sebas5384: also that blog post is coming this week - i have a hard cut off date to do a writeup over my docker charm work.
[00:03] <sebas5384> lazyPower: yeah, well using juju as a complete workflow tool for devops
[00:04] <sebas5384> is not going to happen till we have something more fast like docker to spin up the services, and sharing changes
[00:06] <sebas5384> I don't know how to explained better, but I would like to see juju as my only tool for deploying and orchestrating my services
[00:06] <lazyPower> sebas5384: everyone has different requirements, and building a tool that wraps everybody's workflow as it stands today (with changes to core) is going to be slow going
[00:07] <sebas5384> lazyPower: yeah thats my fear
[00:07] <lazyPower> this is why virtual services is a compelling option - so dont abandon hope yet
[00:07] <lazyPower> and dont let end users mistake juju for just a "deploymetn" solution. we're doing lifecycle management in charms and scaling - which is more than just "deployment"
[00:08] <sebas5384> lazyPower: I really hope that juju uses docker as a provider and protocol to upgrade and deploy their services
[00:08] <lazyPower> sebas5384: i just stopped in to check on offlines for the OCP demo - i'm goign to bounce out and finish my swap day. If you have any pressing questions about that feel free to hit up the list and i'll do my best to get back to you shortly :)
[00:09] <sebas5384> lazyPower: sure! thanks :)
[00:10] <sebas5384> lazyPower: i'll be waiting that article about the future of juju and docker o/
[06:47] <jobot> @lazyPower hello
[06:48] <lazyPower> jobot: hi
[06:48] <jobot> oh hi, I had discussed a charm with you on the e-mail list earlier, and was wondering if you had any time to discuss it
[06:49] <jobot> it was a suitecrm charm. I had trouble getting the database info to automatically populate during installation
[08:33] <Muntaner> good morning to everyone!
[08:34] <Muntaner> I'm trying to use the load balancer charm HAProxy for my charm. I set up everything, but when I try to access to the public IP of the load balancer, I get a 503 Service Unavailable. How can I diagnose my situation?
[08:42] <Muntaner> more info: if I try to connect directly to the units of my charm, the connection hangs
[08:44] <lazyPower> jobot: hey sorry about the *extended* delay in reply
[08:44] <lazyPower> jobot: i'm firefighting for a demo atm - I'd be happy to pick this up tomorrow?
[09:05] <turicasto> hi to all! o/
[09:07] <turicasto> guys I have some problem with haproxy .. can someone help me?
[09:37] <Muntaner> marcoceppi, ping
[10:31] <bloodearnest> bradm, heya, seems we are fixing the same issue in rabbit
[10:31] <bloodearnest> me: https://code.launchpad.net/~bloodearnest/charms/trusty/rabbitmq-server/add-nagios-service-groups/+merge/251790
[10:31] <bloodearnest> you: https://code.launchpad.net/~brad-marshall/charms/trusty/rabbitmq-server/nagios-fixes-sync-charmhelpers/+merge/251551
[10:32] <bloodearnest> bradm, are you gonna be working on it soon?
[10:34] <bloodearnest> hmm, I have a simple apache2 charm-helpers sync MP: https://code.launchpad.net/~bloodearnest/charms/trusty/apache2/update-charm-helpers/+merge/252331
[10:34] <bloodearnest> can I trigger an automated test run for it?
[10:36] <Muntaner> can anybody help me with HAProxy? I totally dunno what to do
[11:00] <gnuoy> Muntaner, what's the problem
[11:00] <gnuoy> ?
[11:00] <Muntaner> hi gnuoy
[11:00] <Muntaner> I'm trying to use HAproxy to introduce load-balancing to my charm
[11:01] <Muntaner> I'm following the wordpress charm code
[11:01] <Muntaner> but can't get my HAproxy to work, since I get a 503 error
[11:01] <Muntaner> and can't find useful logs
[11:04] <Muntaner> gnuoy, need more infos?
[11:04] <gnuoy> Muntaner, what does /etc/haproxy/haproxy.cfg have in it ?
[11:04] <Muntaner> gnuoy, paste incoming
[11:05] <Muntaner> gnuoy, http://paste.ubuntu.com/10573891/
[11:07] <gnuoy> Muntaner, on the haproxy node what does "nc -zvw2 10.0.0.7 8080" return ?
[11:10] <Muntaner> gnuoy, just a sec
[11:17] <gnuoy> Muntaner, fwiw the haproxy monitoring page is really useful to see the status
[11:17] <Muntaner> gnuoy, I get  port 8080 (tcp) timed out: Operation now in progress
[11:18] <Muntaner> gnuoy, how can I reach it
[11:18] <Muntaner> ?
[11:18] <gnuoy> Muntaner, so it sounds like it is not a problem with haproxy. whatever you have attached to the haproxy is not serving content on 8080
[11:20] <Muntaner> gnuoy, that's the motivation of the 503 error?
[11:21] <gnuoy> Muntaner, yes, haproxy is saying none of its backends are available
[11:21] <Muntaner> mh fine, my server is running on the 80 in fact gnuoy
[11:22] <Muntaner> how can I set the correct backend?
[11:27] <gnuoy> Muntaner, when your charm joins with haproxy I think it should set a port if I remember correctly
[11:27] <gnuoy> Muntaner, the haproxy charm has a README with the details
[11:28] <gnuoy> Muntaner, yes, the README shows what to do in the "1. Single-Service Proxying" section
[11:31] <Muntaner> gnuoy, thanks
[11:31] <Muntaner> looking about it
[11:37] <Murali> Hi Jamespage
[11:40] <Muntaner> gnuoy, seems to work now, thanks! how can I test my configuration to check if HAproxy is correctly working?
[11:41] <Anz> While trying to deploy the openstack bundle @ https://jujucharms.com/openstack/29  , I am getting the following error http://paste.ubuntu.com/10574023/
[11:41] <gnuoy> Muntaner, look at port 8080 on your haproxy node, it has a status page
[11:42] <Anz> I had earlier deployed this succesfully in the very same MAAS environment before
[11:42] <Muntaner> gnuoy, I have nothing at 192.168.0.97:8080
[11:43] <gnuoy> Muntaner, sorry, I meant port 10000
[11:44] <Muntaner> gnuoy, I get a 403 Forbidden
[11:44] <Muntaner> I need to put a password, I guess
[11:44] <gnuoy> Muntaner, look at haproxy.cfg it has the credentials in it
[11:45] <Anz> Can someone please tell me what the issue is ?
[11:45] <Muntaner> gnuoy, how should I give the password to haproxy?
[11:50] <Anz> 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement mysql to lxc:juju-gui=0 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement rabbitmq-server to lxc:juju-gui=0 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement ceph-osd to juju-gui=0 2015-03-10 17:18:16 [ERROR] deployer.deploy: Invalid service placement neutron-gateway to juju-gui=0
[11:52] <philip_stoev> marcoceppi: I have the Galera Cluster charm in my own LP directory. What is the procedure to make it a reviewed/Featured charm?
[11:52] <philip_stoev> Should I start by filing a ticket at https://bugs.launchpad.net/charms/+filebug? If yes, then what title/tags should I give it?
[12:01] <Muntaner> gnuoy, seems working
[12:01] <Muntaner> gnuoy, my HAproxy is at 192.168.0.97. When I go on this url, it auto-redirects me to 192.168.0.93: is this the expected behaviour?
[12:02] <Muntaner> (92 and 93 are the units of my web service)
[12:03] <gnuoy> Muntaner, That is not expected and I don't think it's haproxy doing the redirect. It'll be the web service
[12:03] <Muntaner> gnuoy, so I should use the web service remaining on the proxy IP?
[13:04] <Anz> Hi Jamespage
[14:07] <mwak> heya
[14:48] <Muntaner> hi guys
[14:48] <Muntaner> I have a problem with nova security groups and juju
[14:48] <Muntaner> I have 100 security groups available in my project
[14:48] <Muntaner> but Juju only uses 10 of them and then gives me errors if I try to launch new VMs
[14:56] <Muntaner> any suggestions?
[15:11] <mbruzek> Muntaner: that is a question for the OpenStack charmers like jamespage coreycb or beisner
[15:11] <jamespage> Muntaner, check your security group rule quota
[15:12] <Muntaner> jamespage, it is 100
[15:12] <Muntaner> jamespage, you mean in nova?
[15:12] <jamespage> Muntaner, well that depends
[15:12] <jamespage> Muntaner, are you using neutron security or nova security?
[15:13] <jamespage> Muntaner, also security groups and security group rules are separate quota items in neutron
[15:13] <Muntaner> jamespage, nova security
[15:13] <jamespage> Muntaner, same applies in nova
[15:17] <beisner> may also be worth noting bug 1335885 if doing repetitive deploys (there's a potential for quota consumption there)
[15:17] <mup> Bug #1335885: destroy-environment reports WARNING cannot delete security group <cloud-installer> <destroy-environment> <landscape> <openstack-provider> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1335885>
[15:43] <jobot> 　lazyPower: np, yeah I went to sleep. Try to catch you later today.
[15:44] <whit> to hell with vendoring charmhelpers... when do we get resource streams?
[16:15] <Muntaner> hey jujuers
[16:15] <Muntaner> I need to set which user the mysql charm is gonna use
[16:15] <Muntaner> because I need it to be shared between many charms
[16:15] <Muntaner> can I do that?
[16:30] <DrewT> I've run into an issue when using the openstack-installer (and landscape) where the Ceph charm is trying to use the various removable media devices on the boxes as block storage
[16:30] <DrewT> I have submitted bug: https://bugs.launchpad.net/charms/+source/ceph/+bug/1420094
[16:31] <mup> Bug #1420094: Ceph install fails by using removable devices <cloud-install-failure> <cloud-installer> <landscape> <ceph (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1420094>
[16:31] <DrewT> but, is there any way I can force the ceph charm to only use a specific block device and ignore everything else?
[16:58]  * lamont is doing battle with juju-local and losing: chown: invalid user: ‘ubuntu:ubuntu’
[16:59] <lamont> anyone wanna help a juju-local noob?
[17:03] <lamont> (anyone happen to have a working type:local juju/environments.yaml snippet they can share?
[17:10] <marcoceppi> lamont: sure, what's up?
[17:11] <lamont> marcoceppi: tossed you a paste with what I'm seeing, and what I have.. clearly, it's not right.
[17:11] <lamont> clue would be appreciated
[17:13] <redelmann> hi, im having some troubles with juju 1.22-beta4
[17:13] <marcoceppi> lamont: that's weird
[17:13] <redelmann> it was working fine
[17:13] <lamont> marcoceppi: verily
[17:14] <marcoceppi> redelmann: what are you seeing?
[17:14] <redelmann> now it always say: cannot read info: lock timeout exceeded
[17:14] <marcoceppi> lamont: can you boostrap with --debug and -v flags?
[17:14] <redelmann> from one moment to another
[17:14] <marcoceppi> redelmann: when trying to do?
[17:14] <lamont> ah, that might be better than the strace -ff output I just created
[17:14] <redelmann> i already try
[17:15] <redelmann> 2015-03-10 17:14:49 INFO juju.cmd supercommand.go:37 running juju [1.22-beta4-trusty-amd64 gc]
[17:15] <lamont> marcoceppi: would it be signifcant to say that I'm running vivid?
[17:15] <redelmann> 2015-03-10 17:14:49 INFO juju.utils.fslock fslock.go:146 attempted lock failed "env.lock", reading, currently held: reading
[17:15] <redelmann> 2015-03-10 17:14:50 ERROR juju.cmd supercommand.go:411 there was an issue examining the environment: cannot read info: lock timeout exceeded
[17:15] <marcoceppi> lamont: maybe, but it's good to know
[17:15] <redelmann> im using lxc on local machine
[17:15] <marcoceppi> redelmann: for future multiline pastes it'd be useful to use http://paste.ubuntu.com
[17:16] <redelmann> marcoceppi: ok, sorry
[17:16] <marcoceppi> redelmann: there's an issue trying to get a lock on your environment. Is this when trying to bootstrap?
[17:17] <redelmann> marcoceppi: http://paste.ubuntu.com/10575661/
[17:17] <lamont> http://people.canonical.com/~lamont/bootstrap.debug <-- marcoceppi
[17:17] <redelmann> marcoceppi: no, i was working without any trouble, after deploy one ganglia instance it start to faild
[17:18] <redelmann> marcoceppi: after that i couldn't do anything
[17:18] <marcoceppi> redelmann: can you run the following: `sudo apt-get install pastebinit; sudo initctl list | grep juju | pastebinit`
[17:19] <redelmann> http://paste.ubuntu.com/10575679/
[17:19] <marcoceppi> lamont: can you (after cleaning up the file) paste ~/.juju/environments/local.jenv ?
[17:19] <marcoceppi> redelmann: you already have an environment running, running a bootstrap will fail. Can you run `juju status` ?
[17:20] <lamont> "~/.juju/environments/local.jenv" [New File]                                                                                                                                                                0,0-1         All
[17:20] <marcoceppi> damn, I thought that was going to be it
[17:21] <redelmann> marcoceppi: http://paste.ubuntu.com/10575695/
[17:21] <lamont> http://paste.ubuntu.com/10575698/ <-- marcoceppi the actual and for true environments.yaml stanza, albeit redacted
[17:22] <marcoceppi> redelmann: did you upgrade your juju client recently after bootstrapping that environment?
[17:22] <marcoceppi> lamont: you can omit the authorized-keys-path, it's redundant as ~/.ssh/id_rsa.pub will be uploaded as part of Juju's logic
[17:22] <redelmann> marcoceppi: no, i was just testing some local charms
[17:22] <marcoceppi> mine is just type: local and admin-secret
[17:22] <marcoceppi> redelmann: what does `juju version` produce?
[17:23] <redelmann> marcoceppi: 1.22-beta4-trusty-amd64
[17:24] <redelmann> marcoceppi: i cant destroy enviroment too.
[17:24] <marcoceppi> redelmann: can you try `juju destroy-environment -y --force local` ?
[17:24] <redelmann> marcoceppi: running with --force: ERROR cannot read environment info for "local": cannot read info: lock timeout exceeded
[17:25] <marcoceppi> redelmann: well, we can clean it up manually, this is highly irregular
[17:25] <redelmann> marcoceppi: sound like mongodb problem?
[17:25] <marcoceppi> redelmann: possibly, lets see if this helps it recover
[17:25] <marcoceppi> redelmann: try `sudo restart juju-db-redelmann-local; sudo restart juju-agent-redelmann-local`
[17:25]  * lamont decides to confirm that openstack environments bootstrap, since this is a reinstalled box, after all
[17:25] <lamont> juju bootstrap -e openvpn
[17:25] <lamont> Launching instance
[17:25] <lamont> seems to be
[17:26] <marcoceppi> lamont: yeah, it's just with your local, and it's trying to chown ubuntu when there's really no need
[17:26] <redelmann> marcoceppi: same problem, unable to connect to enviroment "local"
[17:27] <marcoceppi> redelmann: okay, so manual clean up it is. If you want to "destroy" local do the following:
[17:27] <redelmann> marcoceppi: ok, im "listening"
[17:27]  * marcoceppi is typing
[17:28] <marcoceppi> actually, just run this
[17:28] <marcoceppi> https://github.com/juju/plugins/blob/master/juju-clean
[17:28] <redelmann> marcoceppi: this is the second time it happend to me, the first time I thought it was a change of ip
[17:30] <redelmann> marcoceppi: im connecting eth0 with lxcbr0, and sometimes dhcp gives me a different ip for lxcbr0
[17:31] <marcoceppi> interesting, that shouldn't cause an issue since technically bootstrap node is on localhost
[17:31] <marcoceppi> but it might be actually
[17:32] <lamont> marcoceppi: is there a good way to make it stop trying to do that?
[17:32] <marcoceppi> lamont: I haven't the slightest, this is a first for me
[17:34] <redelmann> marcoceppi: one last quesion: is necessary to run "--upload-tools" in bootstrap?
[17:38] <redelmann> marcoceppi: http://paste.ubuntu.com/10575811/
[17:38] <redelmann> marcoceppi: Still same problem after clean
[17:38] <redelmann> marcoceppi: maybe deleting .juju/enviroments/local.jenv
[17:39] <redelmann> marcoceppi: i solved it
[17:39] <marcoceppi> what was it?
[17:40] <redelmann> marcoceppi: env.lock direcory inside enviromens
[17:41] <redelmann> marcoceppi: http://paste.ubuntu.com/10575825/
[17:41] <marcoceppi> interesting
[17:41] <redelmann> marcoceppi: think i destroy my enviroment for nothing :P
[17:41] <marcoceppi> env.lock is a new direcetory
[17:42] <marcoceppi> I'll add it to the juju-clean script
[17:42] <redelmann> marcoceppi: Ok, after that i needed to run juju-clean again
[17:57] <redelmann> marcoceppi: thank for the help
[18:13] <lamont> marcoceppi: at what point should I see juju fire up a jujud on my machine?  (I don't have one)
[18:15] <marcoceppi> lamont: there's a line in the local output that says something to the effect of "starting agent"
[18:15] <hazmat> lamont: basically it should be there as soon as cloud init finishes, if not you should check the cloud-init-output.log in /var/log/
[18:15] <hazmat> assuming this isn't the bootstrap node
[18:16] <hazmat> if it is the bootstrap node.. bootstrap with --debug and you'll see the ssh interaction
[18:18] <lamont> sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges? <-- I wonder if that's relevant
[18:18] <lamont> oh haha.  strace
[18:25] <lamont> hazmat: http://paste.ubuntu.com/10576054/ hazmat: what I see is it getting completely lost looking for tools, and then things get weird
[18:26] <hazmat> lamont: ic. that just looks a  juju bug with vivid, it looks like default user ubuntu isn't in that cloud image
[18:27] <lamont> hazmat: can I trivially force it to only use trusty? or does lxc mean that it must use vivid?
[18:28] <lamont> I just want it to bootstrap, man.  well, and then do a bunch of deploys, I guess
[18:28] <hazmat> lamont: so try just adding an ubuntu:ubuntu user on the host,
[18:29] <lamont> does that user need privileges?
[18:29] <hazmat> lamont: so your host is vivid? .. it looks like its trying to bootstrap on the host and assuming the 'ubuntu' user is there
[18:29] <hazmat> lamont: probably .. password less sudo
[18:29] <lamont> host is vivid, ubuntu user never has been there
[18:29] <hazmat> yeah.. that's just broken/buggy imo
[18:29] <hazmat> shouldn't assume that for local provider
[18:30] <hazmat> once you get it working you can use any series, normally series gets picked up from the charm unless your doing add-machine in which case you can pass it explicitly
[18:31] <lamont> http://paste.ubuntu.com/10576080/ <-- I suppose that constitutes "progress"
[18:31]  * hazmat would stalk some juju devs
[18:33] <hazmat> lamont: i just pinged folks on #juju-dev hopefully somebody turns up
[18:33] <lamont> ta
[18:33] <lamont> fwiw, no mongo processes running, though juju-mongodb has been installed
[18:34] <jrwren> lamont: its an upstart not found message, could this related to yesterday's move to systemd?
[18:34] <lamont> jrwren: quite possibly
[18:34] <ericsnow> lamont: juju on vivid has been working fine for a while, but vivid is about to (or just did) switch to booting with systemd
[18:34] <lamont> ericsnow: 2015-03-09 (yesterday)
[18:35] <lamont> if this is a known thing that'll be fixed for vivid sometime soon, I'll just keep using openstack for testing
[18:35] <ericsnow> lamont: we are wrapping up adding support for systemd in the next juju release (1.23)
[18:36] <ericsnow> lamont: also, there's a know issue where a vivid container (running systemd) won't work on a non-vivid host (trusty and utopic can be made to work though)
[18:37] <ericsnow> s/know/known
[18:37] <lamont> ericsnow: does that make the workaround for the meantime "use an utopic schroot"?
[18:37]  * lamont actually wants trusty containers
[18:37] <lamont> maybe I'll just use a trusty box, instead of my vivid box
[18:38] <lamont> sometimes, bleeding edge sucks
[18:40] <ericsnow> lamont: trusty works if you've updated a few packages out of "trusty-updates"
[18:40] <ericsnow> lamont: see https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1347020
[18:40] <mup> Bug #1347020: systemd does not boot in a container <systemd-boot> <lxc (Ubuntu):Fix Released by stgraber> <lxc (Ubuntu Trusty):Triaged by stgraber> <https://launchpad.net/bugs/1347020>
[18:41] <ericsnow> lamont: for testing I've been running local provider in a vivid KVM
[18:41] <lamont> ericsnow: ah, that has potential
[18:42] <lamont> ericsnow: meaning your "juju-local on vivid" test box is a kvm?
[18:42] <ericsnow> lamont: anyway, I'm hoping to land the last patch for systemd-on-vivid support in a little bit
[18:43] <ericsnow> lamont: yep
[18:43] <ericsnow> lamont: but most of my testing has been limited to just bootstrapping
[18:48] <lamont> ericsnow: I would be most interested in being a tester for you.
[18:49] <lamont> but first, lunchtime
[21:44] <fraterlaetus> hi
[21:44] <fraterlaetus> I just set up a private cloud using canonical/landscape/openstack
[21:44] <fraterlaetus> as part of it, it created me a juju endpoint.
[21:45] <fraterlaetus> How do I: A: get credentials for the juju endpoint; B: start playing?
[21:45] <fraterlaetus> ELI5 please?
[21:56] <fraterlaetus> Does anyone know how to create credentials for juju in openstack?
[22:19] <fraterlaetus> ^^ ?
[23:02] <jobot> lazyPower: hello, how's it going?
[23:46] <fraterlaetus> :(