| wallyworld | 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:28 |
|---|---|---|
| mup | Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Committed by dimitern> <https://launchpad.net/bugs/1424777> | 00:29 |
| marcoceppi | jw4: http://juju.fail | 00:29 |
| jw4 | marcoceppi: beyootiful | 00:29 |
| sinzui | 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:30 |
| wallyworld | i get a 404 from that url | 00:31 |
| sinzui | wallyworld, log in as a developer or admin | 00:32 |
| jw4 | sinzui: internal canonical developers only? | 00:34 |
| sinzui | jw4, yes, sorry | 00:40 |
| jw4 | sinzui: n/m :) I think I already asked you so sorry if it feels harassing :-p | 00:41 |
| sinzui | 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:41 |
| jw4 | sinzui: eeesh. out of curiousity where are you moving the bulk of the CI infrastructure? | 00:42 |
| jw4 | sinzui: I thought I saw you say we were leaving aws for more stuff | 00:42 |
| sinzui | jw4, we aren't moving it. the lxcbr0 bug in 1.21.1 killed our old state server. We had to rebuild | 00:44 |
| jw4 | sinzui: oh, I see | 00:49 |
| anastasiamac | katco: thnx for review! | 01:02 |
| sinzui | and we have a real vivid machine | 01:20 |
| mattyw | thumper, ping? | 01:21 |
| thumper | mattyw: hey, whazzup? | 01:29 |
| === TheRealMue is now known as TheMue | ||
| axw | 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. | 02:34 |
| === johnweldon is now known as jw4|afk | ||
| anastasiamac | 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:38 |
| axw | 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:40 |
| axw | 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:41 |
| anastasiamac | 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:42 |
| anastasiamac | axw: for ur suggestion to work, there would be a additional if- to cater for empty input string | 02:43 |
| anastasiamac | axw: then traversing the string backwards | 02:43 |
| anastasiamac | axw: if- last element is digit | 02:43 |
| anastasiamac | axw: until non-digit is encountered | 02:43 |
| anastasiamac | axw: then extracting first part of input as prefix | 02:44 |
| anastasiamac | axw: and then parsing suffix into a number | 02:44 |
| anastasiamac | axw: logically | 02:44 |
| anastasiamac | axw: it's easier to read - get this 2 parts from string using regex | 02:44 |
| anastasiamac | axw: :P | 02:44 |
| anastasiamac | s/this/these | 02:45 |
| axw | and then check if the number is missing... and then parse to a number.. it's almost identical. | 02:45 |
| anastasiamac | axw: :D except for les lines of code :D | 02:45 |
| axw | anastasiamac: http://paste.ubuntu.com/10400349/ | 02:47 |
| axw | anastasiamac: as I said, literally the same # LOC :) | 02:48 |
| * axw goes back to reviewing tmpfs | 02:49 | |
| anastasiamac | axw: :D | 02:51 |
| axw | wallyworld: reviewed your tmpfs branch | 02:55 |
| wallyworld | ty | 02:55 |
| wallyworld | axw: anastasiamac: i did a benchmark and on 20000 splits, regexp takes 0.06s longer. i'm ok with that :-) | 03:06 |
| wallyworld | im the regexp code is easier to read, but ymmv | 03:07 |
| anastasiamac | wallyworld: i agreee - reg exp is easier to read | 03:08 |
| anastasiamac | wallyworld: howver i have detected a regexp allergy in most go programmers towards regexp on other occasions too | 03:08 |
| wallyworld | them there is fighting words | 03:09 |
| anastasiamac | wallyworld: since most likely skillset of maintaince (and current dev) team is go, mayb idiomatic go is "the path of less resisitance"? | 03:09 |
| wallyworld | regexp is nit not idiotmatic Go is it? | 03:09 |
| wallyworld | not not i mean | 03:09 |
| anastasiamac | no, but the snippet axw pasted above is idiomatic | 03:10 |
| === urulama_ is now known as urulama | ||
| axw | 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 |
| anastasiamac | wallyworld: m on the fence on that but "when in Rome...", sorry "when in Go.." | 03:11 |
| axw | it may be that there's some correlation :) | 03:11 |
| axw | *I* don't find my version any more difficult to read, but if I'm outnumbered then feel free to revert. | 03:12 |
| anastasiamac | axw: i personaly have a thing against string examinations, so will always vote for regexp use in complex cases | 03:12 |
| anastasiamac | axw: hwever, here m not feeling the need to come heavy on either side :D | 03:13 |
| axw | anastasiamac: sure, I agree. I don't think this is a complex case - I guess we have different cutoff points | 03:13 |
| anastasiamac | axw: it's so trivial that m happy to follow either u or wallyworld | 03:13 |
| anastasiamac | axw: since u've gone as far as writting a snippet, I thought I;d concur | 03:13 |
| wallyworld | i don't mind either way | 03:14 |
| anastasiamac | axw: but then wallyworldwen and benchmarked.. | 03:14 |
| wallyworld | just leave it as whatever is there now | 03:14 |
| anastasiamac | axw: wallyworld now i just need a 3rd party, opinion i think :D | 03:14 |
| wallyworld | 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:15 |
| anastasiamac | axw: wallyworld: k... :D since neither of u want to **really*** put ur foot down (m having fun here)... | 03:16 |
| anastasiamac | axw: wallyworld: and there is more important things to do (thnx ian for executive directive) | 03:17 |
| anastasiamac | axw: wallyworld: and this PR has my name on it and I like regexp approach | 03:17 |
| anastasiamac | axw: wallyworld: i'll revert | 03:17 |
| axw | anastasiamac: ok. | 03:17 |
| anastasiamac | axw: tyvm for showing me a way to do awesome string examination tho :D | 03:18 |
| wallyworld | gawd, we really need to do this over a beer or 6 | 03:18 |
| anastasiamac | wallyworld: or a cider...? :D | 03:18 |
| wallyworld | i wouldn't revert now, andrew's solution is fine | 03:18 |
| wallyworld | yeah, or a cider | 03:18 |
| anastasiamac | wallyworld: why not? CI is blocked anyway | 03:20 |
| anastasiamac | wallyworld: and looking for flights is killing my buzz - there is no simple route from a ot b | 03:21 |
| wallyworld | you decide :-) | 03:21 |
| axw | wallyworld: out of interest, what was the input you used to benchmark? :) | 03:23 |
| axw | regexp will be slower with a longer prefix | 03:23 |
| wallyworld | axw: a shortish string, eg "myservice/12345" | 03:25 |
| anastasiamac | axw: wallyworld: i think mayb we should upgrade beer and cider to harder liquor (menn0's scotch?) | 03:25 |
| wallyworld | i agree regexp will always be more expensive | 03:25 |
| wallyworld | 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:27 |
| anastasiamac | wallyworld: is this realistic for juju names 30 char string and up to a 6 digit number (m guessing numeric suffix here) | 03:30 |
| anastasiamac | wallyworld: ? | 03:30 |
| wallyworld | i can't recall if there's a length limit on service/unit names | 03:31 |
| wallyworld | most are shorter than that | 03:31 |
| wallyworld | 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:47 |
| sinzui | 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 |
| sinzui | wallyworld, and master doesn't get unblocked until master passed | 03:49 |
| sinzui | passed | 03:49 |
| sinzui | wallyworld, I can start master teasting now, but then I don't release 1.22 | 03:49 |
| wallyworld | 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:50 |
| wallyworld | i wish we could just drop i386, it's 2015 after all | 03:51 |
| wallyworld | i also wish we had hardware to do more than one series test at a time | 03:52 |
| wallyworld | or i guess we'd need another jenkins set up | 03:52 |
| beisner | hi wallyworld, ? for ya: is there a way to destroy an environment but keep the bootstrap node? | 03:52 |
| wallyworld | not that I know of right now, but that's coming soon | 03:53 |
| wallyworld | thumper: the above will be in 1.23 right? | 03:53 |
| sinzui | wallyworld, ec2 healed 4 hours ago | 03:53 |
| wallyworld | good :-) | 03:54 |
| * thumper looks up | 03:54 | |
| thumper | wat? | 03:54 |
| wallyworld | thumper: destroy env but keep state server | 03:54 |
| beisner | 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 |
| sinzui | and the test results for 386 in trusty and precise on other machines also fail | 03:54 |
| thumper | wallyworld: not with the current way things work | 03:54 |
| thumper | wallyworld, beisner: when we have multiple environments, yes | 03:54 |
| sinzui | wallyworld, so unless I can cheat juju shitty test suite, someone needs to change it | 03:54 |
| wallyworld | thumper: yeah, that's what i meant | 03:54 |
| thumper | wallyworld: not in a nice friendly way | 03:55 |
| thumper | it'll be possible but a little awkward | 03:55 |
| sinzui | wallyworld, in summary, the 386 tests fail on precise and trusty, and in Hp and aws. that is very bad | 03:55 |
| thumper | until we get the new CLI working nicely with it | 03:55 |
| wallyworld | 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 |
| wallyworld | beisner: see thumper's answer above | 03:55 |
| sinzui | 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 |
| beisner | ok tyvm | 03:56 |
| thumper | wallyworld: I fully expect to have multiple environment creation landed in the next day or so | 03:56 |
| sinzui | wallyworld, I am fine to drop 386...and we can stop make windows clients which are 386 too | 03:56 |
| thumper | under a feature flag | 03:56 |
| wallyworld | 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 |
| sinzui | 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:57 |
| wallyworld | sinzui: yeah, didn't mean to whinge to you, just venting | 03:58 |
| sinzui | 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:58 |
| wallyworld | who still runs windows on i386? anyone? | 03:59 |
| wallyworld | you can't even buy a 386 version of windows since how long ago? | 04:00 |
| sinzui | wallyworld, the os is 386 | 04:00 |
| sinzui | wallyworld, and windows developers don't upgrade often | 04:00 |
| wallyworld | really? i thought win 7 was 64 bit | 04:00 |
| sinzui | so the reasoning is windows developers need 386 | 04:00 |
| sinzui | wallyworld, it didn't sell that well | 04:00 |
| wallyworld | at least that's what my last 2 laptops shipped with since 6 years ago | 04:01 |
| wallyworld | 64 bit | 04:01 |
| wallyworld | no 386 to be seen | 04:01 |
| sinzui | 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:02 |
| wallyworld | rightio, i'll skip those ping tests. the current pinger implementation is flwed anyway | 04:03 |
| wallyworld | and we want to replace it | 04:03 |
| sinzui | 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 |
| wallyworld | ok, hope it passes | 04:05 |
| wallyworld | wow 40 minutes | 04:05 |
| wallyworld | how long do the 386 tests take | 04:05 |
| sinzui | 140minutes to 2h5m | 04:06 |
| sinzui | yeah, it is that bad | 04:06 |
| wallyworld | and the and64 ones? | 04:06 |
| sinzui | 20-40 minutes depending on the host. ec2 is slower that the slaves or the ppc64el hardware | 04:06 |
| sinzui | wallyworld, but consider the arm64 tests, they take 18 hours | 04:07 |
| wallyworld | serious, so say 30mins for amd64 and > 4x that for i386 | 04:07 |
| wallyworld | wft | 04:07 |
| wallyworld | sinzui: and you are still trying to get these tests to pass to bless 1.22 right? | 04:07 |
| sinzui | wallyworld, aws wont allow you to deploy 386 on a large instance, which is why we built our own | 04:08 |
| sinzui | wallyworld, yes to bless 1.22 | 04:08 |
| wallyworld | sigh | 04:08 |
| wallyworld | sinzui: i will ask alexis about dropping support for i386; in the meantime, i will skip the pinger tests in trunk. | 04:09 |
| sinzui | +1 | 04:09 |
| wallyworld | if i need to skip the pinger tests in 1.22 let me know | 04:09 |
| wallyworld | man, master should have been unblocked by now | 04:09 |
| sinzui | wallyworld, use __jfdi__ to land that | 04:09 |
| wallyworld | yep | 04:10 |
| wallyworld | sinzui: i'll only skip on i386, vivid will still fail, we need to fix the tests | 04:10 |
| sinzui | 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 |
| sinzui | wallyworld, you will need to fix those for 1.23 since we know vivid will be in beta | 04:11 |
| wallyworld | bug is currently medium, should be high or critical then if vivid is blocked | 04:12 |
| sinzui | wallyworld, vivid was a moving target. IT is now close to stable | 04:12 |
| wallyworld | i know whole suite needs to pass, but sad that i386 failures block landings | 04:12 |
| wallyworld | sinzui: as soon as we add vivid voting tests, the bug can become critical? | 04:13 |
| sinzui | wallyworld, yep | 04:13 |
| wallyworld | axw: can i please have a trivial review to help unbock master | 04:22 |
| wallyworld | http://reviews.vapour.ws/r/1003/ | 04:22 |
| axw | wallyworld: looking | 04:23 |
| axw | wallyworld: done | 04:24 |
| wallyworld | ty | 04:24 |
| * jam goes to get his car serviced for a while | 04:28 | |
| wallyworld | sinzui: that pinger test suite is now disabled for i386 on trunk | 04:48 |
| sinzui | thank you wallyworld | 04:49 |
| wallyworld | sinzui: so, i think it's now about 4 hours or so till trunk is blessed by CI? | 04:49 |
| sinzui | 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:49 |
| sinzui | wallyworld, I will let this revision fail so that master can start testing | 04:50 |
| wallyworld | sinzui: i can backport to 1.22 if that helps unblock the 1.22 release | 04:50 |
| sinzui | wallyworld, or someone before you wake | 04:50 |
| wallyworld | i'll do it now | 04:51 |
| thumper | jam: hey, you around yet? | 05:10 |
| thumper | fwereade: ping goes for you too? | 05:10 |
| === jw4|afk is now known as johnweldon | ||
| * thumper will try to remember to pop in later tonight to poke jam and fwereade | 05:17 | |
| wallyworld | sinzui: 1.22 fixed also now | 05:21 |
| sinzui | 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 |
| wallyworld | let's hope it passes now | 05:22 |
| anastasiamac | 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:49 |
| anastasiamac | axw: wallyworld:jam: i'll poke u when it's ready :) tyvm for ur points and interest :P | 05:50 |
| jam | anastasiamac: k | 05:50 |
| jam | I'm actually playing around with a strnatcmp go library | 05:50 |
| jam | cause I like the function | 05:50 |
| jam | and I found a bug in the C implementation | 05:50 |
| anastasiamac | jam: :D sorting is fun and finding bugs is just a s much fun as finding solutions | 05:52 |
| === 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 | ||
| dimitern | wallyworld, ping | 07:08 |
| dimitern | waigani, I doubt you're here, but if you are PTAL: http://reviews.vapour.ws/r/1006/ | 07:09 |
| dimitern | fwereade, and you? :) | 07:11 |
| dimitern | dooferlad, hey there | 09:11 |
| dimitern | dooferlad, how goes the port of the fix for bug 1420049 to trunk? | 09:14 |
| mup | Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:In Progress by dooferlad> <juju-core 1.22:Fix Committed by axwalk> <https://launchpad.net/bugs/1420049> | 09:14 |
| dooferlad | dimitern: a bit slow. Have some tests failing that I wasn't expecting. | 09:15 |
| dooferlad | dimitern: Hopefully not much longer | 09:15 |
| dimitern | dooferlad, if you paste some logs I might be able to help | 09:16 |
| dooferlad | dimitern: Hasn't come to that yet, but I will do if I feel stuck. | 09:16 |
| dimitern | dooferlad, ok, np | 09:17 |
| wallyworld | dimitern: i, just got back from soccer | 09:24 |
| wallyworld | hi | 09:24 |
| dimitern | 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 |
| dimitern | wallyworld, it just disables some openstack tests on ppc64el | 09:25 |
| wallyworld | dimitern: ok, i did the same thing with some pinger tests on i386 | 09:25 |
| dimitern | wallyworld, and btw that branch you landed to disable pinger tests | 09:25 |
| wallyworld | to try and get trunk unblocked | 09:26 |
| dimitern | wallyworld, I think you disabled the wrong one | 09:26 |
| wallyworld | oh :-( | 09:26 |
| dimitern | wallyworld, most of the failures I've seen are in rootSuite.TestPingTimeout (root_test.go) - not in pinger_test.go | 09:26 |
| wallyworld | i thought i went by what the bug mentioned | 09:26 |
| dimitern | wallyworld, however, surprisingly after your change that test also started passing :) | 09:27 |
| wallyworld | good :-) | 09:27 |
| wallyworld | dimitern: i just cecked the bug, and it did mentioned pinger_test. it also mentionedroot_test | 09:28 |
| wallyworld | but i tried just the pinger_test first | 09:28 |
| dimitern | wallyworld, yeah, it's ok - if some other pinger tests start failing on i386 I'll submit another PR to disable them | 09:29 |
| wallyworld | these openstack tests, are they new failures? | 09:29 |
| wallyworld | they seem like old tests which have been there for a while | 09:29 |
| dimitern | wallyworld, no, they're there since the beginning | 09:29 |
| wallyworld | so why the issues now all of a sudden | 09:29 |
| dimitern | wallyworld, and also reproducible on gccgo/amd64 | 09:29 |
| dimitern | wallyworld, well, they were not happening on the "deploy" ppc64 jobs, just the run-unit-tests-trusty-ppc64el-lxc | 09:31 |
| wallyworld | oh, ok, failed inside lxc | 09:31 |
| dimitern | wallyworld, which is non-voting; and looking at the build history this job never ever passed | 09:31 |
| wallyworld | dimitern: is there are bug with the correct label so we can track the work to fix those tests? | 09:32 |
| dimitern | wallyworld, I've tagged them with ppc64el and gccgo among others | 09:32 |
| dimitern | bug 1425242 | 09:32 |
| mup | Bug #1425242: disable failing provider/openstack tests on ppc64 until we can fix them <gccgo> <papercut> <ppc64el> <reliability> <test-failure> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Committed by dimitern> <https://launchpad.net/bugs/1425242> | 09:32 |
| wallyworld | dimitern: we need a bug that's not fix committed | 09:33 |
| dimitern | the underlying issue is in goose, i filed an issue there and have a fix in mind | 09:33 |
| wallyworld | dinner ready, bbiab | 09:33 |
| dimitern | wallyworld, yes - bug 1411818 | 09:33 |
| mup | Bug #1411818: ppc64el in lxc failure: github.com_juju_juju_provider_openstack_test.localServerSuite <ci> <intermittent-failure> <ppc64el> <test-failure> <juju-core:Triaged by dimitern> <https://launchpad.net/bugs/1411818> | 09:33 |
| voidspace | morning everyone | 10:00 |
| voidspace | dimitern: TheMue: dooferlad: be with you in standup in a minute | 10:00 |
| TheMue | voidspace: heya | 10:00 |
| voidspace | laptop issues :- | 10:00 |
| voidspace | :-/ | 10:01 |
| voidspace | TheMue: o/ | 10:01 |
| dimitern | voidspace, o/ | 10:01 |
| voidspace | dimitern: TheMue: dooferlad: now I'm installing the hangout plugin! | 10:03 |
| dimitern | 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:21 |
| dooferlad | dimitern: will do | 10:22 |
| dimitern | dooferlad, ta! | 10:22 |
| perrito666 | and now, for something completely different, working in a car | 11:07 |
| dooferlad | dimitern: http://reviews.vapour.ws/r/985/ | 11:12 |
| dimitern | dooferlad, looking | 11:13 |
| dooferlad | dimitern: thanks! | 11:13 |
| dimitern | dooferlad, so the tests now pass - gc and gccgo? | 11:13 |
| dooferlad | dimitern: go, yes. I have compiled with gccgo | 11:14 |
| dooferlad | dimitern: testing with gccgo now | 11:14 |
| dimitern | dooferlad, ok, nice | 11:14 |
| dooferlad | dimitern: lots of "error: reference to undefined identifier ‘testing.MainStart’" showing up | 11:15 |
| dooferlad | dimitern: I did make clean; go test -compiler gccgo -test.timeout=1200s github.com/juju/juju/... | 11:16 |
| dimitern | dooferlad, check if go env -compiler gccgo reports the same as go env | 11:19 |
| dimitern | nope that doesn't work | 11:20 |
| dooferlad | :-) | 11:20 |
| dimitern | dooferlad, try go test -check.v -compiler gccgo inside the worker/provisioner | 11:20 |
| dimitern | :) | 11:20 |
| jamespage | dimitern, can i get your opinion on https://bugs.launchpad.net/juju-core/+bug/1425435 | 11:22 |
| mup | Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <juju-core:New> <https://launchpad.net/bugs/1425435> | 11:22 |
| dooferlad | dimitern: same problem | 11:22 |
| dimitern | 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:24 |
| dimitern | dooferlad, ok, I'll pull your branch and run the tests here | 11:25 |
| dooferlad | dimitern: is my setup broken? | 11:25 |
| dimitern | dooferlad, well, considering I can run them - most likely :) | 11:26 |
| dooferlad | dimitern: :p | 11:26 |
| dimitern | dooferlad, however, I haven't specifically installed gccgo or configured it | 11:26 |
| dooferlad | dimitern: I don't think I have either | 11:26 |
| dimitern | dooferlad, what's your golang-go package coming from? | 11:27 |
| jam | fwereade: just checking in to see how you and leader elections are going | 11:27 |
| dooferlad | dimitern: https://golang.org/dl/ | 11:27 |
| dooferlad | dimitern: though I am on 1.4.1 and 1.4.2 is out | 11:28 |
| dimitern | dooferlad, ah, that's probably it | 11:28 |
| fwereade | 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 |
| dimitern | dooferlad, I'm using golang-go from the trusty archive (1.2.1 - same as the CI jobs use) | 11:28 |
| jamespage | dimitern, maybe - but that's breaking all our automated testing right now | 11:29 |
| dimitern | jamespage, any idea what jujuclient is trying to iterate over that happens to be None? | 11:31 |
| fwereade | 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:34 |
| jam | looking through it now | 11:35 |
| jam | fwereade: lgtm | 11:35 |
| fwereade | jam, <3 | 11:35 |
| fwereade | 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:36 |
| jam | fwereade: because you may not listen on your own channel and get the Tracker stuck? | 11:37 |
| fwereade | jam, essentially yes -- I think it's possible to work around that, but annoyingly complex | 11:38 |
| fwereade | jam, I was trying to write a TestAbusiveClient and not having a very good time ;) | 11:38 |
| jam | fwereade: or too good a time.... :) | 11:38 |
| fwereade | jam, haha | 11:38 |
| dimitern | dooferlad, reviewd | 11:43 |
| dimitern | reviewed* | 11:43 |
| voidspace | dimitern: ping | 12:03 |
| voidspace | dimitern: I need to understand what you mean by "Clean up MAAS container addressability methods" | 12:04 |
| dimitern | voidspace, hey | 12:05 |
| mgz_ | dimitern: can I get you to take a look at bug 1425435 | 12:05 |
| mup | Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1425435> | 12:05 |
| voidspace | 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 |
| mgz_ | (deal with voidspace first :) | 12:05 |
| voidspace | dimitern: ok, sure - np | 12:05 |
| voidspace | oh, that was mgz_ to dimitern not dimitern to me :-) | 12:05 |
| dimitern | voidspace, I'll go back to you in a bit | 12:05 |
| voidspace | dimitern: ok, np | 12:05 |
| voidspace | dimitern: ah, having read the card properly I understand better anyway | 12:06 |
| dimitern | mgz_, I've asked jamespage for details - any idea what jujuclient is trying to iterate over that happens to be None? | 12:06 |
| dimitern | voidspace, cheers :) | 12:06 |
| voidspace | dimitern: I'll just get on with it and complain if I get stuck | 12:06 |
| dimitern | voidspace, thanks! | 12:06 |
| mgz_ | dimitern: I'll pastebin you the code | 12:06 |
| mgz_ | it's in lp:python-jujuclient | 12:06 |
| mgz_ | basically, using the allwatcher | 12:06 |
| dimitern | mgz_, is it about ports then? | 12:07 |
| dimitern | mgz_, it is - I can see it now at the end | 12:08 |
| mgz_ | dimitern: http://paste.ubuntu.com/10406919/ | 12:08 |
| mgz_ | the d argument there comes from the watcher | 12:08 |
| dimitern | mgz_, so first off, the client needs to change and start using the port ranges instead | 12:09 |
| mgz_ | so, would be trivial to fix there in the python | 12:09 |
| mgz_ | but we should *not* be breaking apis in stable releases | 12:09 |
| dimitern | mgz_, then second, looking at the code - why it's not iterating over tports if it cares to setdefault on them | 12:09 |
| mgz_ | and both your branch and franks seemed to attempt not to do that | 12:09 |
| mgz_ | tports is the output | 12:10 |
| mgz_ | ports is the input from the watcher | 12:10 |
| dimitern | 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 |
| mgz_ | dimitern: right, one of those branches did not in fact work | 12:10 |
| dimitern | mgz_, ah, ok | 12:10 |
| dimitern | mgz_, I'll look into what landed etc. | 12:11 |
| mgz_ | or we released the wrong thing, or something | 12:11 |
| dimitern | mgz_, jamespage, where did you get the 1.21.3 binary from? is it definitely 1.21.3? | 12:11 |
| jamespage | yes | 12:11 |
| jamespage | ppa | 12:11 |
| mgz_ | allwatcher is named megawatcher now right? I'm not up to date on watcher terminology | 12:12 |
| dimitern | 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:16 | |
| mgz_ | dimitern: my assumption is the gui does in fact work, but this use of python-jujuclient doesn't | 12:17 |
| mgz_ | it could also be we're not actually on the right version somehow | 12:18 |
| dimitern | 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 |
| mgz_ | that change is certainly in 1.21.3 as far as I can see | 12:18 |
| dimitern | mgz_, and after the fix it worked - without changing quickstart AIUI | 12:19 |
| dimitern | jamespage, mgz_, I'm asking in #juju-gui for clarification | 12:22 |
| mgz_ | dimitern: thanks! | 12:23 |
| mgz_ | I agree it looks like frankban's change was aimed at covering all this | 12:23 |
| mgz_ | and I didn't see anything obviously wrong eyeballing the backport diff | 12:23 |
| dimitern | mgz_, yeah - and python-jujuclient didn't have to change after the fix landed | 12:28 |
| TheMue | 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:41 |
| dimitern | TheMue, well :) we have to live with what already has bson tags, but for new ones let's use the first case | 12:43 |
| TheMue | 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:44 |
| dimitern | :) | 12:45 |
| dimitern | people keep hitting issues with the 1.21 series, most of which are already resolved with 1.22 and later | 12:58 |
| dimitern | we need to release 1.22.0 already and call that stable | 12:59 |
| === liam_ is now known as Guest95654 | ||
| dimitern | 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? | 13:20 |
| === kadams54-away is now known as kadams54 | ||
| anastasiamac | jam, axw, wallyworld: updated natural order sort (catering a lot beta, i think even floating points vs IPs) | 14:05 |
| wallyworld | wow ok, did we need all that extra? | 14:05 |
| anastasiamac | jam: axw:wallyworld: not catering for scientific notations :D not negative numbers | 14:05 |
| wallyworld | was just for a quick status sort fix right? | 14:06 |
| anastasiamac | wallyworld: well, we wanted natural sort for any string not just by numeric suffix | 14:06 |
| anastasiamac | wallyworld: any string containing numbers... | 14:07 |
| wallyworld | ok, np, if we need it. i was thinking we'd wait till needed before expending the effort | 14:07 |
| dooferlad | 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 |
| mup | Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Fix Committed by dimitern> <juju-core 1.22:Fix Released by dimitern> <https://launchpad.net/bugs/1424777> | 14:10 |
| jam | anastasiamac: https://github.com/jameinel/strnatcmp/tree/master/src/strnatcmp | 14:10 |
| dooferlad | dimitern: who can assist jujubot in understanding? | 14:10 |
| mgz_ | dimitern: it was an upgrade to 1.21.3 | 14:11 |
| jam | anastasiamac: where is your version, I seem to be missing it in reviews.vapour.ws | 14:11 |
| mgz_ | I think | 14:11 |
| jam | ah, just at the end | 14:11 |
| mgz_ | but he just tried with a fresh deploy and it got the same error | 14:11 |
| mgz_ | 1.21.3 client and 1.21.3 server | 14:12 |
| rick_h_ | jam: morning, did the guys get you the macaroon info you needed for that spec review for the new CS api spec and did that make sense? | 14:12 |
| anastasiamac | jam: i kind of disagree with skipping spaces... i think that "1 a" and "1a" may need to b treated differently..? | 14:12 |
| jam | anastasiamac: my one concern about unicode.IsDigit() is that what do we do about numbers that aren't 0-9, is it actually valid to mix non-latin chars | 14:12 |
| dimitern | dooferlad, it's fine - the blocker will be lifted when the bug is Fix Released | 14:13 |
| dooferlad | dimitern: ah, OK. | 14:13 |
| jam | anastasiamac: you also don't check how "foo01" sorts compared to "foo2" | 14:15 |
| dooferlad | dimitern, voidspace: So, about this MAAS code cleanup. There was talk of pairing. I am available now for a little over an hour. | 14:15 |
| dimitern | dooferlad, ok, voidspace how about you? | 14:16 |
| mgz_ | dooferlad: wanted a clean run with dimitern's fix but the maas jobs are failing atm: <http://reports.vapour.ws/releases/2380> | 14:16 |
| jam | anastasiamac: I kind of like the idea of 'foo 1' and 'foo 2' and 'foo 3' sorting accordingly | 14:16 |
| mgz_ | dooferlad: I'm reasonably sure that's our problem, not a regression on trunk, but want to check | 14:16 |
| === Murali_ is now known as Murali | ||
| jam | I don't think *humans* think of number of spaces as significant for sorting most times | 14:17 |
| dooferlad | mgz_: thanks for that info. | 14:18 |
| anastasiamac | jam: just did a test for []string{"foo2", "foo01"} and got []string{"foo01", "foo2"} | 14:18 |
| anastasiamac | jam: is it not right? | 14:18 |
| perrito666 | hey, still locked? :( | 14:18 |
| jam | anastasiamac: I didn't say anything about your correctness, just that it wasn't tested. :) | 14:18 |
| anastasiamac | jam:jam oh :D i'll add testnaturallyfoo :D | 14:19 |
| jam | anastasiamac: probably the big difference implementation-wise is that mine does a single pass, though yours might do only 2 passes | 14:19 |
| jam | it definitely does 2, and it chops the string up (though in go that could be a cheap splicing implementation, though I *think* it actually allocates a new array?) | 14:20 |
| anastasiamac | jam: sounds gr8 :D plz propose and let's plug it before feature freeze :) | 14:22 |
| anastasiamac | jam: r u goingt to propose it to utils? | 14:23 |
| dimitern | mgz_, from what I can see - all of the listed failing jobs haven't tried my fix (6742f589e738eb94b514463438893f7a90a75939), but are struggling on the previous one (a1a088dd000ae742c4bf70f95a2b942068b41be5) | 14:23 |
| dimitern | (that's for 1.23 - for 1.22 is better) | 14:23 |
| mgz_ | yeah, 1.22 went through | 14:25 |
| sinzui | dimitern, natefinch 1.22 is failing because unit-tests time out. I don't even know what to put in the bug report yest | 14:32 |
| sinzui | dimitern, natefinch : I have lowered the number of retests for i386 so that 1.22 can quickly fail so that we can test and unblock 1.23 (master) | 14:33 |
| dimitern | sinzui, I vote to skip these failing tests in cmd/juju/ for i386 | 14:34 |
| jam | anastasiamac: ... well one difficulty with yours and a 10000 digit string is that ParseFloat aborts :) | 14:34 |
| jam | I don't know whether that actually matters | 14:34 |
| sinzui | dimitern, natefinch I am fine with skipping tests in 386. The failures are different in hp/aws precise/trusty too. | 14:35 |
| anastasiamac | jam: m very happy with urs :D r u plan n to propose it? :P | 14:35 |
| jam | anastasiamac: well, I was trying to figure out if the performance actually is different, main problem comparing them is that yours is only defined in terms of sort, vs a compare | 14:36 |
| jam | at least your big O for lots of parts should be ok | 14:36 |
| jam | anastasiamac: anyway, not today, as I'm way past EOD and need to make dinner | 14:37 |
| jam | anastasiamac: I would say that at the least your natural sort code shouldn't live in "cmd/juju" | 14:37 |
| anastasiamac | jam: m not comfortable with mine being a util for any purpose (besides performance, I can think of cases that rn't catered 4...) | 14:38 |
| TheMue | dimitern: the cleaning is in for review at http://reviews.vapour.ws/r/1009/ | 14:39 |
| dimitern | TheMue, thanks, will look in a bit | 14:40 |
| TheMue | dimitern: ta | 14:40 |
| === niemeyer_ is now known as niemeyer | ||
| perrito666 | natefinch: ericsnow I am caught with other things, Ill be missing standup today | 15:04 |
| natefinch | perrito666: ok | 15:04 |
| sinzui | dimitern, your ppc64el+lxc fix works. we have a pass for run-unit-tests-trusty-ppc64el-lxc | 15:12 |
| dimitern | sinzui, for the first time ever! :) | 15:16 |
| perrito666 | sweeet | 15:16 |
| voidspace | dooferlad: just missed you before, I'd just gone on lunch! | 15:16 |
| alexisb | voidspace, heya | 15:16 |
| alexisb | voidspace, what is the baby status? | 15:17 |
| voidspace | alexisb: hi | 15:17 |
| beisner | dimitern, fyi, also affected by this, added workaround to https://bugs.launchpad.net/juju-core/+bug/1425435 | 15:17 |
| mup | Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1425435> | 15:17 |
| voidspace | alexisb: baby still in womb | 15:17 |
| voidspace | alexisb: due for final release tomorrow... | 15:18 |
| alexisb | exciting | 15:18 |
| voidspace | alexisb: maybe delayed for last minute bug fixing, we'll see | 15:18 |
| voidspace | alexisb: yeah, really looking forward to meeting the new creature. To the actual birth itself not so much... | 15:18 |
| ericsnow | voidspace \o/ | 15:18 |
| voidspace | ericsnow: hi | 15:18 |
| ericsnow | voidspace: I'm so happy for you! | 15:18 |
| dimitern | beisner, thanks! | 15:19 |
| alexisb | voidspace, totally understand, but it is soooo worth it | 15:19 |
| voidspace | ericsnow: thanks | 15:19 |
| voidspace | alexisb: yep | 15:19 |
| alexisb | dimitern, beisner does that mean 1425435 is a deployer bug? | 15:21 |
| alexisb | I should say a result of a deployer bug? | 15:21 |
| ericsnow | if anyone has a spare few minutes, I could use a review on http://reviews.vapour.ws/r/1002/ | 15:21 |
| beisner | alexisb, i'd call it a python-jujuclient bug since that's where a 1-liner fix can be made. | 15:21 |
| alexisb | beisner, ack | 15:22 |
| alexisb | mgz_, where does that leave us with trunk being blocked? | 15:22 |
| beisner | alexisb, but i'll defer to dimitern & co. who are more familiar with these things ;-) | 15:22 |
| dimitern | alexisb, I don't know what it is anymore - it's the same issue as bug 1420403 which was fixed (confirmed and released) | 15:23 |
| mup | Bug #1420403: juju-quickstart: bad API server response: 'NoneType' object is not iterable <api> <ci> <network> <regression> <juju-core:Fix Released by frankban> | 15:23 |
| mup | <juju-core 1.21:Fix Released by frankban> <juju-core 1.22:Fix Committed by frankban> <juju-quickstart:Invalid by frankban> <https://launchpad.net/bugs/1420403> | 15:23 |
| dimitern | beisner, the root cause was a backwards-incompatible api change in juju | 15:23 |
| mgz_ | alexisb: hoping to unblock shortly - getting a ci run against master is pending, have been tied up on 1.22 and slow i386 test job | 15:24 |
| dimitern | but that bug ^^ fixes it, and it's not reproducible anymore with juju-quickstart, which also uses python-jujuclient | 15:24 |
| alexisb | mgz_, thanks and please reach out asap if things are still blocked | 15:24 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1424777 1425569 | ||
| sinzui | dimitern, and we test quickstart with every revision on maas, hp, joyent, and aws. We get passes | 16:01 |
| dimitern | sinzui, yeah - I've verified everything I can think of, even rebuilding 1.21.3 from the tag and comparing the md5sum in the stable ppa for amd64/trusty - they don't match, but that might be because my setup is different | 16:06 |
| dimitern | I'm still not convinced despite the version is 1.21.3, but I'm experimenting now to see what I get out of the megawatcher as UnitInfo changes | 16:07 |
| sinzui | dimitern, natefinch : I reluctantly reported a regression in the 386 test suite. I gathered a lot of logs both the official tests and the test we prefer to run. bug 1425569 | 16:10 |
| mup | Bug #1425569: i386 unit-tests fail <ci> <i386> <precise> <regression> <test-failure> <trusty> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1425569> | 16:10 |
| dimitern | sinzui, I have an almost ready solution for this - disabling a few tests on 386 | 16:12 |
| sinzui | +1 | 16:15 |
| dooferlad | voidspace: time to hack on MAAS stuff? | 16:21 |
| voidspace | dooferlad: I think I still need some clarification from dimitern | 16:21 |
| voidspace | dimitern: I've read through your changes to EC2 a couple of times | 16:22 |
| voidspace | dimitern: whilst updating my vm etc, etc, etc *sigh* | 16:22 |
| voidspace | dimitern: I've added the environs.NetworkingEnviron interface check to the maasEnviron as that looks good | 16:22 |
| voidspace | dimitern: the rest of your changes are just logging improvements and general improvements, right? | 16:23 |
| voidspace | dimitern: no actual api changes | 16:23 |
| voidspace | dooferlad: did you manage to get container addressability working with MaaS? | 16:23 |
| voidspace | dooferlad: or alternatively, work out why it doesn't work | 16:23 |
| voidspace | dooferlad: because that's even more important than the cleanup I would think | 16:24 |
| voidspace | dooferlad: we can pair on that | 16:24 |
| dimitern | voidspace, right | 16:24 |
| voidspace | dooferlad: you can "drive" as I don't have maas on this machine | 16:24 |
| voidspace | dimitern: ok, cool | 16:24 |
| voidspace | dimitern: just checking I wasn't missing something important | 16:24 |
| dimitern | voidspace, most of them are logging/error messages reporting, however the important bits are in the tests | 16:24 |
| voidspace | ah | 16:24 |
| voidspace | I didn't read the tests thoroughly, they looked mostly like consequences of error message changes | 16:25 |
| voidspace | and who cares about tests anyway... | 16:25 |
| dimitern | voidspace, maas should return 95% the same result of NetworkInterfaces() as EC2 (same fields set) | 16:25 |
| voidspace | ah right | 16:25 |
| voidspace | dimitern: ok, so that's worth double checking and we can pair on that | 16:25 |
| dimitern | voidspace, e.g. ConfigType: Config.DHCP, Address is set to the first NIC's address, ExtraConfig: nil, GatewayAddress - nil | 16:26 |
| voidspace | I did see those changes | 16:26 |
| voidspace | in the tests | 16:26 |
| voidspace | cool | 16:26 |
| voidspace | dooferlad: ^^ you get all that? | 16:26 |
| voidspace | dooferlad: have you seen dimitern's branch? | 16:26 |
| voidspace | dimitern: thanks | 16:26 |
| dooferlad | voidspace: I have seen his branch. I had a similar impression to you :-) | 16:26 |
| dimitern | voidspace, well, maas can actually set both the interfaceName and vlanTag fields of InterfaceInfo / SubnetInfo | 16:27 |
| voidspace | yep | 16:27 |
| voidspace | dimitern: it should have what EC2 has as a minimum | 16:27 |
| dooferlad | voidspace: Seems like there are only minor changes in tests as well. | 16:27 |
| voidspace | dooferlad: the important thing to check is that the maasEnviron fills in the fields in the same way as EC2 | 16:27 |
| voidspace | dooferlad: and those are now checked explicitly in the tests | 16:28 |
| dimitern | voidspace, but otherwise, think about how are the networkingEnviron methods in maas behaving - i.e. same(or similar) errors returned for same/similar things, etc. | 16:28 |
| voidspace | (and ConfigType.DHCP is actually a change for EC2 - we'll need to check for MaaS) | 16:28 |
| voidspace | e.g. ConfigType: Config.DHCP, Address is set to the first NIC's address, ExtraConfig: nil, GatewayAddress - nil | 16:28 |
| dooferlad | voidspace: Are we talking about https://github.com/dimitern/juju/compare/ec2-cleanup-addressability ? | 16:28 |
| voidspace | dimitern: I think we're good on that front, worth checking though | 16:28 |
| voidspace | dooferlad: yep | 16:28 |
| dimitern | voidspace, cheers, I'll go back to chasing bugs then :) | 16:29 |
| voidspace | dooferlad: so in terms of pairing, I have just under two hours left before I EOD (after I get coffee) | 16:29 |
| * TheMue is afk for a moment, bbiab | 16:30 | |
| dooferlad | voidspace: OK. See you in a moment. I need to reboot so I can enable virtualisation in my BIOS | 16:30 |
| voidspace | dooferlad: one of us should have the EC2 code (dimitern's branch) open and the other the MaaS code and then we can go through both and check that behaviour is the same for both | 16:30 |
| voidspace | dooferlad: cool | 16:30 |
| dooferlad | voidspace: ready when you are | 16:38 |
| voidspace | dooferlad: ok, team hangout? | 16:38 |
| dooferlad | voidspace: sounds good | 16:38 |
| voidspace | dimitern: ping | 17:12 |
| voidspace | dimitern: you said, for MaaS NetworkInterfaces method (InterfaceInfo) "Address is set to the first NIC's address" | 17:12 |
| dimitern | voidspace, ah, right you got me | 17:12 |
| dimitern | :) | 17:12 |
| voidspace | dimitern: I assume you meant "Address is set to the NIC's first address" | 17:12 |
| dimitern | voidspace, correct | 17:13 |
| voidspace | :-) | 17:13 |
| voidspace | dimitern: so parse the CIDR and just return the IP part of the cidr? | 17:14 |
| voidspace | dimitern: is that adequate? | 17:14 |
| voidspace | ParseCIDR(...).IP.String() | 17:16 |
| voidspace | with appropriate error checking | 17:16 |
| dimitern | voidspace, I think so | 17:26 |
| voidspace | dimitern: cool | 17:26 |
| voidspace | dimitern: is it ok to skip ProviderID on MaaS? | 17:26 |
| dimitern | voidspace, if the result is a valid address | 17:26 |
| voidspace | dimitern: we don't have it currently | 17:26 |
| voidspace | dimitern: it must be a valid address | 17:26 |
| dimitern | voidspace, for the NIC you mean? | 17:27 |
| voidspace | dimitern: yes | 17:27 |
| dimitern | voidspace, yes - it's not available on maas, but ProviderSubnetId is | 17:27 |
| voidspace | dimitern: right, we fill that in | 17:27 |
| dimitern | voidspace, +1 | 17:27 |
| alexisb | so folks what do we need to do to no longer be blocked by 1424777? | 18:07 |
| dimitern | alexisb, first 1.22 needs to pass, and a few tests were failing or hanging on i386 since yesterday | 18:08 |
| dimitern | alexisb, I've talked with sinzui about access to a i386 to test, and I'm about to propose a PR to skip certain tests on i386 so 1.22 can pass and then 1.23 can pass and get unblocked | 18:09 |
| dimitern | at least that's the plan | 18:09 |
| sinzui | dimitern, and I endorse the plan | 18:10 |
| dimitern | sinzui, I'm waiting for the full suite to pass on the i386 machine and then proposing | 18:11 |
| sinzui | dimitern, sorry, that takes so long. As for CI we are also waiting for the last two tests to complete, then we can test master | 18:12 |
| dimitern | sinzui, ok, I'm proposing then | 18:12 |
| * perrito666 is surprised that most big cities of his province are flooded, including his, and he still has power and internet... I feel so 1st world :p | 18:13 | |
| sinzui | perrito666, meanwhile abentley is not in his house because Toronto wasn't as first world as he hoped | 18:14 |
| perrito666 | sinzui: amazing | 18:15 |
| sinzui | Once the glaciers melt and London and New York are flooded, we will all be equal | 18:15 |
| perrito666 | oh no, I live in high ground in the middle of the continent, mi city just floods because of improper sewage | 18:16 |
| alexisb | dimitern, sinzui thank you | 18:16 |
| dimitern | alexisb, np | 18:19 |
| dimitern | sinzui, fix proposed and set to land https://github.com/juju/juju/pull/1683 | 18:20 |
| sinzui | dimitern, let's not add $$merge$$ until we see master start testing | 18:20 |
| dimitern | sinzui, :( I already did btw | 18:21 |
| dimitern | sinzui, but feel free to stop the merge job | 18:21 |
| * dimitern hates fixes in a hurry | 18:22 | |
| * dimitern steps out for 30m | 18:23 | |
| sinzui | dimitern, I am going to cheat and that 1.22 out of list of branches to test for a few minutes | 18:24 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === jcw4 is now known as jw4 | ||
| sinzui | dimitern, natefinch : we have new information about deployer bug https://bugs.launchpad.net/juju-core/+bug/1425435/comments/5 | 19:16 |
| mup | Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <regression> <uosci> <juju-core:New> <https://launchpad.net/bugs/1425435> | 19:16 |
| thumper | fwereade: ping | 19:46 |
| thumper | sinzui: what's the reason the bot is still blocked? | 19:47 |
| sinzui | thumper, master has not passed | 19:48 |
| thumper | that particular issue? or other ones? | 19:49 |
| thumper | where that particular one is the critical bug still there | 19:49 |
| thumper | precise local upgrade | 19:49 |
| sinzui | thumper, We are testing dimitern 's fixes now. 1.22 took forever to test because of the i386 regression | 19:50 |
| sinzui | thumper, I hope to see a bless in 3 hours | 19:50 |
| thumper | ok... | 19:50 |
| thumper | cheers | 19:50 |
| === sebas53__ is now known as sebas5384_ | ||
| === sebas5384_ is now known as sebas5384 | ||
| === thumper is now known as thumper-afk | ||
| * dimitern is back | 21:44 | |
| mbruzek | jog ping | 22:01 |
| jog | mbruzek, pong | 22:01 |
| thumper-afk | davecheney: hey, I have a number of trivail patches this morning: http://reviews.vapour.ws/r/1012/ | 22:03 |
| thumper-afk | gah | 22:03 |
| === thumper-afk is now known as thumper | ||
| thumper | I always forget to change that back | 22:04 |
| mbruzek | jog I need some help with the test results for kubernetes. | 22:04 |
| mbruzek | jog do you know why the page does not show the past 12 results? | 22:04 |
| jog | mbruzek, looking | 22:05 |
| mbruzek | jog 8 from yesterday and 4 more from today. | 22:05 |
| perrito666 | thumper: isnt davecheney out in some gophercon? | 22:05 |
| thumper | perrito666: not now | 22:05 |
| thumper | perrito666: davecheney was at the india gophercon at the end of last week | 22:06 |
| perrito666 | ah it was until mon | 22:06 |
| jog | mbruzek, do you know the Jenkins job for one of the missing tests? | 22:10 |
| mbruzek | jog in the note I sent yesterday | 22:11 |
| mbruzek | there were 8 of them. | 22:11 |
| mbruzek | http://juju-ci.vapour.ws:8080/job/charm-bundle-test-azure/49/console | 22:11 |
| dimitern | and we have a blessed master | 22:12 |
| thumper | dimitern: ah finally | 22:13 |
| thumper | awesome | 22:13 |
| dimitern | it was a marathon ;) | 22:13 |
| thumper | davecheney: (or anyone) http://reviews.vapour.ws/r/1013/ | 22:13 |
| dimitern | the last 3 days | 22:13 |
| thumper | dimitern: thanks for all your work on that | 22:13 |
| thumper | dimitern: I really appreciate it | 22:13 |
| dimitern | thumper, cheers, I'm just glad *now* I can land my stuff as well :) | 22:13 |
| jog | mbruzek, the results.json on S3 for all those tests is empty... | 22:14 |
| mbruzek | jog can you help me figure out why? | 22:15 |
| jog | mbruzek, looking | 22:15 |
| dimitern | some of them are still pending I think | 22:16 |
| dimitern | but revision-results #2078 passed | 22:16 |
| jog | mbruzek, still looking but I suspect bug 1425435, since deployer is being used by bundletester | 22:20 |
| mup | Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 <api> <cts> <network> <oil> <openstack> <regression> <uosci> <juju-core:Triaged> <juju-core 1.22:New> <juju-core 1.23:New> <https://launchpad.net/bugs/1425435> | 22:20 |
| jog | mbruzek, I'm trying to find what version of Juju these tests run with. | 22:20 |
| mbruzek | jog according to the console text JUJU_VERSION=1.21.1 | 22:21 |
| dimitern | sinzui, re that deployer bug | 22:26 |
| sinzui | why are you awake? | 22:26 |
| dimitern | sinzui, is it worth doing a 1.21.4 point release for a fix | 22:26 |
| dimitern | sinzui, I'm wired by the blessed master :) | 22:27 |
| dimitern | so much to land.. | 22:27 |
| sinzui | dimitern, I think we need to discuss further. a fixed python-jujuclient is being built now | 22:28 |
| alexisb | sinzui, we will get to talk abou tit in 2 minutes :) | 22:28 |
| dimitern | sinzui, that will definitely alleviate the issue for the users of python-jujuclient, however juju gui might still have issues (well, provided it's quick enough while deploying things and checking status) | 22:29 |
| alexisb | rick_h_, have you looked at this ^^^ | 22:30 |
| dimitern | anyway, I have a solid plan about a fix if it comes to that, and for 1.22 and 1.23 there will be a fix | 22:30 |
| sinzui | thumper, wallyworld dimitern: I confidently predict a bless for master. I am removing the block queue the mad rush to merge and crash | 22:30 |
| dimitern | oh happy days! :) | 22:31 |
| dimitern | 68 PRs await | 22:31 |
| thumper | 68? | 22:32 |
| thumper | holy crap | 22:32 |
| === kadams54 is now known as kadams54-away | ||
| dimitern | well, 67 in reality | 22:33 |
| * dimitern goes to do some *damn* programming as fwereade would say | 22:33 | |
| jog | mbruzek, charm-bundle-test-azure/50 certainly is the bug I mentioned above | 22:36 |
| mbruzek | jog yeah there are different bugs | 22:37 |
| jog | mbruzek, several others such as joyent 45 have "ERROR connection is shut down"... that something we've seen intermittently | 22:37 |
| mbruzek | jog that bug reports things are ok with 1.21.1 and that seems to be the version in the log | 22:45 |
| jog | charm-bundle-test-azure-50-all-machines-log shows an upgrade occurred from 1.21.1-trusty-amd64 to 1.21.3 | 22:48 |
| mbruzek | jog good spot. | 22:55 |
| mbruzek | dimitern: whit had looked into fixing this in the jujuclient, | 22:55 |
| dimitern | mbruzek, that's great, but I think it should also be fixed in juju (at least 1.23) - for the sake of any other client of the api | 22:57 |
| whit | +1 | 22:58 |
| waigani | thumper, cherylj, davecheney: http://reviews.vapour.ws/r/1014/ thanks | 22:58 |
| mbruzek | dimitern: looks good | 22:58 |
| mbruzek | dimitern: thanks for the information, I look forward to the fix | 23:02 |
| dimitern | mbruzek, np | 23:02 |
| sinzui | wallyworld, http://reports.vapour.ws/releases show the ugly truth of failures looking at a specific release we know exactly which voting test failed http://reports.vapour.ws/releases/2383 | 23:06 |
| wallyworld | sinzui: so the failures there are the 386 and vivid issues we know about | 23:07 |
| sinzui | wallyworld, well sort of good news for viviid | 23:08 |
| sinzui | wallyworld, the lxc based unit tests and vivid machine test don't vote because they aren't reliable... | 23:08 |
| sinzui | but vivid machine and ppc64el lxc passed for the first time today | 23:08 |
| wallyworld | i wish the 386 tests didn't vote :-) | 23:08 |
| wallyworld | that's good news | 23:09 |
| wallyworld | i think they were fixing some cloud init issues for vivid? | 23:09 |
| sinzui | wallyworld, ubuntu needs to stop making clients agents that people can run in local host.... | 23:09 |
| sinzui | wallyworld, change juju to refuse to deploy a 386 agent locally | 23:09 |
| wallyworld | yeah, i think there needs to be a 386 discussion | 23:10 |
| perrito666 | hey just back, still locked? | 23:47 |
| anastasiamac | perrito666: CI? no:D | 23:50 |
| perrito666 | anastasiamac: happiness | 23:51 |
| anastasiamac | perrito666: dunno... looks more like a mad rush to land to me :D | 23:51 |
| * perrito666 tries to color juju's tests output and is completely unsuccesful | 23:51 | |
| perrito666 | anastasiamac: could be :p | 23:52 |
| perrito666 | anastasiamac: lets say its a long day and still not over | 23:52 |
| anastasiamac | perrito666: my merge is queed up and the one that is currently running (if it lands) will conflict with mien :( | 23:52 |
| anastasiamac | mine* | 23:52 |
| anastasiamac | perrito666: tomorrow is another day :D | 23:53 |
| perrito666 | anastasiamac: dont remind me :p, tomorrow will start waaaay too close to the end of today | 23:53 |
| anastasiamac | perrito666: wait unitl u'd get kids :d there will be no today/tomorrow - just "awake" and "not quiet awake" :D | 23:55 |
| perrito666 | sinzui: my restore change is queued for landing :) | 23:56 |
| sinzui | perrito666, given the mad rush to merge, there are good odds your change isn't the one that breaks master | 23:57 |
| perrito666 | sinzui: are you kidding? restore always breaks master | 23:58 |
| sinzui | perrito666, but now we have four substrates to test in. In fact I am not convinced restore work in Azure. Well I think it work 1 in 5 tries | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!