[09:46] <jester-> hi
[15:18] <m4v> [NikO]: is the games plugin supposed to be loaded in uBOTu-fr?
[15:32] <[NikO]> m4v: it was use on some channel
[15:32] <[NikO]> m4v: but it s easy to disable channel by channel
[15:33] <m4v> [NikO]: can you disable it for ubuntu-es? the users just discovered the roulette and I fear a kick flood will come ;)
[15:35] <m4v> [NikO]: thanks
[15:35] <[NikO]> you'r welcome
[15:37] <LjL> yay, roulette
[19:31] <ubot4> In #ubuntu-uk, DanielRM said: ! reality is over-rated
[20:01] <alefteris> LjL, remember that I had asked for some factoids for the greek loco channel, they are not working yet :(
[20:22] <Zenitur> Ну превед. И чего это я нарушил, интересно? Короче
[20:24] <Zenitur> One of operators of russian Ubuntu channel makes more that allowed in rules. He ban peoples that he doesn't like (for example me), they followed all of rules. He close his eyes on some rules, for example you can see not allowed bad words. Check the logs, please, and proove it. Thank you
[20:25] <Zenitur> P.S. Type !A4Tech in #ubuntu-ru if you need more information.
[20:27] <Zenitur> please, make he user and find other operator
[21:05] <LjL> alefteris: uhm, then ubot4 or whatever it is that you have doesn't *really* sync with ubottu's database.
[21:06] <LjL> alefteris: (people are writing in proper greek rather than greeklish in -gr?! what's happening, the sky is falling? :P)
[21:06] <jpds> 2 and 4 sync hourly.
[21:07] <LjL> jpds: they have 3
[21:07] <jpds> LjL: Sucks to be them.
[21:07] <LjL> i guess
[21:07] <jpds> ;-)
[21:13] <nalioth> ubot3 syncs hourly
[21:14] <nalioth> does ubottu have the factoid is the question
[21:18] <alefteris> LjL, ναι :)
[21:40] <popey> er
[21:40] <popey> suspect people alert
[21:40] <popey> 21:39:33 -!- arcstech<EMAIL_ADDRESS>has joined #ubuntu-uk
[21:40] <popey> 21:39:46 -!- dlctelc<EMAIL_ADDRESS>has joined #ubuntu-uk
[21:41] <popey> 21:39:56 -!- fwsmbukt<EMAIL_ADDRESS>has joined #ubuntu-uk
[21:41] <popey> 21:40:29 -!- bbtspeks<EMAIL_ADDRESS>has joined #ubuntu-uk
[21:41] <LjL> hummety hum
[21:42] <LjL> weird, none of them joinde #ubuntu, even though they joined #kubuntu or #ubuntu+1
[21:42] <Nafallo> -!- fwsmbukt<EMAIL_ADDRESS>has joined #ubuntu-se
[21:42] <popey> they seem to have joined a whole load of channels
[21:42] <LjL> !staff | have a look at this please
[21:44] <LjL> (thanks staff)
[21:46] <nalioth> popey: thanks
[21:46] <LjL> hmm there's still a lot random-looking ones connected from 206.251.250.*
[21:46]  * nalioth knows those guys
[21:46] <LjL> none of the 209.216.196.* are not connected anymore, on the other hand
[21:47] <popey> klined
[21:47] <LjL> yes, the 209 ones were
[21:48] <LjL> the 206 - still weird
[21:48] <LjL> still *none of them* connected to #ubuntu
[21:48] <LjL> even though some of them are on +1
[21:48] <LjL> one in on -es...
[21:48] <LjL> one on -nl
[21:49] <LjL> and they are all no more


