[00:20] cory_fu: still about ? [00:23] cory_fu: https://pastebin.canonical.com/152219/ I repro'ed [00:32] cory_fu: OK found the difference : APT::Install-Recommends "false"; [00:33] cory_fu: python-virtualenv only recommends the virtualenv package, so I think we should "force" its installation === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob === danilos` is now known as danilos === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_zz_CyberJacob [09:53] brothers in arms I need help [11:55] jamespage, have you got a sec for https://code.launchpad.net/~gnuoy/charm-helpers/keystone_authtoken/+merge/289042 ? [12:16] 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] 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? === zz_zz_CyberJacob is now known as CyberJacob [12:28] tvansteenburgh: have you 'juju bootstrap'ed [12:29] icey: says i'm already bootstrapped, but i can't destroy b/c jujud isn't running [12:29] local environment tvansteenburgh? [12:29] hmm, that gives me an idea though [12:29] yeah [12:34] icey: got it going again with the juju-clean plugin [12:35] nice tvansteenburgh :) [12:35] hopefully my problem is as easily solved, though I fear not [12:39] Sophie_: how can we help? [12:44] i thinki i found something i will tell you if it doesnt work :P [12:56] icey, can you point me at that az bug for 1.25.x ? [12:56] my search foo is failing me ... ++coffee.. [12:57] beisner: https://bugs.launchpad.net/juju-core/+bug/1546790 [12:57] Bug #1546790: availability zone not set

