[00:59] <lp|sprint> jose: there's a lot of variables there - i would take notes for our wednesday call
[01:00] <jose> ack
[01:00] <lp|sprint> jose: thing is, we may or may not have a good answer there. we run into the same papercuts
[01:00] <jose> that's fine
[09:35] <apuimedo> gnuoy: ping
[09:35] <gnuoy> apuimedo, hi
[09:35] <apuimedo> Hi
[09:36] <apuimedo> gnuoy: I'm getting some errors running tests on charm-helpers
[09:36] <apuimedo> File "/home/celebdor/code/midonet-charms/mem-manager/.venv2/lib/python2.7/site-packages/charmhelpers/core/services/helpers.py", line 157, in __init__
[09:36] <apuimedo>     super(HttpRelation).__init__(self, *args, **kwargs)
[09:36] <apuimedo> TypeError: must be type, not HttpRelation
[09:37] <apuimedo> that super statement does not look py2 nor py3 compliant to me
[09:38] <gnuoy> apuimedo, it looks ok to me, I haven't been having problems running the unit tests. let me retry
[09:39] <apuimedo> the old one used to be:
[09:39] <apuimedo> super(Child, self).__init__(*args, **kwargs)
[09:39] <apuimedo> the new one is supposed to be
[09:40] <apuimedo> super().__init__(*args, **kwargs)
[09:41] <gnuoy> apuimedo, lp:charm-helper tests are passing cleanly for me
[09:41] <apuimedo> mmm
[09:41] <apuimedo> python2, 3 or both?
[09:42] <gnuoy> apuimedo, running the test makefile target which runs both
[09:42] <apuimedo> in any case, shouldn't it be: super(MysqlRelation).__init__(self, *args, **kwargs)
[09:42] <apuimedo> if it's the MysqlRelation class?
[09:44] <gnuoy> apuimedo, I have no idea what is in you charmhelpers/core/services/helpers.py given it seems to be different from trunk so it's hard to say
[09:44] <gnuoy> * your
[09:45] <apuimedo> gnuoy: it's retrieved with pip
[09:45] <apuimedo> automatically with my Makefile
[09:46] <gnuoy> apuimedo, it seems not to be trunk as trunk tests are passing
[09:47] <apuimedo> gnuoy: check out the version of pypi
[09:47] <gnuoy> apuimedo, are you on revno 341 /
[09:47] <gnuoy> ?
[09:47] <apuimedo> (after all, it's what's being pulled with the default charm setup.py
[09:48] <apuimedo> it was 322
[09:48] <gnuoy> so that seems old
[09:48] <gnuoy> apuimedo, I think we may be on cross-purposes somehow
[09:48] <apuimedo> yes, probably a new pypi release should be done
[09:49] <apuimedo> gnuoy: or it should be based on charm-helpers/stable
[09:50] <apuimedo> note it was updated on 17th of this month
[09:51] <gnuoy> apuimedo, for the openstack charms the charmhelpers dir is populated by branching directly from  lp:charm-helpers into the hooks directly
[09:52] <gnuoy> s/ hooks directly/hooks directory/
[09:52] <apuimedo> I know. My concern is that when you do `charm create` and it pregenerates some setup.py that goes to pip for getting the helpers
[09:52] <apuimedo> it will get 0.2.3 currently
[09:52] <apuimedo> which has this issue
[09:53] <apuimedo> so. Should I expect a fix on the pypi version or should I branch stable in my repo?
[09:53] <gnuoy> apuimedo, ok, that makes sense, I thought your were trying to land a change to charm helpers
[09:54] <apuimedo> gnuoy: no. Just alerting of a problem in the distributed version
[09:54] <apuimedo> sorry if I was not clear enough
[09:55] <gnuoy> apuimedo, no problem at all, thank you for reporting the issue.
[09:55] <apuimedo> gnuoy: you're welcome
[09:56] <apuimedo> gnuoy: so I guess it's better that I pin the stable version on my tree
[09:56] <apuimedo> for now
[09:57] <gnuoy> apuimedo, I would follow the same path as the other openstack charms. create a charm-helpers-hooks.yaml pointing at lp:charm-helpers , list the modules you need and create a sync make file target
[09:57] <apuimedo> ok ;-)
[10:08] <apuimedo> good. It worked fine with the pinning
[11:16] <schkovich> rick_h_: done. https://github.com/juju/docs/pull/311
[14:25] <Muntaner> hello guys
[14:26] <Muntaner> can I run juju over a net that does not have internet connection?
[14:26] <Muntaner> cos I need juju to deploy some basic services without internet access
[14:26] <Muntaner> in some subnets
[14:31] <jrwren> Muntaner: yes and to do so  you will need your own simplestreams services.
[14:31] <Muntaner> jrwren, I already have them
[14:32] <Muntaner> jrwren, the problem is that I can't give the floating IPs to those machines
[14:32] <Muntaner> since they don't have a direct internet access
[14:32] <Muntaner> (it is a private openstack cloud)
[14:33] <Muntaner> jrwren, so, I can't connect to the machines, and can't even bootstrap
[14:35] <jrwren> Muntaner: I don't know.
[14:36] <jrwren> Muntaner: ignoring juju, if you start a nova instance do you have connectivity to it? You'll need that.
[14:36] <Muntaner> jrwren, yes, but the VM does not have access to the intetnet
[14:53] <gnuoy> jamespage, If you have a sec could you take a look at the two tiny mps associated with Bug 1435902 pls?
[14:53] <jrwren> Muntaner: internet is irrelevant. connectivity from where you are running juju to the openstack environment is important.
[14:53] <mup> Bug #1435902: services error deploying to next due to bad mtu setting <quantum-gateway (Juju Charms Collection):New for gnuoy> <https://launchpad.net/bugs/1435902>
[14:55] <Muntaner> jrwren, since I'm launching the bootstrap on a subnet that has no internet access, if I don't use floating IPs I can't "talk" to the machines. So, the bootstrap hangs at "attempting to connect at ... "
[14:57] <jamespage> gnuoy, +1's
[14:57] <jrwren> Muntaner: I won't pretend to understand. Sorry :(
[14:57] <gnuoy> Muntaner, that machine that you're doing the juju deployment from is outside of the openstack cloud ?
[14:57] <gnuoy> jamespage, thanks
[14:57] <Muntaner> jrwren, don't worry, I know it's a "strange" configuration :)
[14:57] <Muntaner> gnuoy, maybe I can explain it better with an image
[14:58] <Muntaner> gnuoy, http://i59.tinypic.com/2jevkwp.png
[14:59] <Muntaner> I'm trying to bootstrap juju on the purple subnet
[14:59] <Muntaner> now I'm giving to that subnet internet access via the router... but in a normal use, I don't want to do that
[15:08] <mrhatch_> can anyone answer a few questions about juju and maas?
[15:14] <mrhatch_> We are looking at juju and maas to solve cm problems in a physical environment.  My big question is do I have to dedicate a machine to manage juju for every environment I want to deploy
[15:15] <mrhatch_> for instance we have a project that uses tomcat and mysql on a single machine and another that uses apache, django and mysql on two machines
[15:16] <mrhatch_> I realize that I may have to write the charms to deploy those services in that configuration, but do I need a server dedicated to managing each of those?
[15:16] <mrhatch_> and would I need yet another set of servers to manage the test and development servers?
[15:17] <schkovich> if i am getting you correctly you would need to have a several environments and switch between those
[15:18] <schkovich> if you are by dedicated machine to manage juju referring to the machine on which juju client will reside
[15:18] <schkovich> im not sure about state servers
[15:19] <mrhatch_> yeah that is what I was wondering if I needed a dedicated machine for managing juju
[15:19] <mrhatch_> for each environment
[15:20] <schkovich> we have a several environments and each environment has it's own juju state server
[15:21] <schkovich> but again in our case it makes sense
[15:21] <schkovich> perhaps you could have several containers and in each container state server running and place all containers on a single physical server
[15:22] <schkovich> or several vms running on a single physical server
[15:23] <schkovich> but again someone more knowledgeable might have better answer :)
[15:27] <gnuoy> jamespage, thanks
[15:28] <mrhatch_> I am just getting started with all of this so I am not sure what the best way to go about it is.  The idea of having state servers running on vm's is an good suggestion, of course that means I would need a more robust maas environment to manage the different networks
[15:29] <mrhatch_> or possibly just use the second NIC in each server to manage them all from a single internal network
[15:29] <schkovich> true that
[15:30] <mrhatch_> at this point I am still playing with both maas and juju on some old laptops and virtual box vm's at home with a linksys router running the subnet
[15:30] <mrhatch_> still having DNS issues too
[15:31] <mrhatch_> maas team thinks they will be fixed if I upgrade to 1.7 which is my next task when I get back to the house
[15:31] <schkovich> im using both maas and juju in virtual environments
[15:31] <schkovich> can't help much with physical environments setup
[15:32] <mrhatch_> have you ever had problems with logging in to a server provisioned by maas?  Sometimes it seems like my keys aren't going across with the build even though they are in the maas gui
[15:32] <schkovich> nope
[15:32] <mrhatch_> I think I am going to write a blog post about the next trip through the setup...
[15:33] <schkovich> but i had similar problems when juju agent is not running or in odd state
[15:33] <mrhatch_> what version of maas are you running now?
[15:34] <mrhatch_> I haven't even installed juju on this go around yet
[17:37] <aisrael> Charmers, here's a list of reviews currently in the queue that need a charmer's attention: http://pastebin.ubuntu.com/10671316/
[17:43] <dpb1> Hi all -- how can I find out the JUJU_UNIT_NAME while doing 'juju run'?
[17:49] <jog> sinzui, No space left on device
[17:50] <sinzui> :(
[17:53] <marcoceppi_> dpb1: you should be able to `echo $JUJU_UNIT_NAME` when doing juju-run
[17:56] <dpb1> marcoceppi_: no dice. :(  nothing JUJU in the environment (I really thought I've used that before, but can't find anything documented).
[17:57] <marcoceppi_> dpb1: depending on what you're doing and how patcient you can be, juju actions are in 1.23-beta1 which gives you more structure around juju-run
[17:58] <rick_h_> dpb1: nothing $JUJU_ in there? That sounds broken. I could have sworn juju run ran in full hook context?
[17:59] <dpb1> rick_h_: same. :(   echo $JUJU_UNIT_NAME gives nothing, trying 'set, env, compgen -v', all show nothing 'JUJU_'
[18:02] <marcoceppi_> dpb1: are you doing juju run against the unit or the machine number?
[18:02] <dpb1> marcoceppi_: --all, let me try some variation
[18:02] <marcoceppi_> dpb1: ah, that might be it
[18:02] <marcoceppi_> dpb1: I know that juju run --machine will just use SSH, while --unit will do it as a hook context
[18:02] <marcoceppi_> all may be the same way as --machine
[18:02] <dpb1> w.t.h.
[18:03] <dpb1> :)
[18:03]  * dpb1 checks
[18:03] <dpb1> --service has the JUJU_ ones
[18:04] <dpb1> nice job marco
[18:04] <dpb1> marcoceppi_: now, I can confirm that ssh is not involved, but it certainly is different
[18:05] <dpb1> I can kinda see why juju run --machine does not run in a hook context
[18:05] <dpb1> I guess --all is shorthand for all machines, not all units
[18:05] <dpb1> --all  (= false)
[18:05] <dpb1>     run the commands on all the machines
[18:05] <dpb1> very interesting
[18:06] <dpb1> thx, that helps
[18:07] <marcoceppi_> dpb1: yeah, I'm going to raise a bug with core, it shouldn't be too hard to have --machine use the machine-agent like it does the unit-agent
[18:07] <marcoceppi_> but you still wouldn't get things like JUJU_UNIT_NAME since if you --to you'd have conflicting values
[18:07] <dpb1> marcoceppi_: yes, I can understand.  would be nice to have --service 'all' or something
[18:07] <marcoceppi_> yeah
[18:08] <dpb1> --unit all too
[18:08] <dpb1> I guess --all-units or similar
[18:08] <marcoceppi_> dpb1: yeah
[18:09] <dpb1> marcoceppi_: if you have that bug, let me know, I'll subscribe the appropriate people
[18:09] <dpb1> (when you have...)
[18:11] <marcoceppi_> dpb1: https://bugs.launchpad.net/juju-core/+bug/1435999
[18:11] <mup> Bug #1435999: juju run should have an --all-units option, --all is ambiguous and confusing <juju-core:New> <https://launchpad.net/bugs/1435999>
[18:12] <dpb1> marcoceppi_: danke
[18:39] <AskUbuntu> Update someone else's chrams in the juju charm store | http://askubuntu.com/q/600802
[19:13] <Guest51625> Juan Negron or Tom Haddon | May I ask one of you a quick question regarding Haproxy and SSL
[20:07] <aisrael> marcoceppi_: https://code.launchpad.net/~paulgear/charms/precise/nrpe-external-master/fix-duplicate-rsync-entries/+merge/250248
[20:27]  * web would greatly appreciate some insight about what I may be missing when trying to use SSL based node.js application with Haproxy.  I am using the following hooks ( http://paste.ubuntu.com/10672089/ ) and cant understand the error coming from the reverse server ( http://paste.ubuntu.com/10672447/ ).  GUI shot:  http://ibin.co/1vxjz6hLgSMJ
[20:29] <lp|sprint> jose: did you see? :)
[20:29] <jose> wat? wat?!
[20:30] <web> oops
[20:30] <web> sorry
[20:30] <jose> lp|sprint: what's going on?!
[20:30] <lp|sprint> jose: http://review.juju.solutions/ - look at those numbers
[20:31] <jose> lp|sprint: you. all. are. awesome.
[20:32] <lp|sprint> it was all aisrael, cory_fu, and marcoceppi_
[20:32] <jose> kudos to them, great job guys!
[20:32] <web> wow the review dash is nice and organized now and days
[20:32] <aisrael> ^5 guys
[20:33] <lp|sprint> web: yeah, we've been working on upping the ante on UX
[20:34] <jose> lp|sprint: you know that if you guys need me, I'm here to give you a hand
[20:34] <jose> so, any merges that have approve community and need charmer merging, please pass them on to me and I can take care of them
[20:35] <aisrael> jcastro: https://code.launchpad.net/~jorge/charms/trusty/kibana/update-defaults-to-4/+merge/250379
[20:37] <lp|sprint> web: i'm trying ot pull up your pastebins but it looks like our network is tanking here at the sprint :(
[20:41] <web> lp|sprint:  Thank you I appreciate it.  No rush I have a feeling I am off on my configuration parameters.  I also just notices a note about Haproxy on Tusky.  Gonna try a precise based charm for now.  I have set haproxy up plenty but never with SSL.
[20:42] <web> trusky
[20:42] <lp|sprint> IIRC ssl with haproxy was touchy with the charm atm. aisrael has some experience there i think.
[20:42] <web> It seems to be stuck in an infinite loop of some sort because the connection doen't timeout
[20:43] <aisrael> lp|sprint: that was rabbitmq. I haven't touched haproxy today
[20:43] <lp|sprint> aisrael: i was thinking back w/ the reddit bundle. weren't you working with haproxy as the reverse proxy server?
[20:44] <web> I sent Juan and Tom a message also since their the maintainers
[20:45] <aisrael> lp|sprint: yeah, that's been an issue wrt complex configurations, but I think a merge just landed that may help with that.
[21:14] <web> aisrael: Thanks for the heads up, there are a couple relating to ssl for merging.  https://code.launchpad.net/charms/trusty/+source/haproxy
[21:21] <mwenning> stokachu, openstack-install is basically a wrapper around juju-deployer, correct?
[21:21] <stokachu> mwenning: uh no
[21:21] <mwenning> ok.
[21:21] <mwenning> stokachu, elucidate please
[21:22] <stokachu> juju-deployer is only used with landscape autopilot as thats what they use to deploy
[21:22] <stokachu> otherwise is our own stuff
[21:23] <web> seems all the newest ssl merges were made.  Not sure if I caught the merge or not.  Cross fingers and tries again.
[21:24] <web> 6 hours is what I mean by just merged
[21:24] <mwenning> stokachu, thx.
[22:25] <AskUbuntu> SSL Node.js Charms with Haproxy | http://askubuntu.com/q/600880
[23:06]  * web having trouble.  Feels he is overlooking something. http://askubuntu.com/q/600880/88546
[23:07] <web> Isn't the room bot supposed to announce new questions???
[23:08] <aisrael> web: it did, about a half hour ago :)
[23:08] <web> okay must have timed out for a min