[00:28] sinzui: how soon before we can unblock master by resolving bug 1424777? i think you said dimiter's fix for the cloud-init issue also will address this too [00:29] Bug #1424777: local-provider precise failed to upgrade

[00:29] jw4: http://juju.fail [00:29] marcoceppi: beyootiful [00:30] wallyworld, I can unblock 1.22 now. we are waiting for master to test, and it is waiting on this to complete and pass http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-precise-i386/1474/console [00:31] i get a 404 from that url [00:32] wallyworld, log in as a developer or admin [00:34] sinzui: internal canonical developers only? [00:40] jw4, yes, sorry [00:41] sinzui: n/m :) I think I already asked you so sorry if it feels harassing :-p [00:41] jw4, we are just counting down the i386 tests. the aws failure required us to retest the slowest test in the suite 7 times [00:42] sinzui: eeesh. out of curiousity where are you moving the bulk of the CI infrastructure? [00:42] sinzui: I thought I saw you say we were leaving aws for more stuff [00:44] jw4, we aren't moving it. the lxcbr0 bug in 1.21.1 killed our old state server. We had to rebuild [00:49] sinzui: oh, I see [01:02] katco: thnx for review! [01:20] and we have a real vivid machine [01:21] thumper, ping? [01:29] mattyw: hey, whazzup? === TheRealMue is now known as TheMue [02:34] anastasiamac: not sure what you mean by performance of regexp being "not as heavy"? it's a general purpose hammer, it's *definitely* going to be heavier than searching backwards for the last non-digit. === johnweldon is now known as jw4|afk [02:38] axw: i would have thought that go is sufficiently mature that performance will be noticably degraded for lasrger volumes of string comparisons... surely comparing 100 strings with regexp split is not a big deal?.. [02:40] anastasiamac: it is not. I pointed out that it's not *currently* a problem, but it could easily become one if someone decides to extract this function. If you can easily (literally the same number of LOC) do it more performantly without loss of readability (I don't think there is any), then I don't see why you wouldn't [02:41] I won't belabor the point, I just don't like seeing regexps used when there's a much simpler (algorithmically) way of solving the problem [02:42] axw: i have no problem changing the implmentation but m not convinced that there will be any gain as earlier implmentation was written with isdigit logic [02:43] axw: for ur suggestion to work, there would be a additional if- to cater for empty input string [02:43] axw: then traversing the string backwards [02:43] axw: if- last element is digit [02:43] axw: until non-digit is encountered [02:44] axw: then extracting first part of input as prefix [02:44] axw: and then parsing suffix into a number [02:44] axw: logically [02:44] axw: it's easier to read - get this 2 parts from string using regex [02:44] axw: :P [02:45] s/this/these [02:45] and then check if the number is missing... and then parse to a number.. it's almost identical. [02:45] axw: :D except for les lines of code :D [02:47] anastasiamac: http://paste.ubuntu.com/10400349/ [02:48] anastasiamac: as I said, literally the same # LOC :) [02:49] * axw goes back to reviewing tmpfs [02:51] axw: :D [02:55] wallyworld: reviewed your tmpfs branch [02:55] ty [03:06] axw: anastasiamac: i did a benchmark and on 20000 splits, regexp takes 0.06s longer. i'm ok with that :-) [03:07] im the regexp code is easier to read, but ymmv [03:08] wallyworld: i agreee - reg exp is easier to read [03:08] wallyworld: howver i have detected a regexp allergy in most go programmers towards regexp on other occasions too [03:09] them there is fighting words [03:09] wallyworld: since most likely skillset of maintaince (and current dev) team is go, mayb idiomatic go is "the path of less resisitance"? [03:09] regexp is nit not idiotmatic Go is it? [03:09] not not i mean [03:10] no, but the snippet axw pasted above is idiomatic === urulama_ is now known as urulama [03:11] anastasiamac: before working with Go, I spent a lot of time working with Java, C, C++ and Python both professionally and non-professionally. this has nothing to do with language choice [03:11] wallyworld: m on the fence on that but "when in Rome...", sorry "when in Go.." [03:11] it may be that there's some correlation :) [03:12] *I* don't find my version any more difficult to read, but if I'm outnumbered then feel free to revert. [03:12] axw: i personaly have a thing against string examinations, so will always vote for regexp use in complex cases [03:13] axw: hwever, here m not feeling the need to come heavy on either side :D [03:13] anastasiamac: sure, I agree. I don't think this is a complex case - I guess we have different cutoff points [03:13] axw: it's so trivial that m happy to follow either u or wallyworld [03:13] axw: since u've gone as far as writting a snippet, I thought I;d concur [03:14] i don't mind either way [03:14] axw: but then wallyworldwen and benchmarked.. [03:14] just leave it as whatever is there now [03:14] axw: wallyworld now i just need a 3rd party, opinion i think :D [03:15] opinion is go with the current diff, it works, and there's bigger things to worry about. i only did the benchmark to satisfy my assumption that regexp doesn't cost that much to use [03:16] axw: wallyworld: k... :D since neither of u want to **really*** put ur foot down (m having fun here)... [03:17] axw: wallyworld: and there is more important things to do (thnx ian for executive directive) [03:17] axw: wallyworld: and this PR has my name on it and I like regexp approach [03:17] axw: wallyworld: i'll revert [03:17] anastasiamac: ok. [03:18] axw: tyvm for showing me a way to do awesome string examination tho :D [03:18] gawd, we really need to do this over a beer or 6 [03:18] wallyworld: or a cider...? :D [03:18] i wouldn't revert now, andrew's solution is fine [03:18] yeah, or a cider [03:20] wallyworld: why not? CI is blocked anyway [03:21] wallyworld: and looking for flights is killing my buzz - there is no simple route from a ot b [03:21] you decide :-) [03:23] wallyworld: out of interest, what was the input you used to benchmark? :) [03:23] regexp will be slower with a longer prefix [03:25] axw: a shortish string, eg "myservice/12345" [03:25] axw: wallyworld: i think mayb we should upgrade beer and cider to harder liquor (menn0's scotch?) [03:25] i agree regexp will always be more expensive [03:27] with an approx 30 char string and up to a 6 digit number, it's twice as slow, taking 0.6s total for 20000 strings [03:30] wallyworld: is this realistic for juju names 30 char string and up to a 6 digit number (m guessing numeric suffix here) [03:30] wallyworld: ? [03:31] i can't recall if there's a length limit on service/unit names [03:31] most are shorter than that [03:47] sinzui: given the i386 test issues/failures are independent of the precise apt issue fix committed to master, should be unblock master if everything else besides the 386 tests is ok? [03:49] wallyworld, We don't know it is independent. I think I need to report a regression in 1.22 or find a way to mak a test that always passed in 1.22 pass again [03:49] wallyworld, and master doesn't get unblocked until master passed [03:49] passed [03:49] wallyworld, I can start master teasting now, but then I don't release 1.22 [03:50] ok, 1.22 is more important. but they are independent as far as i can see. the 386 are failing for the same reasons as always, no new failures [03:51] i wish we could just drop i386, it's 2015 after all [03:52] i also wish we had hardware to do more than one series test at a time [03:52] or i guess we'd need another jenkins set up [03:52] hi wallyworld, ? for ya: is there a way to destroy an environment but keep the bootstrap node? [03:53] not that I know of right now, but that's coming soon [03:53] thumper: the above will be in 1.23 right? [03:53] wallyworld, ec2 healed 4 hours ago [03:54] good :-) [03:54] * thumper looks up [03:54] wat? [03:54] thumper: destroy env but keep state server [03:54] wallyworld, ack, ty. i thought i had seen someone somewhere in somescript do it a while back, but maybe that was actually a dream ;-) [03:54] and the test results for 386 in trusty and precise on other machines also fail [03:54] wallyworld: not with the current way things work [03:54] wallyworld, beisner: when we have multiple environments, yes [03:54] wallyworld, so unless I can cheat juju shitty test suite, someone needs to change it [03:54] thumper: yeah, that's what i meant [03:55] wallyworld: not in a nice friendly way [03:55] it'll be possible but a little awkward [03:55] wallyworld, in summary, the 386 tests fail on precise and trusty, and in Hp and aws. that is very bad [03:55] until we get the new CLI working nicely with it [03:55] sinzui: i may have forgotten, but why do we support 386? would be nice if tests could be non voting tll we can fix [03:55] beisner: see thumper's answer above [03:56] wallyworld, ubuntu makes it, and I understand we want to allow 386 clients and many developers wan 386 images to develop with because they are small [03:56] ok tyvm [03:56] wallyworld: I fully expect to have multiple environment creation landed in the next day or so [03:56] wallyworld, I am fine to drop 386...and we can stop make windows clients which are 386 too [03:56] under a feature flag [03:57] sinzui: fair enough, 386 clients is one thing, but images, bleah, that is so last century. and what's small in 2015 anyway [03:57] wallyworld, take it to alexis so that she goes to ramm. when management says we don't need to support it we are done [03:58] sinzui: yeah, didn't mean to whinge to you, just venting [03:58] wallyworld, or as I have said in other bug reports, aws is dropping 386, joyent and hp don't support it so we need to make a decision about the windows case eventually [03:59] who still runs windows on i386? anyone? [04:00] you can't even buy a 386 version of windows since how long ago? [04:00] wallyworld, the os is 386 [04:00] wallyworld, and windows developers don't upgrade often [04:00] really? i thought win 7 was 64 bit [04:00] so the reasoning is windows developers need 386 [04:00] wallyworld, it didn't sell that well [04:01] at least that's what my last 2 laptops shipped with since 6 years ago [04:01] 64 bit [04:01] no 386 to be seen [04:02] wallyworld, just change the test suite to only test the client when 386 is involved. or as I suggested in that bug, just skip the two ping tests and we wouls have had a pass 9 hours ago [04:03] rightio, i'll skip those ping tests. the current pinger implementation is flwed anyway [04:03] and we want to replace it [04:05] wallyworld, I am rerunning the hp precise 386 test. It had only one failure and the suite is 40 minutes faster than the aws version [04:05] ok, hope it passes [04:05] wow 40 minutes [04:05] how long do the 386 tests take [04:06] 140minutes to 2h5m [04:06] yeah, it is that bad [04:06] and the and64 ones? [04:06] 20-40 minutes depending on the host. ec2 is slower that the slaves or the ppc64el hardware [04:07] wallyworld, but consider the arm64 tests, they take 18 hours [04:07] serious, so say 30mins for amd64 and > 4x that for i386 [04:07] wft [04:07] sinzui: and you are still trying to get these tests to pass to bless 1.22 right? [04:08] wallyworld, aws wont allow you to deploy 386 on a large instance, which is why we built our own [04:08] wallyworld, yes to bless 1.22 [04:08] sigh [04:09] sinzui: i will ask alexis about dropping support for i386; in the meantime, i will skip the pinger tests in trunk. [04:09] +1 [04:09] if i need to skip the pinger tests in 1.22 let me know [04:09] man, master should have been unblocked by now [04:09] wallyworld, use __jfdi__ to land that [04:10] yep [04:10] sinzui: i'll only skip on i386, vivid will still fail, we need to fix the tests [04:11] wallyworld, we don't unblock unitil the whole suite passes. remember that 1.22-beta3 did pass many time on about 2.5 hours. beta4 has NEVER passed and we have retested for hours [04:11] wallyworld, you will need to fix those for 1.23 since we know vivid will be in beta [04:12] bug is currently medium, should be high or critical then if vivid is blocked [04:12] wallyworld, vivid was a moving target. IT is now close to stable [04:12] i know whole suite needs to pass, but sad that i386 failures block landings [04:13] sinzui: as soon as we add vivid voting tests, the bug can become critical? [04:13] wallyworld, yep [04:22] axw: can i please have a trivial review to help unbock master [04:22] http://reviews.vapour.ws/r/1003/ [04:23] wallyworld: looking [04:24] wallyworld: done [04:24] ty [04:28] * jam goes to get his car serviced for a while [04:48] sinzui: that pinger test suite is now disabled for i386 on trunk [04:49] thank you wallyworld [04:49] sinzui: so, i think it's now about 4 hours or so till trunk is blessed by CI? [04:49] wallyworld, I think http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/run-unit-tests-precise-i386/1476/console is hung like the 8 previous attempts [04:50] wallyworld, I will let this revision fail so that master can start testing [04:50] sinzui: i can backport to 1.22 if that helps unblock the 1.22 release [04:50] wallyworld, or someone before you wake [04:51] i'll do it now [05:10] jam: hey, you around yet? [05:10] fwereade: ping goes for you too? === jw4|afk is now known as johnweldon [05:17] * thumper will try to remember to pop in later tonight to poke jam and fwereade [05:21] sinzui: 1.22 fixed also now [05:22] wallyworld, fab. My last test run I setup is at its hanging spot. I don't have a lot of hope to a last minute pass [05:22] let's hope it passes now [05:49] axw: wallyworld:jam: m tak n hammer to my solution for status sort and re-writting it in a proper string-walking-full-proper-natural-sorting way to avoid concerns :D [05:50] axw: wallyworld:jam: i'll poke u when it's ready :) tyvm for ur points and interest :P [05:50] anastasiamac: k [05:50] I'm actually playing around with a strnatcmp go library [05:50] cause I like the function [05:50] and I found a bug in the C implementation [05:52] jam: :D sorting is fun and finding bugs is just a s much fun as finding solutions === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1424777 [07:08] wallyworld, ping [07:09] waigani, I doubt you're here, but if you are PTAL: http://reviews.vapour.ws/r/1006/ [07:11] fwereade, and you? :) [09:11] dooferlad, hey there [09:14] dooferlad, how goes the port of the fix for bug 1420049 to trunk? [09:14] Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")")