[12:57] that should be fine on MAAS too as it is not a provider specific change [12:57] icey, still getting 'None' ? [12:57] on MAAS, yes; works fine on AWS [13:07] icey, can you push a new patchset to 293694 with log("AZ Info: " + az_info) in your az_info() method? [13:07] or the slightly adjusted equiv that is [13:08] heh sure, I did have that in there at one point :) [13:08] that'll be something we want in place for t-shooting purposes, both now, and down the line. [13:08] safe to leave in place [13:09] beisner: incoming [13:09] icey, thx sir [13:10] icey, i'm going to tear that down and redeploy. need to catch the tiger by the tail. [13:10] beisner: I was just about to say I'll do that :) [13:10] I'll let you drive [13:25] beisner: did you want to update the bundle to deploy changset 5? [13:25] icey, oh heck. yes. [13:26] on the plus side, it failed to deploy anyway beisner [13:26] 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] but one at a time [13:27] 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] beisner: ^ [13:27] it is [13:27] 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] icey, ha. the controller had the patchset 4 rev of ceph-osd. will upgrade-charm... [13:45] yay controller -_- [13:47] thedac, beisner: had another run at https://review.openstack.org/#/c/291721/3 which should deal with upgrades as well [13:48] 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] icey, ok, charm upgraded. now to look at the unit logs for az info dump... drumroll [13:51] beisner: the place we call that happens in emimt_cephconf [13:52] emit_cephconf rather [13:53] beisner: look at /etc/ceph/ceph.conf ; it JUJU_AVAILABILITY_ZONE is, then it will be present there [13:53] in "osd crush location" [13:54] no AZ is set [13:55] but at least we see that in the juju unit log now [13:55] true [13:58] 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] beisner: they are fine on AWS :-P [13:58] until thedac needs 'em back that is ;-) [13:58] but yeah, I think this is blocked until we can get some juju insight on it [13:58] icey, right, but the actual use case is on metal. [13:59] beisner: one can only hope ;-) [13:59] icey, ok thx for diving into that with me. lmk how it goes with bug chasing. [14:03] jamespage, ack, thx re: ncc 291721, will look for thedac to re-review. [14:12] 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] beisner, yes, I think we should [14:13] hi beisner, yes, I've added that to my instructions in the gist: https://gist.github.com/ajkavanagh/bb16cd911dfbac2e5651 [14:13] gnuoy, tinwood - ok great, i agree. i'd like to see those accompany the proposals. [14:13] beisner, "proposals"? [14:14] errr uhm, gerrit changes. /me still blurs git/gerrit/bzr terminology ;-) [14:14] ah, right. [14:14] if we defer to add tests later, we endure test debt which may or may not be revisited. [14:15] hence, the accompany-changes-with-tests preference [14:15] beisner, we singing from the same songsheet. [14:15] woot [14:16] 🎜🎝 [14:16] :) [14:21] wow that +2 button is no-confirm one-click madness [14:22] tinwood, ok yep i also had refresh the browser issues on my wf-1 for your ceilo. wf cleared to 0 [14:23] 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] tinwood, indeed "ERROR failed to bootstrap environment:" might have been during the network loop/storm. feel free to retrigger [14:26] beisner, yes - that makes sense. Lost network access to the bastion for about 2 mins around 12.00 today -- IIRC. [14:26] I'll trigger a recheck. Thanks! [14:27] tinwood, ack thx too [14:28] 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] beisner: can you file that here and i'll take a look https://github.com/juju/amulet/issues [14:30] jamespage: I'll take a look at your nova-cc PR shortly [14:32] beisner: can you include the full yaml formatted status too [14:32] tvansteenburgh, yep, raised, will add full yaml [14:33] beisner: also, does self.d.sentry['lxd'][0] work? [14:33] (if you know) [14:35] tvansteenburgh, i'm guessing so, per: https://github.com/openstack/charm-lxd/blob/master/tests/basic_deployment.py#L127 [14:35] beisner: k, thanks [14:36] 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] tvansteenburgh, indeed, when the sub and princ unit id's match, it passes. [14:44] beisner: could be a red herring, i can't see the relevance in the code [14:44] of course i could be wrong [14:44] tvansteenburgh, yah it could be, i've not dug into it. [14:46] thedac, hey - looking at that unison merge/bug you referenced now [14:49] jamespage: sweet, thanks [14:51] marcoceppi: couple of random questions from todays delving into charm world [14:52] a) why can't you trigger actions from juju gui? [14:52] b) can you trigger actions from within a bundle? [14:52] a) the GUI hasn' [14:52] t had time add that as a feature yet [14:52] 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] marcoceppi: for policy the "must pass bundletester" ... that replaces must pass charm proof and bundle right? [14:52] thedac, not sure I quite understand how that's impacting you? [14:52] for your proposal I mean [14:52] jcastro: yes [14:53] booo [14:53] okay [14:53] I wanted to come up with a useful "demo bundle" [14:53] jamespage: keystone on xenial segfaults when trying to copyt the ssl files via unison [14:53] do we have bundletester documented? I can't seem to find a page for it [14:53] but i'd need to run some actions to get the test data stuff in there [14:53] 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] thedac, between units all on the same version? [14:53] magicaltrout: I keep forgetting about those [14:53] jamespage: yes [14:53] i'll add them in then [14:53] jcastro: for now, just have it as `charm test` we'll make charm test do the right thing [14:53] jamespage: and I can confirm manually scp'ing works [14:54] ack [14:54] thedac, Unison segfault when transferring data, "input_value: bad bigarray kind" [14:54] that kinda thing? [14:55] similar. I'll have to deply again to get the exact error [14:55] thedac, but you def saw a segfault right? [14:55] yes, that is confirmed. While running the command by hand [15:04] axino: https://github.com/juju-solutions/layer-basic/pull/49 [15:06] 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] cory_fu: can't you prod endpoints to check its responding correctly? [15:11] cory_fu: i dunno, maybe shell out to casperjs or something [15:12] cory_fu: might be a good question for hatch [15:12] magicaltrout: I don't know the protocol the zeppelin websocket uses [15:12] i assume you'll have to shell out to something though [15:13] ahoy [15:14] hatch: Trying to figure out how to create an automated test for Zeppelin. [15:15] 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] 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] you 'simply' ;) need to load it up in something like phantomjs and then query the dom [15:15] using a test driver [15:15] cory_fu : splinter is a nice abstraction for talking to phantom from python... [15:16] Nice. Those are exactly the suggestions I was hoping for. [15:16] last time I had to test websockets, I trapped some output with wireshark and hacked up curl to test it :) [15:16] cory_fu: although I'd still question weather the test is necessary [15:16] hatch - i think its more of a smoke test to find out if zeppelin is doing the right thing [15:16] ERROR unrecognized command: juju init [15:16] wtf [15:17] 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] ohhh I see [15:17] downloading and installing phantom is such a time consuming process :( [15:17] 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] hatch - we can use a container to make that part faster [15:18] mmm true true [15:18] it's really too bad everyone is going to these client-only rendering schemes [15:18] 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] it only takes a few hours to set up an isomorphic rendering setup [15:18] as a webdev that pushed for the client to do more, i regret nothing... but i also got out of webdev :D [15:19] i'll take websockets headaches over php any day ;) [15:19] ^ [15:19] and that [15:19] bushel baskets full of that [15:19] lol [15:19] ha [15:20] magicaltrout: I'm really not inclined to start reverse-engineering ZK, though [15:20] if I can't load a 'content' site without javascript and still see the content - they did it wrong ;) [15:20] 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] 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] yup, if it becomes generic, I don't mind reusing someone elses effort ;) [15:26] 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] Ohh. The package was renamed from juju-core2 to juju2 [15:32] yeah, thank lazyPower for that ^ [15:32] i got bit by it too [15:32] had to update charmbox [15:32] kwmonroe what did i do? [15:35] lazyPower: I tihnk kwmonroe was referring to the splinter suggestion [15:35] Or maybe he was blaming you for the juju-core2 -> juju2 rename [15:35] Either way, it's all your fault [15:35] yeah, some would say that [15:35] hehe [15:36] but some people just want to watch the world burn cory_fu [15:37] 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] beisner, hey https://review.openstack.org/#/c/291139/ is still kicking around - nice to get that landed if possible... [15:40] cory_fu: lol [15:40] 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] beisner, oh did we? [15:41] beisner, what exploded? [15:43] hahaha [15:44] 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] beisner, urgh... [15:44] 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] jamespage, and we broke and reverted two charms at master. ;-) [15:45] eeek [15:45] plugged one of those holes with an amulet test, the other was just process [15:45] tvansteenburgh: juju init is dead [15:45] just autoload-credentails [15:45] and everyone survives :-) [15:45] wtf do you need to init ;) [15:45] marcoceppi: thanks, i figured it out :) [15:46] marcoceppi: well it's in the docs, and it's still in the command list for juju2 [15:46] and so ends one of the longest running disagreements between me and evilnickveitch "init vs generate-config" ;) [15:46] tvansteenburgh: that's just beta cruft, it's gonzo [15:46] cool [15:47] marcoceppi, yes, it must be great for you not to be quite so wrong any more :) [15:47] evilnickveitch: aww, that's what I was hoping you would say. I miss our spirited debates [15:47] I'm sure we will find something to take its place! [15:52] beisner, the revert was the 'blocked' status on ceph-osd? [15:52] jamespage, ack that one and a keystone install-hook fail. [16:01] beisner, I'm failing to grok the CI comments on https://review.openstack.org/#/c/292897/ , has full amulet passed? [16:03] 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] beisner, ok, ta [16:06] gnuoy, yw. apologies for the noise there. [16:21] 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] any thoughts? [16:22] jamespage, Sounds great, thank you [16:22] nova-compute would still run nova-api-metadata when in dvr mode, correct? [16:22] gnuoy, this would mean removal of the legacy neutron support which I think would be a win for all [16:22] agreed [16:22] based on my current experience of the nova-cc charm at least [16:22] thedac, correct [16:23] so its aware of neutron, but only provides nova services... [16:23] jamespage: then I am a big +1 [16:23] thedac, I reckon it will strip out about 50% of the codebase.. [16:23] esp in nova-cc [16:23] nice [16:25] thedac, unison is merged btw [16:25] so that should fix keystone syncs again [16:25] jamespage: thanks. I'll test [16:25] but it does mean that a trusty->xenial sync will not work [16:25] I think [16:25] its a bit of a mess with cross version compat afaict [16:26] 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] thedac, that's the one. It'll probably be next week before I can get to checking why it failed [16:27] gnuoy: ok, I'll still do the code review for now [16:27] thedac, excellent, thanks [16:29] 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] tvansteenburgh: Is this a problem with the automated testing? ^^ === natefinch is now known as natefinch-lunch [16:30] wolsen, hardening io ch change landed [16:30] nice [16:31] thedac: amulet pkging prob, but resolved since that test ran [16:31] tvansteenburgh: great, is there a magic way to retest? [16:31] thedac: yes :) [16:32] thedac: are you in ~charmersL [16:32] ~charmers ? [16:32] tvansteenburgh: haha, I was when I was in IS. I need to make that request. my bad [16:33] thedac, np, if you were you could kick off a test from here http://review.juju.solutions/review/2606 [16:33] but i'll do it for you [16:33] thank you, sir [16:33] thedac: retest queued, np [16:36] gnuoy \o/ [16:50] thedac, did a quick upgrade check on nova-cc liberty->mitaka - worked OK [16:50] in that it did the series of things I expected it todo. [16:50] sweet. [16:50] and is functional afterwards... [16:50] that is always good [16:51] 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] marcoceppi: hi [16:53] 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] jamespage: oh, amulet already succeded. So again policy wise should I be the +2 or should that be a second reviewer? [16:55] thedac, +2 approval from you is fine, and then +1 on workflow to land it... [16:55] cool [16:55] thedac, we're only enforcing a no-self-review policy right now [16:56] got it [16:56] jamespage: approved [17:03] narindergupta: that will be released either today or monday [17:03] narindergupta: and it's not in the juju client, it's in the charm command [17:04] 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] jamespage: seems the unison merge fixed that issue. Thank you. [17:09] thedac, np [17:10] narindergupta, openstack charms are in git repos now [17:11] 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] narindergupta, tbh the new workflow is agnostic of VCS [17:12] its basically 'shove this directory and contents to the charmstore here please' [17:12] ok that sounds good then [17:13] so that we can control what should go in opnfv dev charmstore space [17:17] narindergupta, I'm a little unclear as to why you need a separately namespaced set of charms? === redelmann is now known as rudi|comida === natefinch-lunch is now known as natefinch === rudi|comida is now known as redelmann [18:11] no crontab helpers in charmhelpers? [18:11] pip to the rescue! [18:47] anyone here familiar with openstack-base? [19:10] lazyPower: can you install python-tox on the base docker image for https://github.com/juju-solutions/charmbox ? [19:10] if you give me a bug to do so [19:10] do you want it in stable, devel, or both? [19:11] 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] so you want it on the 2.0 flavor only? [19:13] lazyPower: I suppose I misunderstood, I'd like it to have tox on all versions that I could run tests on :) [19:14] icey - ack, gimme a bug# and i'll submit to the builders [19:14] bug# on LP, GH? [19:14] GH [19:14] @ the repo you linked above [19:15] https://github.com/juju-solutions/charmbox/issues/13 lazyPower [19:23] icey : https://github.com/juju-solutions/charmbox/pull/14 [19:23] icey : https://github.com/juju-solutions/charmbox/pull/15 [19:24] ~ 20 minutes after those are merged you'll have new toys in charmbox [19:25] :) [19:38] https://hub.docker.com/r/jujusolutions/charmbox/builds/ - if you wanted to follow along at home [19:39] heh lazyPower, the reactive base layer is using tox for unit testing :) [19:39] we've been using tox all over the place for quite a while [19:41] good shout tho. lmk if you need anything else icey [19:41] I think I'm good lazyPower thanks! [20:32] lazyPower, want to review a 4 liner? https://code.launchpad.net/~xfactor973/charm-helpers/action-params/+merge/289537 [20:34] cholcombe - sure - if you review mine https://github.com/juju-solutions/layer-logstash/pull/13 [20:35] lazyPower, :) [20:36] obey the space walrus [20:36] hah === wolverin_ is now known as wolverineav [20:41] lazyPower, it looks sane to me [20:41] lazyPower, i don't have a lot of layer experience though so if i missed something that's why :) [20:45] cholcombe - time to change that ;) [20:45] yep [20:47] approved/merged [20:48] cholcombe - beware though, i dont think that method is python3 safe. iteritems was removed i'm pretty sure [20:48] lazyPower, uh oh [20:49] dict.items() is the python3 idiom [20:49] gotcha [23:06] Finally sent my offical ~charmers application email