[00:20] <axino> cory_fu: still about ?
[00:23] <axino> cory_fu: https://pastebin.canonical.com/152219/ I repro'ed
[00:32] <axino> cory_fu: OK found the difference : APT::Install-Recommends "false";
[00:33] <axino> cory_fu: python-virtualenv only recommends the virtualenv package, so I think we should "force" its installation
[09:53] <Sophie_> brothers in arms I need help
[11:55] <gnuoy> jamespage, have you got a sec for https://code.launchpad.net/~gnuoy/charm-helpers/keystone_authtoken/+merge/289042 ?
[12:16] <icey> I've deployed juju (1.25.4) onto MAAS configured with zones, but the charm environment still doesn't seem to be setting JUJU_AVAILABILITY_ZONE
[12:24] <tvansteenburgh> hey guys, i have a fresh xenial with a fresh juju 1.25.3. `ps -aef |grep juju` returns nothing. how do i get juju running, or figure out why it won't start?
[12:28] <icey> tvansteenburgh: have you 'juju bootstrap'ed
[12:29] <tvansteenburgh> icey: says i'm already bootstrapped, but i can't destroy b/c jujud isn't running
[12:29] <icey> local environment tvansteenburgh?
[12:29] <tvansteenburgh> hmm, that gives me an idea though
[12:29] <tvansteenburgh> yeah
[12:34] <tvansteenburgh> icey: got it going again with the juju-clean plugin
[12:35] <icey> nice tvansteenburgh :)
[12:35] <icey> hopefully my problem is as easily solved, though I fear not
[12:39] <marcoceppi> Sophie_: how can we help?
[12:44] <Sophie_> i thinki i found something i will tell you if it doesnt work :P
[12:56] <beisner> icey, can you point me at that az bug for 1.25.x ?
[12:56] <beisner> my search foo is failing me ... ++coffee..
[12:57] <icey> beisner: https://bugs.launchpad.net/juju-core/+bug/1546790
[12:57] <mup> Bug #1546790: availability zone not set <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Released by anastasia-macmood> <https://launchpad.net/bugs/1546790>
[12:57] <icey> that should be fine on MAAS too as it is not a provider specific change
[12:57] <beisner> icey, still getting 'None' ?
[12:57] <icey> on MAAS, yes; works fine on AWS
[13:07] <beisner> icey, can you push a new patchset to 293694 with log("AZ Info: " + az_info) in your az_info() method?
[13:07] <beisner> or the slightly adjusted equiv that is
[13:08] <icey> heh sure, I did have that in there at one point :)
[13:08] <beisner> that'll be something we want in place for t-shooting purposes, both now, and down the line.
[13:08] <beisner> safe to leave in place
[13:09] <icey> beisner: incoming
[13:09] <beisner> icey, thx sir
[13:10] <beisner> icey, i'm going to tear that down and redeploy.  need to catch the tiger by the tail.
[13:10] <icey> beisner: I was just about to say I'll do that :)
[13:10] <icey> I'll let you drive
[13:25] <icey> beisner: did you want to update the bundle to deploy changset 5?
[13:25] <beisner> icey, oh heck.  yes.
[13:26] <icey> on the plus side, it failed to deploy anyway beisner
[13:26] <beisner> icey, yeah i suspect a separate bug in 1.25.4, as it did that on me as well.  but a retry succeeded.   and it didn't do that with the same bundle on 1.25.3.
[13:26] <beisner> but one at a time
[13:27] <icey> by the way, apparently 1.25.4 is DOA for another bug, but it's the minimum that has a fix we're testing :)
[13:27] <icey> beisner: ^
[13:27] <beisner> it is
[13:27] <beisner> but if we want to move this az thing fwd, we either try-and-see, or shelve it until there is a juju version where az does what the charm change requires
[13:44] <beisner> icey, ha.  the controller had the patchset 4 rev of ceph-osd.  will upgrade-charm...
[13:45] <icey> yay controller -_-
[13:47] <jamespage> thedac, beisner: had another run at https://review.openstack.org/#/c/291721/3 which should deal with upgrades as well
[13:48] <jamespage> its hard to follow the logic, but basically if the nova_api db is not created, we skip migration on service restart on upgrade, clear the dbstate marker in leader storage and then migration and restart on the next db-changed event...
[13:50] <beisner> icey, ok, charm upgraded.  now to look at the unit logs for az info dump...  drumroll
[13:51] <icey> beisner: the place we call that happens in emimt_cephconf
[13:52] <icey> emit_cephconf rather
[13:53] <icey> beisner: look at /etc/ceph/ceph.conf ; it JUJU_AVAILABILITY_ZONE is, then it will be present there
[13:53] <icey> in "osd crush location"
[13:54] <icey> no AZ is set
[13:55] <beisner> but at least we see that in the juju unit log now
[13:55] <icey> true
[13:58] <beisner> icey, ok this is where i bail on deploy/test efforts and let you drive the bug(s).   az ceph changes should be kept wf -1 until we can actually exercise the proposed changes.  we'll keep those maas machines avail to you though.
[13:58] <icey> beisner: they are fine on AWS :-P
[13:58] <beisner> until thedac needs 'em back that is ;-)
[13:58] <icey> but yeah, I think this is blocked until we can get some juju insight on it
[13:58] <beisner> icey, right, but the actual use case is on metal.
[13:59] <icey> beisner: one can only hope ;-)
[13:59] <beisner> icey, ok thx for diving into that with me.  lmk how it goes with bug chasing.
[14:03] <beisner> jamespage, ack, thx re: ncc 291721, will look for thedac to re-review.
[14:12] <beisner> hi tinwood, gnuoy - re: the enhanced pause/resume work - should we be adding pause/resume amulet tests to go along with those?  (similar to the early-adopter swift-* ones)
[14:12] <gnuoy> beisner, yes, I think we should
[14:13] <tinwood> hi beisner, yes, I've added that to my instructions in the gist: https://gist.github.com/ajkavanagh/bb16cd911dfbac2e5651
[14:13] <beisner> gnuoy, tinwood - ok great, i agree.  i'd like to see those accompany the proposals.
[14:13] <tinwood> beisner,  "proposals"?
[14:14] <beisner> errr uhm, gerrit changes.  /me still blurs git/gerrit/bzr terminology ;-)
[14:14] <tinwood> ah, right.
[14:14] <beisner> if we defer to add tests later, we endure test debt which may or may not be revisited.
[14:15] <beisner> hence, the accompany-changes-with-tests preference
[14:15] <tinwood> beisner,  we singing from the same songsheet.
[14:15] <beisner> woot
[14:16] <beisner> 🎜🎝
[14:16] <tinwood> :)
[14:21] <beisner> wow that +2 button is no-confirm one-click madness
[14:22] <beisner> tinwood, ok yep i also had refresh the browser issues on my wf-1 for your ceilo.  wf cleared to 0
[14:23] <tinwood> beisner, you too eh.  I also think I had a osci blow up on the charm-recheck-full on charm-glance :(  -- or I misunderstood the error trace.
[14:23]  * beisner looks
[14:25] <beisner> tinwood, indeed "ERROR failed to bootstrap environment:"  might have been during the network loop/storm.  feel free to retrigger
[14:26] <tinwood> beisner, yes - that makes sense.  Lost network access to the bastion for about 2 mins around 12.00 today -- IIRC.
[14:26] <tinwood> I'll trigger a recheck.  Thanks!
[14:27] <beisner> tinwood, ack thx too
[14:28] <beisner> hi tvansteenburgh, i'm seeing something that i think is an amulet bug in the sentry list population, with subordinates.  caught it here:  http://pastebin.ubuntu.com/15414895/   ideas?
[14:29] <tvansteenburgh> beisner: can you file that here and i'll take a look https://github.com/juju/amulet/issues
[14:30] <thedac> jamespage: I'll take a look at your nova-cc PR shortly
[14:32] <tvansteenburgh> beisner: can you include the full yaml formatted status too
[14:32] <beisner> tvansteenburgh, yep, raised, will add full yaml
[14:33] <tvansteenburgh> beisner: also, does self.d.sentry['lxd'][0] work?
[14:33] <tvansteenburgh> (if you know)
[14:35] <beisner> tvansteenburgh, i'm guessing so, per: https://github.com/openstack/charm-lxd/blob/master/tests/basic_deployment.py#L127
[14:35] <tvansteenburgh> beisner: k, thanks
[14:36] <beisner> tvansteenburgh, i wonder if the passing runs have matching subordinate and principal unit ids and if it's failing when they aren't matching?  aiui there's no guarantee that they will match.
[14:41] <beisner> tvansteenburgh, indeed, when the sub and princ unit id's match, it passes.
[14:44] <tvansteenburgh> beisner: could be a red herring, i can't see the relevance in the code
[14:44] <tvansteenburgh> of course i could be wrong
[14:44] <beisner> tvansteenburgh, yah it could be, i've not dug into it.
[14:46] <jamespage> thedac, hey - looking at that unison merge/bug you referenced now
[14:49] <thedac> jamespage: sweet, thanks
[14:51] <magicaltrout> marcoceppi: couple of random questions from todays delving into charm world
[14:52] <magicaltrout> a) why can't you trigger actions from juju gui?
[14:52] <magicaltrout> b) can you trigger actions from within a bundle?
[14:52] <marcoceppi> a) the GUI hasn'
[14:52] <marcoceppi> t had time add that as a feature yet
[14:52] <marcoceppi> b) not yet, we had an interesting conversation about it and it's a feature I'm interested in for benchmarking but you can't atm
[14:52] <jcastro> marcoceppi: for policy the "must pass bundletester" ... that replaces must pass charm proof and bundle right?
[14:52] <jamespage> thedac, not sure I quite understand how that's impacting you?
[14:52] <jcastro> for your proposal I mean
[14:52] <marcoceppi> jcastro: yes
[14:53] <magicaltrout> booo
[14:53] <magicaltrout> okay
[14:53] <magicaltrout> I wanted to come up with a useful "demo bundle"
[14:53] <thedac> jamespage: keystone on xenial segfaults when trying to copyt the ssl files via unison
[14:53] <jcastro> do we have bundletester documented? I can't seem to find a page for it
[14:53] <magicaltrout> but i'd need to run some actions to get the test data stuff in there
[14:53] <marcoceppi> magicaltrout: yeah, I do as well. It might be good to reply to the roadmap email for actions in bundles and actions in GUI
[14:53] <jamespage> thedac, between units all on the same version?
[14:53] <marcoceppi> magicaltrout: I keep forgetting about those
[14:53] <thedac> jamespage: yes
[14:53] <magicaltrout> i'll add them in then
[14:53] <marcoceppi> jcastro: for now, just have it as `charm test` we'll make charm test do the right thing
[14:53] <thedac> jamespage: and I can confirm manually scp'ing works
[14:54] <jcastro> ack
[14:54] <jamespage> thedac, Unison segfault when transferring data, "input_value: bad bigarray kind"
[14:54] <jamespage> that kinda thing?
[14:55] <thedac> similar. I'll have to deply again to get the exact error
[14:55] <jamespage> thedac, but you def saw a segfault right?
[14:55] <thedac> yes, that is confirmed. While running the command by hand
[15:04] <cory_fu> axino: https://github.com/juju-solutions/layer-basic/pull/49
[15:06] <cory_fu> tvansteenburgh (or anyone who can help): We ran into an issue with our bundle test for Zeppelin in that Zeppelin requires Javascript to render anything so our Amulet test can't verify that it's actually working.  That ended up biting us because it in fact isn't.  Any suggestions on how to charm test a service that requires JS?
[15:11] <magicaltrout> cory_fu: can't you prod endpoints to check its responding correctly?
[15:11] <tvansteenburgh> cory_fu: i dunno, maybe shell out to casperjs or something
[15:12] <tvansteenburgh> cory_fu: might be a good question for hatch
[15:12] <cory_fu> magicaltrout: I don't know the protocol the zeppelin websocket uses
[15:12] <tvansteenburgh> i assume you'll have to shell out to something though
[15:13] <hatch> ahoy
[15:14] <cory_fu> hatch: Trying to figure out how to create an automated test for Zeppelin.
[15:15] <hatch> cory_fu: if you want to test that zeppelin renders something properly (although thats probably not recommended because you're effectively testing Zeppelin at that point)
[15:15] <lazyPower> cory_fu : if you're willing to incur the dep cost, phantomjs is a resonable headless test driver that by its very nature understands js.
[15:15] <hatch> you 'simply' ;) need to load it up in something like phantomjs and then query the dom
[15:15] <hatch> using a test driver
[15:15] <lazyPower> cory_fu : splinter is a nice abstraction for talking to phantom from python...
[15:16] <cory_fu> Nice. Those are exactly the suggestions I was hoping for.
[15:16] <magicaltrout> last time I had to test websockets, I trapped some output with wireshark and hacked up curl to test it :)
[15:16] <hatch> cory_fu: although I'd still question weather the test is necessary
[15:16] <lazyPower> hatch - i think its more of a smoke test to find out if zeppelin is doing the right thing
[15:16] <tvansteenburgh> ERROR unrecognized command: juju init
[15:16] <tvansteenburgh> wtf
[15:17] <cory_fu> hatch: The background is that Zeppelin starts up and runs fine, but if you actually try to run the notebook, it fails because of a classpath configuration issue
[15:17] <hatch> ohhh I see
[15:17] <hatch> downloading and installing phantom is such a time consuming process :(
[15:17] <lazyPower> cory_fu - i'm curious to see how that evolves over time, if it becomes a noisy test due to DOm changes between releases, or if it stays relatively consistent
[15:17] <lazyPower> hatch - we can use a container to make that part faster
[15:18] <hatch> mmm true true
[15:18] <hatch> it's really too bad everyone is going to these client-only rendering schemes
[15:18] <cory_fu> Yeah, I had thought of phantomjs but figured it would be a big dep just for a test.  And I also wasn't sure about bindings, but if splinter is good, maybe it'll be worth it
[15:18] <hatch> it only takes a few hours to set up an isomorphic rendering setup
[15:18] <lazyPower> as a webdev that pushed for the client to do more, i regret nothing... but i also got out of webdev :D
[15:19] <magicaltrout> i'll take websockets headaches over php any day ;)
[15:19] <lazyPower> ^
[15:19] <lazyPower> and that
[15:19] <lazyPower> bushel baskets full of that
[15:19] <hatch> lol
[15:19] <cory_fu> ha
[15:20] <cory_fu> magicaltrout: I'm really not inclined to start reverse-engineering ZK, though
[15:20] <hatch> if I can't load a 'content' site without javascript and still see the content - they did it wrong ;)
[15:20] <magicaltrout> it is true though, I'm not a fan of stuff that is entirely Javascript, even though i write webapps for a living.
[15:22] <hatch> cory_fu: I'd imagine others would also need to do similar tests with charms, might be worth abstracting it into a module of sorts
[15:22] <magicaltrout> yup, if it becomes generic, I don't mind reusing someone elses effort ;)
[15:26] <aisrael> Did I dream juju 2.0 beta 2 was released? I've got ppa:juju/devel added but still don't see beta 2
[15:28] <aisrael> Ohh. The package was renamed from juju-core2 to juju2
[15:32] <kwmonroe> yeah, thank lazyPower for that ^
[15:32] <lazyPower> i got bit by it too
[15:32] <lazyPower> had to update charmbox
[15:32] <lazyPower> kwmonroe what did i do?
[15:35] <cory_fu> lazyPower: I tihnk kwmonroe was referring to the splinter suggestion
[15:35] <cory_fu> Or maybe he was blaming you for the juju-core2 -> juju2 rename
[15:35] <cory_fu> Either way, it's all your fault
[15:35] <lazyPower> yeah, some would say that
[15:35] <magicaltrout> hehe
[15:36] <lazyPower> but some people just want to watch the world burn cory_fu
[15:37] <cory_fu> lazyPower: When you made your earlier comment about encouraging client-heavy pages and then leaving web dev, I pictured you throwing a match over your shoulder while walking away, after having convinced everyone to hoard gasoline in open containers
[15:39] <jamespage> beisner, hey https://review.openstack.org/#/c/291139/ is still kicking around - nice to get that landed if possible...
[15:40] <hatch> cory_fu: lol
[15:40] <beisner> jamespage, indeed.  so we had our own ski trip this week, but it was more off-path, through the trees with a few cliff jumps ;-)   i think we're clear of any fires and back to regular business.
[15:40] <jamespage> beisner, oh did we?
[15:41] <jamespage> beisner, what exploded?
[15:43] <lazyPower> hahaha
[15:44] <beisner> jamespage, first stable charm update with the new flow revealed:  stable charms needed tox and gerritreview file housekeeping, and 16.01 stable charms are set to test amulet against next which is no bueno;  WIP by wolsen and i
[15:44] <jamespage> beisner, urgh...
[15:44] <beisner> jamespage, the master charm makefiles were still using system pkgs which was causing inconsistency in tests, that's fixed on all @ master (except lxd, which has a wip)
[15:45] <beisner> jamespage, and we broke and reverted two charms at master. ;-)
[15:45] <jamespage> eeek
[15:45] <beisner> plugged one of those holes with an amulet test, the other was just process
[15:45] <marcoceppi> tvansteenburgh: juju init is dead
[15:45] <marcoceppi> just autoload-credentails
[15:45] <beisner> and everyone survives :-)
[15:45] <marcoceppi> wtf do you need to init ;)
[15:45] <tvansteenburgh> marcoceppi: thanks, i figured it out :)
[15:46] <tvansteenburgh> marcoceppi: well it's in the docs, and it's still in the command list for juju2
[15:46] <marcoceppi> and so ends one of the longest running disagreements between me and evilnickveitch "init vs generate-config" ;)
[15:46] <marcoceppi> tvansteenburgh: that's just beta cruft, it's gonzo
[15:46] <tvansteenburgh> cool
[15:47] <evilnickveitch> marcoceppi, yes, it must be great for you not to be quite so wrong any more :)
[15:47] <marcoceppi> evilnickveitch: aww, that's what I was hoping you would say. I miss our spirited debates
[15:47] <evilnickveitch> I'm sure we will find something to take its place!
[15:52] <jamespage> beisner, the revert was the 'blocked' status on ceph-osd?
[15:52] <beisner> jamespage, ack that one and a keystone install-hook fail.
[16:01] <gnuoy> beisner, I'm failing to grok the CI comments on https://review.openstack.org/#/c/292897/ , has full amulet passed?
[16:03] <beisner> gnuoy, yep i cleared my wf -1 to 0;  then prematurely +2'd (via the one-click no-confirm +2 button, yikes);  then set my code-review to 0;  most recent patchset (5) has Canonical CI verify+1;  so it's clear to review.
[16:04] <gnuoy> beisner, ok, ta
[16:06] <beisner> gnuoy, yw.  apologies for the noise there.
[16:21] <jamespage> gnuoy, thedac, beisner: hey I was going to try to spend some time next week on nova-cc and nova-compute to a) rollup old config files and b) extract neutron
[16:21] <jamespage> any thoughts?
[16:22] <gnuoy> jamespage, Sounds great, thank you
[16:22] <thedac> nova-compute would still run nova-api-metadata when in dvr mode, correct?
[16:22] <jamespage> gnuoy, this would mean removal of the legacy neutron support which I think would be a win for all
[16:22] <gnuoy> agreed
[16:22] <jamespage> based on my current experience of the nova-cc charm at least
[16:22] <jamespage> thedac, correct
[16:23] <jamespage> so its aware of neutron, but only provides nova services...
[16:23] <thedac> jamespage: then I am a big +1
[16:23] <jamespage> thedac, I reckon it will strip out about 50% of the codebase..
[16:23] <jamespage> esp in nova-cc
[16:23] <thedac> nice
[16:25] <jamespage> thedac, unison is merged btw
[16:25] <jamespage> so that should fix keystone syncs again
[16:25] <thedac> jamespage: thanks. I'll test
[16:25] <jamespage> but it does mean that a trusty->xenial sync will not work
[16:25] <jamespage> I think
[16:25] <jamespage> its a bit of a mess with cross version compat afaict
[16:26] <thedac> gnuoy: is this the only nrpe change? https://code.launchpad.net/~gnuoy/charms/trusty/nrpe/sibling-subordinate/+merge/288888  That one failed automated testing
[16:27] <gnuoy> thedac, that's the one. It'll probably be next week before I can get to checking why it failed
[16:27] <thedac> gnuoy: ok, I'll still do the code review for now
[16:27] <gnuoy> thedac, excellent, thanks
[16:29] <thedac> gnuoy: it might be a test rig failure. import amulet failing http://juju-ci.vapour.ws:8080/job/charm-bundle-test-aws/3192/console
[16:29] <thedac> tvansteenburgh: Is this a problem with the automated testing? ^^
[16:30] <gnuoy> wolsen, hardening io ch change landed
[16:30] <thedac> nice
[16:31] <tvansteenburgh> thedac: amulet pkging prob, but resolved since that test ran
[16:31] <thedac> tvansteenburgh: great, is there a magic way to retest?
[16:31] <tvansteenburgh> thedac: yes :)
[16:32] <tvansteenburgh> thedac:  are you in ~charmersL
[16:32] <tvansteenburgh> ~charmers ?
[16:32] <thedac> tvansteenburgh: haha, I was when I was in IS. I need to make that request. my bad
[16:33] <tvansteenburgh> thedac, np, if you were you could kick off a test from here http://review.juju.solutions/review/2606
[16:33] <tvansteenburgh> but i'll do it for you
[16:33] <thedac> thank you, sir
[16:33] <tvansteenburgh> thedac: retest queued, np
[16:36] <wolsen> gnuoy \o/
[16:50] <jamespage> thedac, did a quick upgrade check on nova-cc liberty->mitaka - worked OK
[16:50] <jamespage> in that it did the series of things I expected it todo.
[16:50] <thedac> sweet.
[16:50] <jamespage> and is functional afterwards...
[16:50] <thedac> that is always good
[16:51] <thedac> I'll watch the amulet run and +2 when it completes. (unless we are supposed to have different reviewers do the second review) /me still learning the process
[16:51] <narindergupta> marcoceppi: hi
[16:53] <narindergupta> marcoceppi: do we know whether juju published feature is there in latest juju client? As we have to start preparing for OPNFV C release now so want to make sure i published the various charm in opnfv dev space and use it? How can i do that?
[16:55] <thedac> jamespage: oh, amulet already succeded. So again policy wise should I be the +2 or should that be a second reviewer?
[16:55] <jamespage> thedac, +2 approval from you is fine, and then +1 on workflow to land it...
[16:55] <thedac> cool
[16:55] <jamespage> thedac, we're only enforcing a no-self-review policy right now
[16:56] <thedac> got it
[16:56] <thedac> jamespage: approved
[17:03] <marcoceppi> narindergupta: that will be released either today or monday
[17:03] <marcoceppi> narindergupta: and it's not in the juju client, it's in the charm command
[17:04] <narindergupta> marcoceppi: ok i need to learn how to do and how its going to help me in C release. Ad most importnant for me is openstack charms in git repo though
[17:09] <thedac> jamespage: seems the unison merge fixed that issue. Thank you.
[17:09] <jamespage> thedac, np
[17:10] <jamespage> narindergupta, openstack charms are in git repos now
[17:11] <narindergupta> jamespage: yes thats in git repos and my queston was whether juju feature of publishing charm in dev will work for openstack charms in git repo also or not?
[17:12] <jamespage> narindergupta, tbh the new workflow is agnostic of VCS
[17:12] <jamespage> its basically 'shove this directory and contents to the charmstore here please'
[17:12] <narindergupta> ok that sounds good then
[17:13] <narindergupta> so that we can control what should go in opnfv dev charmstore space
[17:17] <jamespage> narindergupta, I'm a little unclear as to why you need a separately namespaced set of charms?
[18:11] <cholcombe> no crontab helpers in charmhelpers?
[18:11] <cholcombe> pip to the rescue!
[18:47] <fritchie> anyone here familiar with openstack-base?
[19:10] <icey> lazyPower: can you install python-tox on the base docker image for https://github.com/juju-solutions/charmbox ?
[19:10] <lazyPower> if you give me a bug to do so
[19:10] <lazyPower> do you want it in stable, devel, or both?
[19:11] <icey> lazyPower: development? I want to be able to start up the box, cd to the charm directory, and run make test; most of our (openstack) tests are using tox to manage the testing environment
[19:12] <lazyPower> so you want it on the 2.0 flavor only?
[19:13] <icey> lazyPower: I suppose I misunderstood, I'd like it to have tox on all versions that I could run tests on :)
[19:14] <lazyPower> icey - ack, gimme a bug# and i'll submit to the builders
[19:14] <icey> bug# on LP, GH?
[19:14] <lazyPower> GH
[19:14] <lazyPower> @ the repo you linked above
[19:15] <icey> https://github.com/juju-solutions/charmbox/issues/13 lazyPower
[19:23] <lazyPower> icey : https://github.com/juju-solutions/charmbox/pull/14
[19:23] <lazyPower> icey : https://github.com/juju-solutions/charmbox/pull/15
[19:24] <lazyPower> ~ 20 minutes after those are merged you'll have new toys in charmbox
[19:25] <icey> :)
[19:38] <lazyPower> https://hub.docker.com/r/jujusolutions/charmbox/builds/ - if you wanted to follow along at home
[19:39] <icey> heh lazyPower, the reactive base layer is using tox for unit testing :)
[19:39] <lazyPower> we've been using tox all over the place for quite a while
[19:41] <lazyPower> good shout tho. lmk if you need anything else icey
[19:41] <icey> I think I'm good lazyPower thanks!
[20:32] <cholcombe> lazyPower, want to review a 4 liner?  https://code.launchpad.net/~xfactor973/charm-helpers/action-params/+merge/289537
[20:34] <lazyPower> cholcombe - sure - if you review mine https://github.com/juju-solutions/layer-logstash/pull/13
[20:35] <cholcombe> lazyPower, :)
[20:36] <lazyPower> obey the space walrus
[20:36] <cholcombe> hah
[20:41] <cholcombe> lazyPower, it looks sane to me
[20:41] <cholcombe> lazyPower, i don't have a lot of layer experience though so if i missed something that's why :)
[20:45] <lazyPower> cholcombe - time to change that ;)
[20:45] <cholcombe> yep
[20:47] <lazyPower> approved/merged
[20:48] <lazyPower> cholcombe - beware though, i dont think that method is python3 safe. iteritems was removed i'm pretty sure
[20:48] <cholcombe> lazyPower, uh oh
[20:49] <lazyPower> dict.items() is the python3 idiom
[20:49] <cholcombe> gotcha
[23:06] <thedac> Finally sent my offical ~charmers application email