[09:15] dimitern: a bit slow. Have some tests failing that I wasn't expecting. [09:15] dimitern: Hopefully not much longer [09:16] dooferlad, if you paste some logs I might be able to help [09:16] dimitern: Hasn't come to that yet, but I will do if I feel stuck. [09:17] dooferlad, ok, np [09:24] dimitern: i, just got back from soccer [09:24] hi [09:25] wallyworld, hi, it's ok I wanted you to have a look at http://reviews.vapour.ws/r/1006/ if you're around, but decided to land it [09:25] wallyworld, it just disables some openstack tests on ppc64el [09:25] dimitern: ok, i did the same thing with some pinger tests on i386 [09:25] wallyworld, and btw that branch you landed to disable pinger tests [09:26] to try and get trunk unblocked [09:26] wallyworld, I think you disabled the wrong one [09:26] oh :-( [09:26] wallyworld, most of the failures I've seen are in rootSuite.TestPingTimeout (root_test.go) - not in pinger_test.go [09:26] i thought i went by what the bug mentioned [09:27] wallyworld, however, surprisingly after your change that test also started passing :) [09:27] good :-) [09:28] dimitern: i just cecked the bug, and it did mentioned pinger_test. it also mentionedroot_test [09:28] but i tried just the pinger_test first [09:29] wallyworld, yeah, it's ok - if some other pinger tests start failing on i386 I'll submit another PR to disable them [09:29] these openstack tests, are they new failures? [09:29] they seem like old tests which have been there for a while [09:29] wallyworld, no, they're there since the beginning [09:29] so why the issues now all of a sudden [09:29] wallyworld, and also reproducible on gccgo/amd64 [09:31] wallyworld, well, they were not happening on the "deploy" ppc64 jobs, just the run-unit-tests-trusty-ppc64el-lxc [09:31] oh, ok, failed inside lxc [09:31] wallyworld, which is non-voting; and looking at the build history this job never ever passed [09:32] dimitern: is there are bug with the correct label so we can track the work to fix those tests? [09:32] wallyworld, I've tagged them with ppc64el and gccgo among others [09:32] bug 1425242 [09:32] Bug #1425242: disable failing provider/openstack tests on ppc64 until we can fix them

[09:33] dimitern: we need a bug that's not fix committed [09:33] the underlying issue is in goose, i filed an issue there and have a fix in mind [09:33] dinner ready, bbiab [09:33] wallyworld, yes - bug 1411818 [09:33] Bug #1411818: ppc64el in lxc failure: github.com_juju_juju_provider_openstack_test.localServerSuite

[10:00] morning everyone [10:00] dimitern: TheMue: dooferlad: be with you in standup in a minute [10:00] voidspace: heya [10:00] laptop issues :- [10:01] :-/ [10:01] TheMue: o/ [10:01] voidspace, o/ [10:03] dimitern: TheMue: dooferlad: now I'm installing the hangout plugin! [10:21] dooferlad, since michael is here, I'd suggest finishing the bug fix you're working on and putting the other one I've assigned to you on hold for now [10:22] dimitern: will do [10:22] dooferlad, ta! [11:07] and now, for something completely different, working in a car [11:12] dimitern: http://reviews.vapour.ws/r/985/ [11:13] dooferlad, looking [11:13] dimitern: thanks! [11:13] dooferlad, so the tests now pass - gc and gccgo? [11:14] dimitern: go, yes. I have compiled with gccgo [11:14] dimitern: testing with gccgo now [11:14] dooferlad, ok, nice [11:15] dimitern: lots of "error: reference to undefined identifier ‘testing.MainStart’" showing up [11:16] dimitern: I did make clean; go test -compiler gccgo -test.timeout=1200s github.com/juju/juju/... [11:19] dooferlad, check if go env -compiler gccgo reports the same as go env [11:20] nope that doesn't work [11:20] :-) [11:20] dooferlad, try go test -check.v -compiler gccgo inside the worker/provisioner [11:20] :) [11:22] dimitern, can i get your opinion on https://bugs.launchpad.net/juju-core/+bug/1425435 [11:22] Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 [11:22] dimitern: same problem [11:24] jamespage, I've looked at it, but can't quite tell where is that coming from - is it an api breakage (like the ports not getting populated by the megawatcher I had recently) [11:25] dooferlad, ok, I'll pull your branch and run the tests here [11:25] dimitern: is my setup broken? [11:26] dooferlad, well, considering I can run them - most likely :) [11:26] dimitern: :p [11:26] dooferlad, however, I haven't specifically installed gccgo or configured it [11:26] dimitern: I don't think I have either [11:27] dooferlad, what's your golang-go package coming from? [11:27] fwereade: just checking in to see how you and leader elections are going [11:27] dimitern: https://golang.org/dl/ [11:28] dimitern: though I am on 1.4.1 and 1.4.2 is out [11:28] dooferlad, ah, that's probably it [11:28] jam, just figured out how to deal with potentially abusive tracker clients, hopefully pushing that for review in a mo; would you give http://reviews.vapour.ws/r/987 another pass please? [11:28] dooferlad, I'm using golang-go from the trusty archive (1.2.1 - same as the CI jobs use) [11:29] dimitern, maybe - but that's breaking all our automated testing right now [11:31] jamespage, any idea what jujuclient is trying to iterate over that happens to be None? [11:34] jam, just added a couple of comments to http://reviews.vapour.ws/r/987/ -- will be adding a bug# for the open issue and would like to land after that? [11:35] looking through it now [11:35] fwereade: lgtm [11:35] jam, <3 [11:36] jam, had to change around the Tracker interface a bit -- it now issues its own Tickets which you Wait() for, rather than letting people pass their own channels in, because that eliminates a whole class of abusive client behaviour of the sort that has always bugged me about watcher [11:37] fwereade: because you may not listen on your own channel and get the Tracker stuck? [11:38] jam, essentially yes -- I think it's possible to work around that, but annoyingly complex [11:38] jam, I was trying to write a TestAbusiveClient and not having a very good time ;) [11:38] fwereade: or too good a time.... :) [11:38] jam, haha [11:43] dooferlad, reviewd [11:43] reviewed* [12:03] dimitern: ping [12:04] dimitern: I need to understand what you mean by "Clean up MAAS container addressability methods" [12:05] voidspace, hey [12:05] dimitern: can I get you to take a look at bug 1425435 [12:05] Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3

[12:05] dimitern: note that as I'm working from my laptop I don't have MaaS setup here. (Back to desktop next week - but Delia will probably have the baby by then) [12:05] (deal with voidspace first :) [12:05] dimitern: ok, sure - np [12:05] oh, that was mgz_ to dimitern not dimitern to me :-) [12:05] voidspace, I'll go back to you in a bit [12:05] dimitern: ok, np [12:06] dimitern: ah, having read the card properly I understand better anyway [12:06] mgz_, I've asked jamespage for details - any idea what jujuclient is trying to iterate over that happens to be None? [12:06] voidspace, cheers :) [12:06] dimitern: I'll just get on with it and complain if I get stuck [12:06] voidspace, thanks! [12:06] dimitern: I'll pastebin you the code [12:06] it's in lp:python-jujuclient [12:06] basically, using the allwatcher [12:07] mgz_, is it about ports then? [12:08] mgz_, it is - I can see it now at the end [12:08] dimitern: http://paste.ubuntu.com/10406919/ [12:08] the d argument there comes from the watcher [12:09] mgz_, so first off, the client needs to change and start using the port ranges instead [12:09] so, would be trivial to fix there in the python [12:09] but we should *not* be breaking apis in stable releases [12:09] mgz_, then second, looking at the code - why it's not iterating over tports if it cares to setdefault on them [12:09] and both your branch and franks seemed to attempt not to do that [12:10] tports is the output [12:10] ports is the input from the watcher [12:10] mgz_, that's the third point :) yeah - that was a backwards incompatible api change, but IIRC frankban fixed it even in 1.21 [12:10] dimitern: right, one of those branches did not in fact work [12:10] mgz_, ah, ok [12:11] mgz_, I'll look into what landed etc. [12:11] or we released the wrong thing, or something [12:11] mgz_, jamespage, where did you get the 1.21.3 binary from? is it definitely 1.21.3? [12:11] yes [12:11] ppa [12:12] allwatcher is named megawatcher now right? I'm not up to date on watcher terminology [12:16] mgz_, jamespage, well the fix for that landed in 1.21 almost 2 weeks ago - https://github.com/juju/juju/pull/1595, and it was confirmed to work with the GUI after the fix [12:16] * dimitern doesn't get it [12:17] dimitern: my assumption is the gui does in fact work, but this use of python-jujuclient doesn't [12:18] it could also be we're not actually on the right version somehow [12:18] mgz_, well, part of the reason why this was discovered in the first place is that the gui started throwing exceptions like that (I think it was juju-quickstart actually) [12:18] that change is certainly in 1.21.3 as far as I can see [12:19] mgz_, and after the fix it worked - without changing quickstart AIUI [12:22] jamespage, mgz_, I'm asking in #juju-gui for clarification [12:23] dimitern: thanks! [12:23] I agree it looks like frankban's change was aimed at covering all this [12:23] and I didn't see anything obviously wrong eyeballing the backport diff [12:28] mgz_, yeah - and python-jujuclient didn't have to change after the fix landed [12:41] dimitern: I wonderfully found three different ways of bson names: lowercase, lowerCamelCase, and dash-case. :) in our portsDoc we e.g. use dash-case opposite to the other network types :/ [12:43] TheMue, well :) we have to live with what already has bson tags, but for new ones let's use the first case [12:44] dimitern: yes, that's what I've done. it's only funny when you grep "type .*Doc struct" on state and scan those types [12:45] :) [12:58] people keep hitting issues with the 1.21 series, most of which are already resolved with 1.22 and later [12:59] we need to release 1.22.0 already and call that stable === liam_ is now known as Guest95654 [13:20] jamespage, I think I may have found the issue - are you upgrading to 1.21.3 or you're bootstrapping a new environment with 1.21.3? === kadams54-away is now known as kadams54 [14:05] jam, axw, wallyworld: updated natural order sort (catering a lot beta, i think even floating points vs IPs) [14:05] wow ok, did we need all that extra? [14:05] jam: axw:wallyworld: not catering for scientific notations :D not negative numbers [14:06] was just for a quick status sort fix right? [14:06] wallyworld: well, we wanted natural sort for any string not just by numeric suffix [14:07] wallyworld: any string containing numbers... [14:07] ok, np, if we need it. i was thinking we'd wait till needed before expending the effort [14:10] dimitern: jujubot isn't landing my code because it doesn't fix https://bugs.launchpad.net/juju-core/+bug/1424777 which you already did (https://github.com/juju/juju/pull/1673) [14:10] Bug #1424777: local-provider precise failed to upgrade