huwshimiHey, does anyone know if this list of supported series is up to date? https://github.com/juju/charmstore/blob/v5-unstable/internal/series/series.go#L3700:08
huwshimiAlso any ideas if there is a list of English labels for those series?00:10
alexisbwallyworld_, ping00:15
alexisbsorry was late, I am on the hangout now00:16
menn0alexisb: do we have a hangout now?01:02
alexisbmenn0, yes01:04
alexisbI am running late01:04
alexisbmenn0, I can see you01:05
alexisbcan you hear me?01:06
axwthumper davecheney: FYI, peergroup fix is landed now01:15
thumperthanks axw01:15
thumperreally appreciate it01:15
thumperaxw: good work on the unit assignment bit too01:15
davecheneyaxw: hotsauce!01:21
natefinch-afkaxw: yes, thanks for cleaning up my mess :)01:24
=== natefinch-afk is now known as natefinch
axwnatefinch: heh, np01:24
thumper\o/ sped up the tests by 10s by fixing one test01:57
* thumper wonders what else he broke01:57
thumperhuh, tests all pass01:58
wwitzel3wallyworld_: ping02:13
wwitzel3wallyworld_: katco said you needed some clarification on things? I'm around poking this bug with a stick02:15
wallyworld_i'm bootstrapping a 1.22 env to debug with02:15
wallyworld_i don't really need clarification02:15
wallyworld_just need to reproduce locally so i don't mess their environment02:15
wwitzel3wallyworld_: ahh ok, I can reproduce the issue even with 1.25.0 .. if you upload-tools, it hoses up the ability to upgrade02:16
wallyworld_even when we find and fix that, there are still on 1.22 without the fix :-(02:17
wallyworld_it will be an agent related issue02:17
wwitzel3wallyworld_: yeah, my hope was that since it is in all versions, the problem code would be the same02:18
wwitzel3wallyworld_: also my main goal was trying to see if a new version didn't have the problem, so I could do a git bisect to isolate the problem02:18
wallyworld_the other issue of course is the conn disconnect preventing upload tools from working02:18
thumperdavecheney: http://reviews.vapour.ws/r/3182/02:20
thumperdavecheney: this has the code I wanted to talk to you about in it02:20
wallyworld_wwitzel3: when you say 1.25, you mean a 1.25 back end?02:24
wwitzel3wallyworld_: yes, I bootstrapped 1.25.0 using upload-tools and then attempted to upgrade and got the same failure02:25
wwitzel3wallyworld_: no tools found OR connection shut down, depending on if I used upload-tools or not02:25
wallyworld_wwitzel3: and if you bootstrap without upload-tools but attemt to upgrade with upload-tools?02:26
wallyworld_so the upload-tools on bootstrap is the issue?02:26
wwitzel3wallyworld_: maybe, I didn't test upgrading after using upload-tools to upgrade02:26
wwitzel3wallyworld_: I can try that really quick though02:26
wwitzel3I can go 1.22 to 1.25 with upload-tools and then try to go to 1.2602:27
wallyworld_so just to be clear, you think bootstrap WITHOUT upload-tools is ok02:27
wallyworld_but with uploa-tools on bootstrap is not02:27
wwitzel3yes, if I bootstrap without upload-tools I can perform an upgrade to 1.26 if I set the agent-stream to devel02:27
wallyworld_wwitzel3: so with upload-tools, you could try clearing ALL the tools metadata as we did yesterday02:28
wwitzel3if I use upload-tools, upgrades fails, even if using upload-tools again02:28
wwitzel3wallyworld_: yep, I did that02:28
wallyworld_and it still fails?02:28
wallyworld_now that makes no sense what so ever02:28
wwitzel3oh you mean even the metadata put there from the upload-tools?02:29
wwitzel3not jsut the streams data02:29
wallyworld_delete * from toolsmetadata collection02:30
wwitzel3wallyworld_: ok, let me try that, bootstrapping 1.22.8 right now (no upload-tools)02:30
wwitzel3wallyworld_: then I will upgrade to 1.25 with upload-tools, see if that puts it in the broken state02:31
wwitzel3wallyworld_: then I'll db.toolsMetadata.remove() and see if I can upgrade to 1.2602:31
davecheneythumper: me looks02:38
thumperdavecheney: cheers02:38
thumperdavecheney: the piece I was talking about this morning is the race condition in the api opening / timeout handling02:39
thumperif we hit the timeout, I close a channel02:39
thumperthe other go routine does check this channel once the open api func returns02:39
thumperthere is a race condition if the api is returned and the channel checked just before a different goroutine determines that we have timed out02:40
thumperso noone reads off the api or error return channels02:40
thumperhowever I figure what I added is better than the guaranteed block forever of the opening goroutine02:41
thumperif it did timeout02:41
thumperdavecheney: I suppose we could fix that by making the apireturn and error return buffered channels of length one?02:41
thumperif we did that, perhaps we could get rid of the timeout channel?02:42
thumperif we did that, the api wouldn't be closed on timeout02:42
thumperbah humbug02:42
davecheneythumper: i don't like what i see02:43
davecheneydo you want me to rip it to shreads in review02:43
davecheneyor should we have a hangout to discuss the design02:43
natefinchdavecheney: shit, we have the second option?  Someone should have told me two years ago :)02:57
davecheneythumper gets special treatment02:58
thumperdavecheney: hmm03:06
thumperdavecheney: hangout probably best03:07
thumperdavecheney: read the review, happy to explain... but given we are trying to pass information through several layers, this is the best approach I could come up with03:11
davecheneythumper: 1:1 hangout ?03:21
thumperdavecheney: sure03:22
wallyworldwwitzel3: i'vr narrowed it down to the final upload tools step after the tools are built, need to dig into that a bit more. plus i've also got new logging showing juju is missing tools from simplestreams after all03:30
natefinchgah, testing that things run in goroutines is a PITA03:36
mgzwallyworld: have you worked out the path where juju is getting correct tools when simplestreams isn't working as expected?03:38
wallyworldmgz: not yet. the logging i added doesn't dump the raw metadata as i did previously, i added extra logging at the point where the tools list is actually composed and returned to the caller. there's something really weird going on03:39
davecheneythumper: http://play.golang.org/p/7HqKts_Di103:40
wallyworldwwitzel3: so i think i found the reason for the no matching error on upgrade, need to double check my logic03:48
=== axw_ is now known as axw
axwcherylj: that peergroup bug is fixed now, I just forgot to tick it over04:20
axwdone now04:20
axwand retargeted back to 1.26-alpha204:21
menn0thumper: upgrader working in the dep engine: http://reviews.vapour.ws/r/3185/diff/04:23
* thumper looks04:40
thumperdavecheney: I'm off now to walk the dog05:18
thumperdavecheney: review updated following review and chat05:18
davecheneyTheMue: ta05:25
davecheneythumper ta05:25
natefinchholy crap, 150 lines of test code runs perfectly the first time it successfully compiles.06:09
natefinch(lol.... all that to test a 23 line function)06:09
mupBug #1517743 opened: api: more data races <juju-core:New> <https://launchpad.net/bugs/1517743>06:18
mupBug #1517744 opened: cmd/jujud/agent: more data races <juju-core:New> <https://launchpad.net/bugs/1517744>06:18
mupBug #1517743 changed: api: more data races <juju-core:New> <https://launchpad.net/bugs/1517743>06:24
mupBug #1517744 changed: cmd/jujud/agent: more data races <juju-core:New> <https://launchpad.net/bugs/1517744>06:24
mupBug #1517743 opened: api: more data races <juju-core:New> <https://launchpad.net/bugs/1517743>06:27
mupBug #1517744 opened: cmd/jujud/agent: more data races <juju-core:New> <https://launchpad.net/bugs/1517744>06:27
mupBug #1517747 opened: provider/joyen: more data races <juju-core:New> <https://launchpad.net/bugs/1517747>06:33
mupBug #1517748 opened: provider/lxd: test suite panics if lxd not installed <juju-core:New> <https://launchpad.net/bugs/1517748>06:33
mupBug #1517747 changed: provider/joyen: more data races <juju-core:New> <https://launchpad.net/bugs/1517747>06:39
mupBug #1517748 changed: provider/lxd: test suite panics if lxd not installed <juju-core:New> <https://launchpad.net/bugs/1517748>06:39
mupBug #1517747 opened: provider/joyen: more data races <juju-core:New> <https://launchpad.net/bugs/1517747>06:45
mupBug #1517748 opened: provider/lxd: test suite panics if lxd not installed <juju-core:New> <https://launchpad.net/bugs/1517748>06:45
axwwallyworld: proposed apiserver/remoterelations, containing just the local watchers for now: https://github.com/juju/juju/pull/377907:28
anastasiamacdimitern: o/07:47
dimiternanastasiamac, o/07:47
anastasiamacdimitern: how is sophia? do u have snow? :D07:47
dimiternthere's nothing like an unblocked master in the morning :)07:48
dimiternanastasiamac, oh not nearly - it's a lat autumn still 10-18 deg.07:48
wallyworldaxw: awesome, thanks will look soon07:58
mupBug #1302498 changed: Ensure network names are validated on deploy/add-machine once possible <tech-debt> <juju-core:Won't Fix> <https://launchpad.net/bugs/1302498>08:55
dimiternfrobware, jam, fwereade, standup?10:02
frobwaredimitern, dooferlad: the answer is "yes" to does an ordinary deploy with network aliases pause with 'Waiting 120 seconds for network devices'", so not a result of butchering /e/n/i10:52
dooferladfrobware: fun!10:53
frobwaredooferlad, it does success though10:54
dimiternfrobware, well, that's kinda good news10:54
dimiternfwereade, hey, I've realized bindings should be updated on svc.SetCharm(), possibly allowing you to do upgrade-charm --bind like with deploy10:58
fwereadedimitern, good point, yes they should10:59
dimiternfwereade, initially, we could just use default bindings for new endpoints, and not implement --bind for upgrade-charm10:59
dimiternfwereade, but the bindings definitely need updating as part of changeCharmOps11:00
fwereadedimitern, yeah, I think that's the bulk of the cost/complexity11:00
fwereadedimitern, once that's in, which I think it must be, the extra cost of exposing it via upgrade-charm is minimal11:00
dimiternfwereade, exactly11:01
fwereadedimitern, and is likely to actually be helpful in terms of showing us where concept boundaries truly lie11:01
fwereadedimitern, the more sane clients you have, the more likely your abstraction is sane11:01
dimiternfwereade, yeah11:01
dimiternfwereade, cheers11:02
dimiternfwereade, in order to assert bindings haven't changed while updating them I think I need to use txn-revno explicitly as a field, right?11:03
fwereadedimitern, hm, quite possibly, yeah11:04
fwereadedimitern, as long as it's a small doc only used for that purpose it's fine11:04
dimiternfwereade, ok, so it's very much like for settings, but slightly simpler since the values are strings, not interface{}11:05
fwereadedimitern, cool11:05
dooferladdimitern, frobware: PTAL https://code.launchpad.net/~dooferlad/gomaasapi/subnets/+merge/27797711:38
dimiterndooferlad, looking11:43
mupBug #1517863 opened: Leadership appears broken in 1.25 <juju-core:New> <https://launchpad.net/bugs/1517863>11:58
mupBug #1517863 changed: Leadership appears broken in 1.25 <juju-core:New> <https://launchpad.net/bugs/1517863>12:04
mupBug #1517863 opened: Leadership appears broken in 1.25 <juju-core:New> <https://launchpad.net/bugs/1517863>12:07
dimiterndooferlad, reviewed, let me know what you think..12:14
mupBug #1517863 changed: Leadership appears broken in 1.25 <juju-core:Triaged> <https://launchpad.net/bugs/1517863>13:49
mupBug #1517863 opened: Leadership appears broken in 1.25 <juju-core:Triaged> <https://launchpad.net/bugs/1517863>13:58
mupBug #1517863 changed: Leadership appears broken in 1.25 <juju-core:Triaged> <https://launchpad.net/bugs/1517863>14:01
tvansteenburghjw4: you around?14:36
* tvansteenburgh shamelessly cross-posts:14:37
tvansteenburghanyone know how to get the ID of the currently executing juju action from inside the action itself?14:37
tvansteenburghi've seen other code using JUJU_ACTION_ID, but it's not set, and I don't see any mention of that env var in the docs14:37
tvansteenburghah, it's JUJU_ACTION_UUID14:43
kadams54stokachu: Just submitted a PR to your theblues branch. Once that's landed, it should fix the doc errors that are currently preventing your PR from landing.14:57
stokachukadams54: nice!14:59
stokachukadams54: i have a initial debian package built would you like me to create a pr for that or just maintain it out of tree?15:00
katcoericsnow-afk: you going to be here today?15:02
ericsnow-afkkatco: coming15:02
=== ericsnow-afk is now known as ericsnow
stokachukadams54: ok merged that PR15:02
jw4tvansteenburgh: glad you found it :)15:21
mupBug #1440209 changed: juju action do doesn't accept non-string params on command line <actions> <juju-core:Fix Released> <https://launchpad.net/bugs/1440209>15:22
frobwarecherylj, I think this (https://bugs.launchpad.net/juju-core/+bug/1516036) should go into 1.25.1 too. Thoughts?15:23
mupBug #1516036: provider/maas: test failure because of test isolation failure <juju-core:Fix Committed by frobware> <https://launchpad.net/bugs/1516036>15:23
cheryljfrobware: yes, if it's a problem on 1.25 and you can get that in, that would be good.15:24
frobwarecherylj, it depends to be a problem for devs - if your DNS doesn't use something like, or whatever CI uses, then the unit tests can fail.15:25
cheryljfrobware: things that prevent us from getting good test / CI runs are definitely good to have everywhere.15:26
cheryljfrobware: but if you can't get it done today, it can wait to 1.25.215:27
cheryljfrobware: actually15:27
cheryljfrobware: would you be up for looking at a different bug?15:27
frobwarecherylj, need to land the MAAS/19 DHCP first.15:27
frobwarecherylj, but sure15:27
cheryljfrobware: ok :)  just ping me if you still feel that way after you land the MAAS 1.9 / DHCP fix :)15:28
frobwarecherylj, what's the LP#15:28
frobwarecherylj, curiosity killed the cat!15:28
cheryljThere are two causing problems for 1.25 CI:  bug 151446215:29
mupBug #1514462: Assertion failure in TestAPI2ResultError <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1514462>15:29
cheryljand bug 151761115:29
mupBug #1517611: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>15:29
frobwarecherylj, Xenial - ha... just to add to the matrix15:29
mgzfrobware: the important bit is less xenial and more go 1.515:30
frobwaredimitern, dooferlad: please take a look http://reviews.vapour.ws/r/3188/15:33
dimiternfrobware, looking15:34
stokachukadams54: just setup a seperate repo for the debian package i did https://github.com/battlemidget/theblues-deb15:35
kadams54stokachu: thanks for the heads up… I'm kinda surprised we don't already have one :-)15:37
frobwaredimitern, thanks15:37
mgzfrobware: I still don't understand your change for bug 151603615:47
mupBug #1516036: provider/maas: test failure because of test isolation failure <juju-core:Fix Committed by frobware> <https://launchpad.net/bugs/1516036>15:47
mgzthe tests actually query a real dns server, so the solution is changing the value that escapes testing to fail more, rather than correctly isolating the tests from the runner's dns setup?15:48
alexisbmgz, cherylj are we sure that those two bugs are what is causing the 1.25 curse?15:48
mgzalexisb: bug 1517611 is causing the 1.25 curse15:49
mupBug #1517611: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>15:49
mgzalexisb: bug 1514462 is the main cause of failure for master on go 1.515:49
mupBug #1514462: Assertion failure in TestAPI2ResultError <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1514462>15:49
alexisbmgz, bug 1517611 is marked incomplete?15:50
mupBug #1517611: TestFilesystemInfo race condition in 1.25 <ci> <intermittent-failure> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1517611>15:50
mgzalexisb: it's the "not on trunk, just 1.25" marker15:50
frobwaremgz, I don't know what to do about it atm. the real issue is on the MAAS side - we're trying to workaround a sporadic bug there,15:50
mgzfrobware: what's the maas bug number? I can hit roaksoax in person.15:51
frobwaremgz, https://bugs.launchpad.net/juju-core/+bug/141262115:51
mupBug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <bug-squad> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Fix Committed by frobware> <juju-core 1.24:Won't Fix> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1412621>15:51
dooferladfrobware: reviewed15:51
ericsnowmgz: why not just delete the bug task for master?15:52
alexisbfrobware, that is a juju core bug15:52
ericsnowmgz: (the minus sign in the "Affects" column)15:52
dimiternfrobware, reviewed15:53
mgzericsnow: we don't know it'as not on master, we've just not seen it15:55
mgzalso, it confuses search15:55
ericsnowmgz: ah15:55
ericsnowmgz: k15:55
mgzfrobware: I'm not seeing a maas bug referenced, just that it's a generic error we see when maas dhcp gets screwed, which can be a variety of reasons16:00
mgzfrobware: roaksoax says that once juju has touched /e/n/i it's our problem, basically16:00
mgzfrobware: I also don't see how that's related to our unit tests really touching dns16:02
frobwaremgz: the issue is that MAAS does not always update its DNZ zone entry for the node that is just deployed which  means it is unresolvable.16:06
mgzfrobware: okay, but there's no maas bug specifically for that in launchpad?16:07
mgzor I'm not finding it?16:07
cheryljmgz: I'm not sure that there was a separate bug for the MAAS issue.  I think they had just looked at the same bug frobware was working on:  bug 141262116:11
mupBug #1412621: replica set EMPTYCONFIG MAAS bootstrap <adoption> <bootstrap> <bug-squad> <charmers> <cpec> <cpp> <maas-provider> <mongodb> <oil> <juju-core:Fix Committed by frobware> <juju-core 1.24:Won't Fix> <juju-core 1.25:Fix Committed by frobware> <https://launchpad.net/bugs/1412621>16:11
cheryljmgz: or maybe I'm remembering wrong.  I thought I saw that the MAAS guys touched that bug16:11
dimiternfrobware, ah, I've haven't notices runScript takes explicit string arguments, so ignore my comment around using test.params...16:11
mgzcherylj: I'm just not seeing any work on the maas side to fix things16:12
frobwaremgz, I just updated the bug16:13
mgzfrobware: thanks!16:14
frobwaremgz, if you drop back to IP addresses the replica set can continue; if you don't drop the unresolvable host names then the node will be unusable. I think we're pushing in the wrong direction. This, to me, is a MAAS issue.16:15
mgzfrobware: okay, I just didn't see that communicated anywhere16:15
frobwaremgz, but it was suggested we try and work around broken/sporadic provider behaviour.16:15
mgzif we want maas to fix things we need to tell them16:15
frobwaremgz, that's mostly in the git commit16:16
frobwaremgz, re: "I just didn't see that communicated anywhere"16:16
frobwaremgz, resolving the names (which broke the unit tests for some) is a bad idea. We either back it out, fix it MAAS, or continue to workaround and add more crud.16:18
mgzI'm generally for backing that out.16:18
frobwaremgz, the advertised solution is to use static IP addresses but I don't think you can do that for 1.8 - true?16:19
=== natefinch is now known as natefinch-afk
mgzfrobware: not in default config at least, everything just asks dhcp for an address16:21
dimiternfrobware, you can do that in 1.8 - with either devices or ipaddresses APIs16:25
frobwaremgz, dimitern: so if you're using dhcp you're like to run into this problem. if you can switch to static, there's a workaround. Open to backing this out if it is making things worse, et al.16:27
dimiternfrobware, well, having the option to do it is one thing, but actually doing it is quite a different story :)16:28
dimiternfrobware, I mean juju can't enforce restrictions on how your maas nodes get their addresses16:28
frobwaredimitern, right. not clear how practical a solution that is (for customers)16:28
dimiternfrobware, in most cases I guess customers will use static addresses for nodes16:29
alexisbmgz, katco ping17:00
mupBug #1517992 opened: juju-upgrade to 1.24.7 leaves juju state server unreachable <juju-core:New> <https://launchpad.net/bugs/1517992>17:38
perrito666sorry ppl, cannot make it to the hangout17:58
natefinch-afkI guess I missed it18:11
=== natefinch-afk is now known as natefinch
katconatefinch: we called it. too few people18:12
natefinchkatco: figured.  Sorry, kids' thanksgiving thing at school ran over.18:17
katconatefinch: are you porting that fix for bug 1382556 to master?18:59
mupBug #1382556:  "cannot allocate memory" when running "juju run" <cpe-critsit> <run> <juju-core:In Progress by natefinch> <juju-core 1.25:Fix Committed by natefinch> <https://launchpad.net/bugs/1382556>18:59
natefinchkatco: I am now19:00
katconatefinch: ty19:00
natefinchman I wish git was better at dealing with moved files.19:18
katconatefinch: did you get that bug ported to 1.25? saw the card is moved over19:34
natefinchporting to master now, didn't realize the card should include the port, sorry, I can move it back.19:35
natefinchkatco: hit a snag that the ssh stuff moved outside the repo, so going to have to do a more manual port of that part of the code19:35
katconatefinch: no worries, the bug was still open so just wanted to check19:35
katconatefinch: bummer =/19:35
natefinchwe should just rename dependencies.tsv to mergeconflict.tsv20:31
natefinchwhen did we start using gopkg.in/inconshreveable/log15.v2 ?20:33
katconatefinch: lxd dependency20:33
natefinchkatco: gah... libraries shouldn't log :/20:33
natefinchfor exactly this reason20:35
natefinchkatco: can I just merge the forward ports?  While I had to manually copy over the changes from 1.25 to the new repo, it really is just an exact copy of the code... there were no changes in between the two as far as I can tell.20:42
katconatefinch: do you mean don't go through the bot?20:43
katconatefinch: or do you mean no review?20:43
natefinchkatco: no review20:43
katconatefinch: yeah go for it20:43
mupBug #1509032 changed: Juju doesn't support is own version of 1.25.0 <ci> <test-failure> <juju-core:Fix Released by cherylj> <juju-core 1.25:Fix Released by cherylj> <https://launchpad.net/bugs/1509032>20:44
=== thumper is now known as thumper-afk
natefinchaww dammit21:17
natefinchsomeone changed juju/utils with a breaking API change, without updating juju core21:18
natefinchdooferlad: ^21:18
alexisbnatefinch, he is sleeping I would think21:23
natefinchalexisb: yeah, remembered after I pinged him21:23
menn0mgz: ping?21:31
mgzmenn0: yo21:31
menn0mgz: i'm helping out with a unit test failure on ppc64 (TestFilesystemInfo)21:31
menn0it only seems to fail on ppc6421:31
menn0can I get access to the ppc64 unit test host (stilson-09 I believe)?21:32
mgzmenn0: sure21:32
menn0I already have access to stilson-08 from looking at an issue a long time ago but it doesn't appear to have any go tools installed21:32
mgzthere are a lot more meenos than I'd expect on lp21:33
natefinchcan someone review this 5 line patch so head on master actually compiles with head on juju/utils? http://reviews.vapour.ws/r/3192/21:38
=== thumper-afk is now known as thumper
natefinchkatco, menn0, thumper ^21:40
* menn0 looks21:41
* thumper shipped it21:41
* menn0 is too slow21:41
natefinchkatco: once my fix to master lands, then my forward port should land21:48
natefinchdinner time, back in a few hours21:48
=== natefinch is now known as natefinch-afk
katconatefinch-afk: cool ty21:50
ericsnowkatco: I'm out like a trout22:00
katcoericsnow: tc22:00
katcoericsnow: how far did you get?22:01
ericsnowkatco: not too far22:02
ericsnowkatco: it *does* reproduce reliably (by re-running the CI job)22:02
ericsnowkatco: I've updated the bug report22:02
katcoericsnow: ty22:10
=== ericsnow is now known as ericsnow-afk
mgzmenn0: hey, did you repo? my run just before restarting hit the failure22:33
menn0mgz: yep, repoed it immediately22:35
menn0mgz: I have a "fix", but it's really looking like a Go toolchain bug22:35
mgzmwhudson will love you.22:36
menn0mgz: printing out the struct created by state.FilesystemAttachmentInfo{MountPoint: "/srv"} gives {MountPoint: ReadOnly: true}22:37
menn0but if I do state.FilesystemAttachmentInfo{MountPoint: "/srv", ReadOnly: false}, you get {MountPoint: "/srv", ReadOnly: false}22:37
menn0serious wtf territory22:38
menn0mwhudson isn't around today unfortunately22:38
mgzmenn0: sooo... is your "fix" constructing the thing with full params each time?22:47
mgzmenn0: we don't seem to have had any compiler changes or other suspect things on stilson-09 recently, so mystery to me why it started happening on the 1.25 branch here22:49
menn0mgz: yeah, it's pretty strange23:03
perrito666hello again everybody23:13
menn0davecheney: I just sent you and mwhudson details of a fun ppc64 issue via email23:21
davecheneymenn0: \o/23:27
davecheneymenn0: unconstructive answer: use go 1.523:29
davecheneynobody will fix gccgo4.923:29
menn0davecheney: joy :-/23:30
davecheney        a := s.newAgent(c, ss)23:32
davecheney        go func() { c.Check(a.Run(nil), gc.IsNil) }()23:32
davecheney        defer func() { c.Check(a.Stop(), gc.IsNil) }()23:32
davecheney        // Now run the test.23:32
davecheney        s.assertUpgradeSteps(c, state.JobHostUnits)23:32
davecheney        s.assertHostUpgrades(c)23:32
davecheneywhat the f23:32
mupBug #1518128 opened: Improper address:port joining <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1518128>23:48
mupBug #1518131 opened: cmd/jujud/agent: different data races <juju-core:New> <https://launchpad.net/bugs/1518131>23:48
mupBug #1518128 changed: Improper address:port joining <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1518128>23:51
mupBug #1518131 changed: cmd/jujud/agent: different data races <juju-core:New> <https://launchpad.net/bugs/1518131>23:51
mupBug #1518128 opened: Improper address:port joining <juju-core:Triaged by cherylj> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1518128>23:57
mupBug #1518131 opened: cmd/jujud/agent: different data races <juju-core:New> <https://launchpad.net/bugs/1518131>23:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!