[11:37] <cmaloney> Morning
[13:08] <rick_h_> morning
[13:08] <rick_h_> from lovely howell heh
[13:09] <cmaloney> Heh
[13:09] <cmaloney> How was the morning commute? :)
[13:09] <rick_h_> ugh, hour long
[13:09] <cmaloney> Yeah, I can imagine
[13:09] <cmaloney> Sounds like my commute from Belleville to Auburn Hills
[13:09] <rick_h_> but place seems nice, 13/6 internet, right on main street.
[13:09] <cmaloney> No quick way.
[13:09] <cmaloney> Oh, coffee shop?
[13:09] <rick_h_> yea, just hop on M59 and keep on going and going
[13:09] <rick_h_> no, coworking space
[13:10] <cmaloney> Ah, cool
[13:10] <rick_h_> didn't think we could work a full day with calls/etc in a coffee shop
[13:10] <cmaloney> yeah, that would be too tough
[13:12] <brousch> What's this?
[13:13] <rick_h_> heh cool that bookie almost got as many apps as phpmyadmin http://blog.cihar.com/archives/2014/03/24/gsoc-2014-applications-phpmyadmin/
[13:13] <rick_h_> brousch: so when we start a new person we do an intro sprint. Work for a week together
[13:13] <rick_h_> brousch: so I'm meeting up with kyle in a coworking space in howell this week
[13:13] <rick_h_> gmaps said 45min each way for each of us, more like 55 for me
[13:13] <rick_h_> and he's not here yet so I'll assume more for him as well
[13:14] <brousch> That doesn't sound right. GR is 45 minutes from Muskegon
[13:14] <cmaloney> Yeah, I think that's "45 minutes as the crow flies" and not "45 minutes in rush-hour"
[13:15] <brousch> I would put Howell at 2 hours from Muskegon
[13:15] <cmaloney> I would put Howell as "we'll get there eventually"
[13:16] <cmaloney> much like the rest of anything past Wixom. :)
[13:16] <brousch> Depending on when he hit GR, it could add another 15 minutes
[13:16] <rick_h_> lol
[13:17] <brousch> Yes, bad rush hour in GR adds 15 minutes to your commute
[13:18] <brousch> Of course it's possible he's not at home right now, but staying in Lansing or something
[14:29] <Havenstance> It depends on the way you go to Muskegon from GR though
[14:29] <Havenstance> I've had travel times from Muskegon to GR take upwards of 2 hours
[14:30] <Havenstance> obviously there were traffic delays but it happens
[14:30] <brousch> Well yeah, I'm assuming he takes I-96 and not back roads
[14:30] <Havenstance> Yeah I've had it happen on I-96, semi crashed & they had the whole road blocked
[14:30] <Havenstance> isolated incident not like it happens every single day
[14:31] <Havenstance> Most likely I'd blame it on the traffic though. Its usually 45mins to an hour from GR to Muskegon I used to frequent that drive till I moved to Traverse City
[14:32] <brousch> Havenstance: Yeah, I just found it odd that they would pick Howell as a center point, since it's 45 mins to GR, then 1:00 to Lansing, then 15 mins to Howell
[14:33] <Havenstance> Yeah, I don't think I've ever went from Muskegon to Howell though
[14:33] <brousch> PRobably Kyle just being a nice guy
[14:33] <brousch> Or Canonical reimbursing mileage so really racking up that bill
[14:34] <Havenstance> lol, that could be an option too
[14:36] <brousch> http://www.meetways.com/halfway-point-between-muskegon-mi-usa-and-clarkston-mi-48346-usa-poi-restaurant-ahw-0-atl-0-tmd-driving.html
[14:36] <brousch> Actually west of Lansing
[14:37] <Havenstance> yeah that's quite a hike though from troy to muskegon
[14:37] <brousch> That site shows the half way point and points of interest near there
[14:38] <Havenstance> that's pretty sweet
[14:38] <Havenstance> I'll have to bookmark that for future reference
[14:39] <Havenstance> I remember the last time I was in Muskegon. They had a DeTour down that road that walmart is on, they ran you down Broadway around it basically right through the heights.
[14:40] <Havenstance> I'd have to see the road sign to know what road that is you get off the freeway and go to the left to get to walmart this way
[14:40] <brousch> Did they hand out bullet proof glass?
[14:40] <Havenstance> Hell no lol
[14:40] <Havenstance> I wasn't too worried about it though. For the most part if you treat the people down there good they do the same in return
[14:40] <brousch> My wife is from Muskegon, so I get a punch in the arm every time I talk like that
[14:41] <Havenstance> Hell now a days you got whites hanging around with blacks and vise versa so its not near as bad as it was in the 80s and 90s
[14:42] <Havenstance> Didn't bother me going that way but my then girlfriend was so scared she was basically hiding on the floor board of the car
[14:42] <Havenstance> I got quite a kick out of it :)
[14:43] <Havenstance> She goes my dad always said white people don't go to Muskegon Heights
[14:43] <Havenstance> I was like yeah that might have been when he was a kid but now you won't have too much of a problem i f your respectful and understand that YOU are the minority there
[16:32] <cmaloney> Afternoon
[17:13] <brousch> cmaloney: +1
[17:13] <rick_h_> -1
[17:13] <rick_h_> where did the day go so far?
[17:15] <brousch> rick_h_: Time moves faster in Howell
[17:15] <rick_h_> heh, something
[17:18] <greg-g> speaking of Howell, we were looking for random weird linux distros for a coworker to install on a build machine, and along side Hannah Montana linux was the White Supremacist linux :/
[17:22] <cmaloney> There's also Linux Satanic which apparently links to Open Metalcast
[17:22] <cmaloney> I'm sure all of my religious instructors are so proud
[17:24] <cmaloney> Which is part of the reason my alumni associations get the terse phrase "Works with Computers"
[17:24] <cmaloney> ;)
[17:26] <cmaloney> http://decafbad.net/2013/12/11/still/
[17:35] <cmaloney> Also: frustrating when I have a band on my HDD that is amazing yet: 1) Not CC licensed and 2) Apparently was self-released
[17:36] <cmaloney> (Sleep of Thetis in case you want to play along at home)
[18:26] <cmaloney> You can tell when rick_h_ is working
[18:28] <rick_h_> sssshhhh
[18:29] <cmaloney> Exactly. You can hear a pin drop in here.
[18:51] <cmaloney> after playing with Ruby I have a renewed appreciation for the masterstroke that is Python's Virtualenvs
[18:53] <rick_h_> there are times I shake my head at python, but I get headaches from shaking at ruby
[18:54] <cmaloney> I just created a wrapper for uwsgi in rvm
[18:55] <cmaloney> It's two commands where my brain would say $path_to_venv/bin/python foo
[18:56] <cmaloney> It just creates this monolothic structure that, while complete, feels as though it were cobbled together by folks who looked at Virtualenv and decided to make a one-stop-shopping experience.
[18:56] <cmaloney> and in the end made something more akin to Walmart than Meijer.