| natefinch | rebased and fixed conflicts | 00:01 |
|---|---|---|
| wallyworld | natefinch: is it https://jujucharms.com/docs/2.0/introducing-2 or https://jujucharms.com/docs/stable/introducing-2 | 00:02 |
| * natefinch is doing pretty well for having a sleeping toddler in his lap :) | 00:02 | |
| natefinch | wallyworld: evilnick said stable | 00:02 |
| wallyworld | ok | 00:03 |
| natefinch | The works 'now and later' bit is a slight problem. We could use the URL: | 00:03 |
| natefinch | https://jujucharms.com/docs/stable/introducing-2 | 00:03 |
| natefinch | I can create that page in the current stable docs and redirect to /devel/ | 00:03 |
| natefinch | When we release the 2.0 docs in a few days, it will be at that URL anyhow. | 00:03 |
| natefinch | (that was from him) | 00:03 |
| wallyworld | natefinch: i have asked some questions in the PR about the tests | 00:14 |
| wallyworld | eg we should be using PatchExecutable I think | 00:15 |
| natefinch | wallyworld: I didn't even know we had a patch executable | 00:15 |
| wallyworld | we do :-) | 00:15 |
| wallyworld | very useful | 00:16 |
| natefinch | oh god it writes OS dependent scripts. Ouch | 00:16 |
| natefinch | see, that's the nice thing about using the Go executable that we already have, it's already cross-platform | 00:17 |
| wallyworld | but the tests are very messy | 00:17 |
| natefinch | wallyworld: maybe we could address these problems for beta 6? | 00:17 |
| wallyworld | hmmm, i reslly don't like the tests as they are | 00:17 |
| wallyworld | i guess we could | 00:18 |
| natefinch | wallyworld: well, I think the better solution might be to simply not run juju-1 and print 1.x all the time | 00:18 |
| natefinch | wallyworld: and that would clean up the production code and the tests | 00:18 |
| wallyworld | natefinch: but actually, why can't the os.Exec patch just write to stdout without running anything? | 00:19 |
| natefinch | wallyworld: I could patch out the whole call to run anything, it's true. My way lets us get a little closer to testing everything, but it's not truly necessary. we could have a runExec(string path, args ...string) ([]byte, error) and patch that out | 00:22 |
| wallyworld | natefinch: yes, something like that. i am reluctant to just print 1.x if rick has asked for the real version | 00:23 |
| wallyworld | natefinch: bit also, PatchExecutable is used extensively in juju so why do something inconsistent here? | 00:23 |
| natefinch | wallyworld: 'cause patch executable is horrible ;) But mostly, I didn't know it existed. | 00:24 |
| natefinch | wallyworld: also, patch executable doesn't let us verify we're sendingf the right arguments, AFAICT | 00:25 |
| wallyworld | there's a PatchExedcutableEchoArgs | 00:25 |
| natefinch | OMG, that whole file is awful hackery | 00:26 |
| mup | Bug #1572350 opened: juju status shows incorrect message after switching to a controller with no model <docteam> <juju-core:New> <https://launchpad.net/bugs/1572350> | 00:27 |
| mup | Bug #1572353 opened: mismatch at [0].Tag.id: unequal; obtained "2"; expected "1" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1572353> | 00:27 |
| natefinch | wallyworld: I can use that if that's what you think is best. | 00:28 |
| wallyworld | natefinch: if you used PatchExcutableEchoArgs, you could easily verify that "juju version" is called right, and return the expected version to std out in only a few lines of code | 00:29 |
| wallyworld | it doesn't really matter if we consider PacthExdcutable good code or not, it's in our toolbox and is what juju uses and it works | 00:30 |
| natefinch | wallyworld: that's fine. I'll change my code to use it. | 00:31 |
| wallyworld | ty :-) | 00:31 |
| wallyworld | PatchExecutableEchArgs i *think* will work ok | 00:31 |
| wallyworld | for what we need here | 00:31 |
| natefinch | wallyworld: ok | 00:32 |
| mup | Bug #1550586 changed: github.com/juju/juju/tools/lxdclient_test constant overflows int <ci> <i386> <lxd> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1550586> | 00:33 |
| mup | Bug #1572355 opened: provider/maas/volumes_test.go constant overflows int on 386 <ci> <i386> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1572355> | 00:33 |
| natefinch | wallyworld: I'm not sure we can verify the args *and* produce output using what's there. It looks like it's one or the other | 00:36 |
| wallyworld | natefinch: yeah, just looked at the code, it seems so | 00:38 |
| natefinch | wallyworld: I actually have to go for a while... my toddler's awake, and I have to take care of him. Maybe we can address the tests in beta 6? They're not *wrong* per se, even if they're not consistent with the rest of the code. | 00:39 |
| natefinch | wallyworld: I have time later to work on them, just not sure how ASAP this should be | 00:39 |
| natefinch | wallyworld: might be a couple hours | 00:39 |
| wallyworld | hmmm, ok, we need to get this landed asap. i was hoping for some other cleanup also but i guess that can be done in a followup | 00:40 |
| wallyworld | natefinch: i've hit merge | 00:41 |
| natefinch | wallyworld: cool, thanks for the review and the merge. i'll be back on later, we can talk about further cleanup. | 00:42 |
| wallyworld | ok | 00:42 |
| === natefinch is now known as natefinch-afk | ||
| mup | Bug #1572355 changed: provider/maas/volumes_test.go constant overflows int on 386 <ci> <i386> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1572355> | 00:42 |
| mup | Bug #1550586 opened: github.com/juju/juju/tools/lxdclient_test constant overflows int <ci> <i386> <lxd> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1550586> | 00:42 |
| menn0 | cherylj, wallyworld, thumper: I'm seeing a lot of this in failed CI runs from the last 24 hours: | 00:47 |
| menn0 | ERROR juju.state.unit unit.go:720 unit ubuntu/0 cannot get assigned machine: unit "ubuntu/0" is not assigned to a machine | 00:48 |
| menn0 | This is happening when jobs are just deploying the ubuntu charm | 00:48 |
| menn0 | I'm seeing it in functional-ha-recovery and functional-ha-backup-restore | 00:48 |
| menn0 | it's just in the test setup before it tries to enable HA and do other things | 00:49 |
| menn0 | hmmm actually it might just happen when Status is called and a unit is being deployed... | 00:51 |
| mup | Bug #1550586 changed: github.com/juju/juju/tools/lxdclient_test constant overflows int <ci> <i386> <lxd> <regression> <juju-core:Fix Released> <https://launchpad.net/bugs/1550586> | 00:57 |
| mup | Bug #1572355 opened: provider/maas/volumes_test.go constant overflows int on 386 <ci> <i386> <regression> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1572355> | 00:57 |
| sinzui | menn0: yes We see than in the restore tests that claim success, but acutally failed https://bugs.launchpad.net/juju-core/+bug/1569467 | 00:59 |
| mup | Bug #1569467: juju restore-backup does not complete properly <backup-restore> <ci> <regression> <juju-core:Triaged by fwereade> <https://launchpad.net/bugs/1569467> | 00:59 |
| * sinzui just purges 5 instances from us-east-1 left behind by today's tests | 01:00 | |
| thumper | menn0: hmm... | 01:01 |
| thumper | just status related? | 01:02 |
| menn0 | sinzui: a lot of the log files for the failures also appear to be truncated ... activity in the console logs goes on for much longer than what's in the machine logs | 01:03 |
| sinzui | that is odd. I never seen truncated logs before | 01:04 |
| * menn0 hopes it isn't that juju that stops logging | 01:04 | |
| menn0 | I'll do some more digging but things look pretty unhappy right now | 01:04 |
| wallyworld | thumper: ping | 01:24 |
| thumper | wallyworld: hey | 01:24 |
| wallyworld | for you maas BlockSize types, you should use int64 | 01:25 |
| wallyworld | uint64 | 01:25 |
| wallyworld | we do that elsewhere in storage | 01:25 |
| wallyworld | and not that it matters now, because we have just agreed to drop i386, but it fails on i386 | 01:25 |
| wallyworld | due to int overflow | 01:25 |
| wallyworld | but to be consistent with juju/storahe/BlockDevice | 01:26 |
| wallyworld | would be good | 01:26 |
| wallyworld | so gomaasapi.BlockDevice could be updated | 01:26 |
| wallyworld | thumper: you ok with that? | 01:29 |
| thumper | meh | 01:30 |
| thumper | can do | 01:30 |
| wallyworld | thumper: it will avoid casts when copying data | 01:34 |
| thumper | wallyworld: otp right now, so distracted | 01:35 |
| wallyworld | sure np | 01:35 |
| menn0 | sinzui, thumper, cherylj, wallyworld: ok I'm less concerned about the failures now. it looks like we've been running into quota limits | 01:39 |
| menn0 | "cannot run instances: Your quota allows for 0 more running instances" | 01:39 |
| cherylj | fun | 01:39 |
| sinzui | menn0: yes the restore tests are always leaving unit/0 behind because the machine is not known by the restored controller | 01:40 |
| menn0 | I believe sinzui just cleaned up some orphaned instances | 01:40 |
| sinzui | and I did just clean us-east-1 a hour ago | 01:40 |
| menn0 | sinzui, cherylj, wallyworld: because of the quota issues I still can't be sure if my peergrouper changes have helped | 01:41 |
| menn0 | I'll keep an eye on the runs | 01:41 |
| mup | Bug #1543770 changed: Juju 2.0alpha1 does not assign a proper netmask for LXC containers <cpe-critsit> <cpe-sa> <dhcp> <lxc> <maas> <network> <juju-core:Fix Released> <https://launchpad.net/bugs/1543770> | 01:45 |
| thumper | wallyworld: the main reason I didn't was due to schema.ForceInt returning an int | 02:03 |
| thumper | and that is the only reason | 02:03 |
| thumper | could easily do it inside gomaasapi | 02:03 |
| wallyworld | ok | 02:03 |
| wallyworld | thumper: fwiw, iirc, all sizes in juju/storage are uint64 so it will make your life easier later | 02:05 |
| * thumper nods | 02:05 | |
| axw | wallyworld: can you please take a look at https://github.com/go-amz/amz/pull/67 when you have a moment | 02:11 |
| wallyworld | sure | 02:11 |
| wallyworld | sorry, i forgot | 02:11 |
| axw | wallyworld: np, juju PR hasn't had a proper review yet anyway | 02:11 |
| perrito666 | yay go 1.6 made http.Client default transport no longer support file:// protocol | 02:13 |
| perrito666 | at least in windows :p | 02:13 |
| perrito666 | or changed the way it handles file :p | 02:14 |
| wallyworld | axw: lgtm, i assume we will set the new sg tags elsewhere | 02:15 |
| axw | wallyworld: yes, in the juju branch | 02:15 |
| axw | ta | 02:16 |
| perrito666 | well with the pleasure of having fixed this ill go to sleep see you all tomorrow, cheers | 02:17 |
| wallyworld | perrito666: ty. do you have a reference for the change in behaviour? i wonder ehy they did it just on windows | 02:18 |
| perrito666 | Wallyworld so what changed (just confirmed through testing) is the kind of url handled | 02:27 |
| mup | Bug # changed: 1379396, 1456757, 1481133, 1494743, 1534610, 1534619, 1534632, 1534637, 1544853, 1550817, 1550821, 1572355 | 02:28 |
| perrito666 | Windows is different from linux in the necessity to have a drive letter in the path | 02:28 |
| wallyworld | perrito666: ok, i'll look for something in the release notes | 02:28 |
| wallyworld | they must have documented it if the behaviour changed | 02:28 |
| perrito666 | Tomorrow ill hit the code/release notes to see why \\localhost\c$ is no longer accepted and what is now the alternative | 02:29 |
| perrito666 | By default, if the drive letter is omitted c is used and it works | 02:29 |
| perrito666 | Now ill need to figure what is the new way of specifying the drive | 02:29 |
| perrito666 | C u all tomorrow | 02:30 |
| mup | Bug # changed: 1469807, 1534620, 1545045, 1552021, 1559381, 1559382, 1559704 | 02:34 |
| mup | Bug # opened: 1469807, 1534620, 1545045, 1552021, 1559381, 1559382, 1559704 | 02:43 |
| mup | Bug # changed: 1469807, 1534620, 1545045, 1552021, 1559381, 1559382, 1559704 | 02:58 |
| === natefinch-afk is now known as natefinch | ||
| mup | Bug # changed: 1290920, 1421315, 1421621, 1436863, 1455627, 1457575, 1460683, 1488576, 1532831, 1559715, 1568069 | 03:04 |
| mup | Bug #1458588 opened: cannot add charm to storage: io timeout <ci> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1458588> | 03:04 |
| mup | Bug #1572382 opened: Can not add credential to user-defined OpenStack provider in juju 2.0 <openstack-provider> <juju-core:New> <https://launchpad.net/bugs/1572382> | 03:04 |
| natefinch | wallyworld: 1:1? | 03:05 |
| wallyworld | natefinch: sure, otp, one sec | 03:06 |
| natefinch | wallyworld: np | 03:06 |
| mup | Bug # changed: 1260187, 1490656, 1498010, 1498084, 1498175, 1502935, 1514451, 1521220, 1528975 | 03:34 |
| wallyworld | natefinch: next bug for your to do list maybe, bug 1567518 | 03:37 |
| mup | Bug #1567518: Payload commands don't work <juju-core:Triaged> <https://launchpad.net/bugs/1567518> | 03:37 |
| wallyworld | after other stuff is wrapped up | 03:37 |
| natefinch | wallyworld: yeah, I'd been trying to stick to the red ones, but I'm more than happy to fix that one.. I'm sure it must be something dumb. I had looked at it briefly before, but didn't immediately see the problem. | 03:38 |
| wallyworld | ty, will be good to get that fixed | 03:38 |
| wallyworld | thumper: there's a test breakage affecting CI in a maas2 test, i will skip it for now to unblock beta5 | 03:38 |
| wallyworld | TestInstanceVolumesMAAS2 | 03:38 |
| thumper | wallyworld: ok | 03:38 |
| wallyworld | bug 1572353 | 03:39 |
| mup | Bug #1572353: mismatch at [0].Tag.id: unequal; obtained "2"; expected "1" <ci> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1572353> | 03:39 |
| thumper | ta | 03:39 |
| * thumper looks | 03:39 | |
| mup | Bug #1391066 changed: worker/uniter: FAIL: filter_test.go:449: FilterSuite.TestConfigAndAddressEventsDiscarded <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1391066> | 03:40 |
| mup | Bug #1409739 changed: UniterSuite.TestActionEvent failing intermittently <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1409739> | 03:40 |
| mup | Bug #1426394 changed: TestConfigEvents random failure <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1426394> | 03:40 |
| thumper | wallyworld: it is a dict ordering bug | 03:40 |
| wallyworld | thumper: samecontents may fix it | 03:40 |
| thumper | aye | 03:40 |
| * thumper looks | 03:40 | |
| wallyworld | but i didn't want to just assume that order didn't matter | 03:41 |
| wallyworld | without looking a bit deeper | 03:41 |
| wallyworld | thumper: it is a slice isn't it? | 03:41 |
| wallyworld | []storage.Volume | 03:41 |
| wallyworld | hence ny concern about ordering | 03:41 |
| thumper | yes, but it is coming in from python | 03:42 |
| thumper | which may not have strict ordering | 03:42 |
| thumper | let me look deeper | 03:42 |
| thumper | you can skip it now | 03:42 |
| wallyworld | ok | 03:42 |
| thumper | I can unskip for the landing | 03:42 |
| * thumper reads the tests | 03:45 | |
| thumper | wallyworld: yep | 03:46 |
| thumper | the source iterates over a map | 03:46 |
| thumper | and appends into a slice | 03:46 |
| thumper | so ordering is not defined | 03:46 |
| wallyworld | ah, the python source | 03:46 |
| thumper | no | 03:46 |
| thumper | the test creates a dict | 03:47 |
| thumper | no, map | 03:47 |
| * thumper tries to replicate the test failure locally | 03:47 | |
| wallyworld | oh right ok, i didn't look too closely at the test | 03:47 |
| thumper | got it | 03:47 |
| thumper | got a fix | 03:51 |
| thumper | and tested | 03:51 |
| wallyworld | thumper: if you push your fix, i'll stop the landing job | 03:51 |
| thumper | wallyworld: have you seen dave's stress script | 03:51 |
| thumper | ? | 03:51 |
| thumper | wallyworld: pushing now | 03:51 |
| wallyworld | no, don't think so | 03:51 |
| wallyworld | if i have i gorgot | 03:52 |
| wallyworld | forgot | 03:52 |
| mup | Bug #1391066 opened: worker/uniter: FAIL: filter_test.go:449: FilterSuite.TestConfigAndAddressEventsDiscarded <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1391066> | 03:52 |
| mup | Bug #1409739 opened: UniterSuite.TestActionEvent failing intermittently <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1409739> | 03:52 |
| mup | Bug #1426394 opened: TestConfigEvents random failure <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1426394> | 03:52 |
| thumper | http://paste.ubuntu.com/15940883/ | 03:52 |
| thumper | wallyworld: http://reviews.vapour.ws/r/4649/ | 03:54 |
| wallyworld | looking | 03:54 |
| wallyworld | i'll have to keep that script handy | 03:54 |
| thumper | wallyworld: I have it in ~/bin/ as 'stress.sh' | 03:54 |
| thumper | it compiles and links once and runs repeatedly | 03:54 |
| thumper | very handy for intermittent failures | 03:54 |
| wallyworld | indeed | 03:55 |
| wallyworld | thumper: +1, i'll cancel my job | 03:55 |
| thumper | k | 03:55 |
| thumper | I've asked the bot to merge it | 03:56 |
| thumper | it has been accepted | 03:56 |
| mup | Bug # changed: 1391066, 1409739, 1411818, 1426394, 1432654, 1436495, 1440199, 1440205, 1440213, 1440219, 1451104, 1456726 | 04:04 |
| mup | Bug # changed: 1456763, 1459337, 1461578, 1463047, 1463135, 1469777, 1471004, 1471030, 1471308 | 04:16 |
| mup | Bug #1456728 opened: UniterSuite.TearDownTest fails <ci> <test-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1456728> | 04:16 |
| mup | Bug #1457092 opened: InvalidInstanceID.NotFound <bootstrap> <ci> <intermittent-failure> <juju-core:Triaged> <juju-core 1.22:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1457092> | 04:16 |
| mup | Bug #1458992 opened: Uploading tools: closed explicitly <ci> <intermittent-failure> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1458992> | 04:16 |
| menn0 | thumper, axw or wallyworld: https://github.com/juju/juju/pull/5225 | 04:24 |
| wallyworld | looking | 04:24 |
| wallyworld | menn0: nice pickup | 04:25 |
| menn0 | wallyworld: I wasn't able to repro but it because obvious when I looked right to the bottom of the race detector output and saw where one of the goroutines had been created (i.e. a different test) | 04:26 |
| wallyworld | ack | 04:27 |
| thumper | wallyworld, menn0: http://reviews.vapour.ws/r/4651/ | 04:28 |
| menn0 | thumper: looking | 04:29 |
| * wallyworld hugs thumper | 04:29 | |
| thumper | menn0: I really wanted to change schema.ForceInt to return int64 instead of int but that was out of scope for this change | 04:30 |
| thumper | I really hate that scheam.Int returns int64 | 04:30 |
| thumper | but scheam.ForceInt is just int | 04:30 |
| wallyworld | +100 | 04:30 |
| thumper | wallyworld: lp bug 1572353 fix committed | 04:33 |
| mup | Bug #1572353: mismatch at [0].Tag.id: unequal; obtained "2"; expected "1" <ci> <regression> <test-failure> <juju-core:Fix Committed by thumper> <https://launchpad.net/bugs/1572353> | 04:33 |
| wallyworld | i saw :-) | 04:33 |
| wallyworld | ty | 04:33 |
| thumper | np | 04:33 |
| menn0 | thumper: you've only tested for numbers around +/-42 | 04:35 |
| menn0 | thumper: I think you need to test for all numbers | 04:36 |
| menn0 | sort that out will you :-p | 04:36 |
| thumper | heh | 04:36 |
| * menn0 jokes | 04:36 | |
| menn0 | thumper: ship it | 04:36 |
| thumper | for i := 0; i < math.MAX_INT; i++ { check fmt.Sprint(i)... } | 04:36 |
| menn0 | thumper: what about all floating point numbers too :) | 04:37 |
| thumper | I did notice a missed code path | 04:37 |
| menn0 | and all possible strings | 04:37 |
| thumper | for negative float values | 04:37 |
| * thumper will add it | 04:37 | |
| menn0 | thumper: what's that? | 04:37 |
| thumper | -42.5 | 04:38 |
| thumper | the conditional in the float case statement | 04:38 |
| thumper | that checks for v < 0 | 04:38 |
| menn0 | ah right... a missed test not implementation | 04:38 |
| menn0 | you had me looking in the implementation and that looked right | 04:39 |
| thumper | yeah, just the test | 04:39 |
| thumper | sinzui: does the merge bot do juju/schema? | 04:40 |
| natefinch | thumper: easiest way to find out, look at previous commits | 04:41 |
| thumper | doesn't look like it | 04:41 |
| sinzui | thumper: the bot only runs make build and make test | 04:41 |
| redir_ | looks like next is back | 04:41 |
| mup | Bug # changed: 1463399, 1463826, 1464671, 1466525, 1468357, 1468369, 1469196, 1471775, 1479889, 1479942, 1484303, 1484308, 1485013, 1490653, 1494749, 1494754, 1494765, | 04:46 |
| mup | 1494870, 1494876, 1494887, 1494894, 1494938, 1496472, 1502127, 1502149, 1502153, 1502154, 1507637, 1507644, 1534623, 1559313, 1560061, 1560192, 1565827 | 04:46 |
| thumper | wallyworld: https://github.com/juju/gomaasapi/pull/43 | 04:48 |
| mup | Bug # changed: 1535328, 1557264, 1559299, 1559305, 1565831, 1566450, 1566452 | 04:49 |
| mup | Bug # opened: 1535328, 1557264, 1559299, 1559305, 1565831, 1566450, 1566452 | 05:04 |
| mup | Bug # changed: 1384233, 1436407, 1457124, 1458992, 1461965, 1461968, 1461969, 1462409, 1462415, 1467556, 1510129, 1532232, 1535328, 1557264, 1559299, 1559305, 1565831, 1566450, 1566452 | 05:16 |
| mup | Bug #1558803 changed: Manual deploy on ppc64el wants wrong package and agents <ci> <manual-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1558803> | 05:22 |
| axw | wallyworld: probably not till later given the meeting's on soon, but if you can take a look later it'd be much appreciated: https://github.com/juju/juju/pull/5226 | 05:31 |
| wallyworld | sure | 05:31 |
| mup | Bug #1558803 opened: Manual deploy on ppc64el wants wrong package and agents <ci> <manual-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1558803> | 05:37 |
| mup | Bug #1558803 changed: Manual deploy on ppc64el wants wrong package and agents <ci> <manual-provider> <juju-core:Fix Released> <https://launchpad.net/bugs/1558803> | 05:46 |
| hoenir | In order to know the version for windows ,I need to look at the CurrentVersion registry value but there are some windows versions with the same SKU, like for example desktop and server, were can I look to know if I'm running a windows server editior or destktop one, other than looking on ProductName? It's there any integer or bytes number that will give me this answer? | 07:32 |
| voidspace | "nonpersisting-pamala" is a slightly worrying name for a maas node | 08:32 |
| voidspace | I'd quite like it to be persisting thank you very much | 08:32 |
| babbageclunk | axw: ping? | 08:41 |
| axw | babbageclunk: pong, in a meeting atm | 08:46 |
| babbageclunk | axw: ok - let me know when you're free? Just want to confirm stuff before I go off half-cocked again. :) | 08:48 |
| axw | babbageclunk: :) no worries, will do | 08:48 |
| dimitern | voidspace, babbageclunk, frobware: please take a look http://reviews.vapour.ws/r/4653/ | 08:59 |
| voidspace | dimitern: ah, but have you tested on MAAS 2? | 09:01 |
| dimitern | voidspace: not yet, wasn't sure if it'll work, but will run a test now | 09:01 |
| voidspace | dimitern: should do | 09:02 |
| voidspace | dimitern: anyway, straightforward - looks good | 09:02 |
| dimitern | voidspace: thanks, will let you know if it works on 2.0 shortly | 09:02 |
| axw | babbageclunk: sorry, finished now | 09:28 |
| babbageclunk | axw: great, thanks! | 09:29 |
| babbageclunk | axw: I'm already putting device.Name() into the VolumeAttachmentInfo.DeviceName, I think - should I change that to the full /dev/disk/by-dname/ path? | 09:31 |
| babbageclunk | awx: or is it better with the device name. | 09:31 |
| babbageclunk | gah, typo'd your name | 09:31 |
| axw | babbageclunk: is /dev/disk/by-dname *always* available? | 09:32 |
| babbageclunk | axw: yeah, from what blake_r was saying yesterday. | 09:32 |
| axw | babbageclunk: also, is it really "by-dname"? not by-name? | 09:32 |
| axw | ok | 09:32 |
| * axw looks at MAAS docs and sees that it really is | 09:32 | |
| babbageclunk | axw: by-dname | 09:32 |
| voidspace | babbageclunk: so, CreateDevice only lets us create a device with one interface - and AllocateContainerAddresses wants to be able to create devices with multiple interfaces on different subnets | 09:33 |
| voidspace | babbageclunk: so it can't just be an "all in one call" unfortunately | 09:33 |
| voidspace | babbageclunk: still not too bad | 09:33 |
| babbageclunk | axw: do we also want to extract the hardware id from the id_path if it's a by-id one? | 09:33 |
| axw | babbageclunk: typically speaking, a device name (e.g. /dev/sdb) is not guaranteed to be persistent | 09:34 |
| voidspace | dimitern: do we really need to be able to create containers (devices) with multiple nics on different subnets? | 09:34 |
| axw | babbageclunk: we need something unique and persistent for the lifetime of the volume's attachment to the machine | 09:34 |
| axw | babbageclunk: i.e. it must not change if the machine is restarted | 09:34 |
| babbageclunk | axw: ok | 09:34 |
| axw | babbageclunk: for MAAS on KVM, the device names should not change | 09:35 |
| axw | babbageclunk: I can't speak with any authority about by-dname, but it looks to me like it's just the same as the device name | 09:35 |
| axw | babbageclunk: whereas "by-id" should be persistent | 09:35 |
| babbageclunk | axw: ok - so then I should do something like what's there already (in the MAAS 1 version) - use the by-id path to get the hardware id if available | 09:36 |
| axw | babbageclunk: that's my feeling, but if there's one thing that's always guaranteed to be available, and guaranteed to be persistent - then use that | 09:36 |
| babbageclunk | axw: and if not set the device name on the attachment info | 09:37 |
| axw | babbageclunk: yup. doesn't hurt to set the DeviceName field also; HardwareId will be used in preference it it's set | 09:37 |
| babbageclunk | axw: Well, that was what I understood from blake_r | 09:37 |
| babbageclunk | axw: (about by-dname) | 09:38 |
| axw | babbageclunk: so if the by-dname value is always persistent, then you could just put that into DeviceLink | 09:38 |
| axw | babbageclunk: and forget about HardwareId and DeviceName | 09:38 |
| axw | babbageclunk: on the machine, we have a worker that inspects udev to get the device links, so we can match against the one you provide in VolumeInfo | 09:39 |
| babbageclunk | axw: ah, ok - I hadn't clicked DeviceLink was a different field on the attachment info - my brain was autocorrecting it to DeviceName. | 09:39 |
| axw | VolumeAttachmentInfo* | 09:39 |
| axw | babbageclunk: yeah, DeviceName is just "sdb", whereas DeviceLink can be any of the /dev/disk/by-... links | 09:40 |
| babbageclunk | axw: Ok - that sounds like the right thing to do - just DeviceLink on the attachment info. | 09:40 |
| babbageclunk | axw: | 09:40 |
| babbageclunk | Oops | 09:40 |
| axw | babbageclunk: we needed that for GCE, because on there you're expected to use one of those paths to uniquely/persistently identify disks | 09:40 |
| axw | sounds good | 09:40 |
| babbageclunk | axw: awesome - thanks for helping me muddle through all this. | 09:40 |
| axw | babbageclunk: not at all :) | 09:40 |
| axw | babbageclunk: gotta go now, have a nice day | 09:41 |
| babbageclunk | axw: you too! | 09:41 |
| babbageclunk | voidspace: yeah, I guess convenience calls cost flexibility. | 09:42 |
| babbageclunk | voidspace: could we reasonably extend the gomaasapi one to take more info? | 09:42 |
| babbageclunk | voidspace: or does it make more sense to just do it in the provider with the lower-level bits? | 09:43 |
| voidspace | babbageclunk: well, I'm trying to verify if maas supports devices with interfaces on different subnets | 10:24 |
| voidspace | babbageclunk: it looks like the CreateDevice call only supports multiple interfaces on the same subnets | 10:24 |
| voidspace | babbageclunk: so, assuming we *can* have multiple interfaces on different subnets, and do it as separate calls to add / link then there's not much value to it being in gomaasapi over juju | 10:25 |
| voidspace | babbageclunk: we still have to maintain the code wherever it lives... | 10:25 |
| voidspace | babbageclunk: I need to setup a maas that I can test this on though | 10:26 |
| babbageclunk | voidspace: yeah, makes sense | 10:44 |
| TheMue | morning | 10:47 |
| wallyworld | axw: reviewed, have a question about retry | 12:35 |
| mup | Bug #1555391 changed: MachineSuite failed during unit test <2.0-count> <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1555391> | 12:36 |
| mup | Bug #1544849 changed: unit-test loop with juju.worker.uniter.remotestate retry hook timer triggered <2.0-count> <ci> <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1544849> | 12:45 |
| mup | Bug #1545055 changed: TestManageModelRunsUndertaker timed out <2.0-count> <ci> <intermittent-failure> <juju-core:Fix Released> <https://launchpad.net/bugs/1545055> | 12:45 |
| mup | Bug #1544849 opened: unit-test loop with juju.worker.uniter.remotestate retry hook timer triggered <2.0-count> <ci> <intermittent-failure> <ppc64el> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1544849> | 12:57 |
| mup | Bug #1545055 opened: TestManageModelRunsUndertaker timed out <2.0-count> <ci> <intermittent-failure> <juju-core:Fix Released> <https://launchpad.net/bugs/1545055> | 12:57 |
| mup | Bug # changed: 1544849, 1545055, 1567676, 1571947, 1572353 | 13:06 |
| mup | Bug #1567676 opened: windows: networker tries to update invalid device and blocks machiner from working <windows> <juju-core:Fix Released by dimitern> <https://launchpad.net/bugs/1567676> | 13:09 |
| mup | Bug #1571947 opened: bootstrap --upload-tools fails with "cannot start bootstrap instance: missing tools URL" <azure-provider> <bootstrap> <ci> <regression> <upload-tools> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1571947> | 13:09 |
| mup | Bug #1572353 opened: mismatch at [0].Tag.id: unequal; obtained "2"; expected "1" <ci> <regression> <test-failure> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1572353> | 13:09 |
| mup | Bug #1567676 changed: windows: networker tries to update invalid device and blocks machiner from working <windows> <juju-core:Fix Released by dimitern> <https://launchpad.net/bugs/1567676> | 13:15 |
| mup | Bug #1571947 changed: bootstrap --upload-tools fails with "cannot start bootstrap instance: missing tools URL" <azure-provider> <bootstrap> <ci> <regression> <upload-tools> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1571947> | 13:15 |
| mup | Bug #1572353 changed: mismatch at [0].Tag.id: unequal; obtained "2"; expected "1" <ci> <regression> <test-failure> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1572353> | 13:15 |
| === natefinch is now known as natefinch-afk | ||
| babbageclunk | voidspace, dimitern, frobware: reviews please? http://reviews.vapour.ws/r/4655/ | 13:43 |
| dimitern | babbageclunk: looking | 13:43 |
| babbageclunk | (That's a nice quick one) | 13:43 |
| babbageclunk | voidspace, dimitern, frobware: Also this one (a bit more involved, but just tests): http://reviews.vapour.ws/r/4654/ | 13:44 |
| dimitern | babbageclunk: no need to bump gomaasapi rev to use Path() ? | 13:44 |
| babbageclunk | voidspace: man, journald keeps hanging/crashing on me | 13:44 |
| babbageclunk | dimitern: no, it was already there - I didn't end up needing to add HardwareId | 13:45 |
| dimitern | babbageclunk: ok, first one LGTM | 13:45 |
| babbageclunk | dimitern: sweet, thanks! | 13:47 |
| dimitern | babbageclunk: second one also LGTM | 14:03 |
| dimitern | frobware, voidspace, dooferlad, babbageclunk: guys, please take a look at http://reviews.vapour.ws/r/4656/ - first step towards cleaning up a *lot* of legacy code | 14:04 |
| mup | Bug # changed: 1460882, 1503992, 1534627, 1541482, 1551779, 1554700, 1554705, 1555694, 1557380, 1558078, 1561315, 1563932, 1563939, 1563942, 1563950, 1563956, 1564017, 1564395, 1564515, 1566332, 1566362, 1566367, 1566369, 1566431, 1567170, 1567719, 1567721, 1567722, 1567724, 1567726, 1567728, | 14:09 |
| mup | 1567730, 1567732, 1567734, 1567925, 1568669, 1568848, 1568862, 1568925, 1569054, 1569086, 1569386, 1569490, 1569652, 1569654, 1569914, 1569948, 1570473, 1570654, 1571254, 1571476, 1571478, 1571861, 1571901 | 14:09 |
| mup | Bug #1572585 opened: juju ssh spawns many juju and ssh processes <juju-core:New> <https://launchpad.net/bugs/1572585> | 14:09 |
| dimitern | let it rain ! :D | 14:09 |
| dimitern | bugs galore | 14:09 |
| voidspace | reviews galore too | 14:10 |
| mup | Bug #1572585 changed: juju ssh spawns many juju and ssh processes <juju-core:New> <https://launchpad.net/bugs/1572585> | 14:12 |
| mup | Bug # opened: 1460882, 1503992, 1534627, 1541482, 1551779, 1554700, 1554705, 1555694, 1557380, 1558078, 1561315, 1563932, 1563939, 1563942, 1563950, 1563956, 1564017, 1564395, 1564515, 1566332, 1566362, 1566367, 1566369, 1566431, 1567170, 1567719, 1567721, 1567722, 1567724, 1567726, 1567728, | 14:12 |
| mup | 1567730, 1567732, 1567734, 1567925, 1568669, 1568848, 1568862, 1568925, 1569054, 1569086, 1569386, 1569490, 1569652, 1569654, 1569914, 1569948, 1570473, 1570654, 1571254, 1571476, 1571478, 1571861, 1571901 | 14:12 |
| mup | Bug # changed: 1460882, 1503992, 1534627, 1541482, 1551779, 1554700, 1554705, 1555694, 1557380, 1558078, 1561315, 1563932, 1563939, 1563942, 1563950, 1563956, 1564017, 1564395, 1564515, 1566332, 1566362, 1566367, 1566369, 1566431, 1567170, 1567719, 1567721, 1567722, 1567724, 1567726, 1567728, | 14:15 |
| mup | 1567730, 1567732, 1567734, 1567925, 1568669, 1568848, 1568862, 1568925, 1569054, 1569086, 1569386, 1569490, 1569652, 1569654, 1569914, 1569948, 1570473, 1570654, 1571254, 1571476, 1571478, 1571861, 1571901 | 14:15 |
| mup | Bug #1572585 opened: juju ssh spawns many juju and ssh processes <juju-core:New> <https://launchpad.net/bugs/1572585> | 14:15 |
| babbageclunk | dimitern: thanks for reviews! | 14:16 |
| babbageclunk | dimitern: looking at yours now | 14:24 |
| dimitern | babbageclunk: cheers! | 14:24 |
| rogpeppe | is there any way to destroy a model within a controller without connecting to the model's API? | 14:32 |
| rogpeppe | (other than destroying the controller and all its models) | 14:32 |
| voidspace | dimitern: wow, that PR must have been annoying to do | 14:34 |
| voidspace | dimitern: working through it as wll | 14:34 |
| voidspace | *well | 14:34 |
| dimitern | voidspace: it was frustrating, I'm glad it's done and verified to work :) | 14:34 |
| dimitern | if that's the last time I see any of that code will be too early | 14:35 |
| voidspace | dimitern: there's a use of NewSubnetTag in there which can panic | 14:38 |
| dimitern | voidspace: I've replied to your comment | 14:38 |
| voidspace | dimitern: so it might panic in the future, but as it's unlikely at the moment it's ok? | 14:39 |
| dimitern | voidspace: ok, fair enough - AIUI you suggest not to use `subnetID != ""` but names.IsValidSubnet..() instead? | 14:40 |
| voidspace | dimitern: isn't there a way of creating a tag that will error instead of panic - those panic'ing New functions are annoyiing | 14:41 |
| voidspace | *annoying | 14:41 |
| voidspace | dimitern: don't you want to return an error if you get a non-empty-but-invalid subnet id? | 14:42 |
| voidspace | dimitern: i.e. leave the empty check, but check IsValid as well | 14:42 |
| dimitern | voidspace: the only way I can think of is doing the same check New..() does before it panics | 14:42 |
| voidspace | dimitern: yeah, very irritating | 14:42 |
| dimitern | voidspace: ok, will change to check for errors etc. | 14:43 |
| voidspace | dimitern: as these are stored in state do you need a migration? | 14:47 |
| dimitern | voidspace: IIRC migrations are not yet working | 14:49 |
| dimitern | but thumper can know for sure | 14:49 |
| voidspace | dimitern: ok, but will you remember we need one when they are - or are we just not worrying at all about upgrades? | 14:50 |
| babbageclunk | voidspace: what should I be working on now? | 14:50 |
| voidspace | babbageclunk: well, the only remaining task is: Evaluate all tests in environ_whitebox_test.go and see if any ought to be ported to MAAS 2 | 14:51 |
| voidspace | babbageclunk: that should be fun... | 14:51 |
| dimitern | voidspace: I'll send a mail to thumper/menn0 to clarify that; upgrades from pre-2.0 are not yet allowed AIUI | 14:51 |
| voidspace | babbageclunk: with the exception of device related tests of course | 14:51 |
| babbageclunk | voidspace: ok, I guess I'll start looking at that! | 14:52 |
| voidspace | babbageclunk: that should be fun, sorry | 14:56 |
| voidspace | babbageclunk: I'm nearly there on devices | 14:56 |
| babbageclunk | dimitern: What you were suggesting should be cached on the maas environ this morning? Can't remember. | 15:33 |
| dimitern | babbageclunk: the apiversion check now always done in SetConfig | 15:34 |
| babbageclunk | dimitern: So if ecfg.maasServer() & .maasOAuth() haven't changed and env.apiVersion isn't zero then skip the version detection? | 15:37 |
| dimitern | babbageclunk: let me have a look at how it is now | 15:39 |
| mup | Bug #1564670 changed: After dist upgrade Juju 1.X should still be the default <packaging> <juju-core:Fix Released> <juju-core (Ubuntu):Fix Released> <https://launchpad.net/bugs/1564670> | 15:39 |
| mup | Bug #1572634 opened: help text for juju logout needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1572634> | 15:39 |
| mup | Bug #1572637 opened: help text for juju change-user-password needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1572637> | 15:45 |
| dimitern | babbageclunk: hmm.. so what I thought is just verifying whether maasEnviron.apiVersion is empty and only then doing the version check | 15:49 |
| dimitern | babbageclunk: it could be done with a guard mutex, like SupportedArchitectures() | 15:50 |
| mup | Bug #1572637 changed: help text for juju change-user-password needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1572637> | 15:51 |
| babbageclunk | dimitern: ok - will that be a problem if the maas server url changes? Is that something that even makes sense? | 15:52 |
| dimitern | babbageclunk: it cannot change for an existing model | 15:52 |
| babbageclunk | dimitern: ok | 15:53 |
| babbageclunk | dimitern: There's already a guard mutex in SetConfig - seems like that would cover this, right? | 15:55 |
| babbageclunk | dimitern: so really this is just an early return if env.apiVersion is already set. | 15:55 |
| babbageclunk | dimitern: is it por | 15:56 |
| babbageclunk | gah | 15:56 |
| dooferlad | frobware: I am not seeing the bridge script run at all on a precise node. Odd. | 15:56 |
| dimitern | babbageclunk: that could work as well, yeah | 15:56 |
| babbageclunk | dimitern: is it possible for someone to upgrade their maas from 1.9 to 2.0 underneath a Juju model? | 15:57 |
| babbageclunk | dimitern: (sorry if these are crazy questions) | 15:57 |
| frobware | dooferlad: odd indeed. | 15:58 |
| dimitern | babbageclunk: it's possible - one of the many ways to shoot yourself in the foot :) | 15:58 |
| dooferlad | frobware: looks like the file isn't added to the file system. | 15:58 |
| frobware | dooferlad: odd. :) Because I have tried this in the past as that's where I ran into the --<option> incompatibilities. | 15:59 |
| dimitern | babbageclunk: but we're not trying to handle this case - for none of the providers AFAICS | 15:59 |
| babbageclunk | dimitern: ok | 15:59 |
| dooferlad | frobware: http://paste.ubuntu.com/15951618/ | 16:00 |
| dooferlad | I put in the "Done bridging..." message. If the script is found you also get a "Bridging..." message. | 16:01 |
| frobware | dooferlad: line 13, unlucky for some... | 16:01 |
| dooferlad | frobware: indeed | 16:01 |
| frobware | dooferlad: is this one the first boot, or second? | 16:01 |
| dooferlad | frobware: not sure. | 16:01 |
| frobware | dooferlad: it's the second, then to be expected as we `trap 'rm -f /tmp/add-juju-bridge.py' so that it doesn't run again. | 16:02 |
| dooferlad | frobware: that is the only mention of it in /var/log/cloud-init-output.log | 16:02 |
| dooferlad | frobware: is that overwritten at each boot? | 16:02 |
| frobware | dooferlad: dunno for sure | 16:03 |
| dooferlad | frobware: there is only one interfaces file and it hasn't been bridged, which is why I went looking. | 16:04 |
| frobware | dooferlad: I have no nodes atm (tis deliberate)... | 16:04 |
| mup | Bug #1572382 changed: Can not add credential to user-defined OpenStack provider in juju 2.0 <openstack-provider> <juju-core:Invalid> <https://launchpad.net/bugs/1572382> | 16:09 |
| mup | Bug #1572637 opened: help text for juju change-user-password needs improving <helpdocs> <juju-core:Triaged> <https://launchpad.net/bugs/1572637> | 16:09 |
| mup | Bug #1572382 opened: Can not add credential to user-defined OpenStack provider in juju 2.0 <openstack-provider> <juju-core:Invalid> <https://launchpad.net/bugs/1572382> | 16:12 |
| mup | Bug #1572382 changed: Can not add credential to user-defined OpenStack provider in juju 2.0 <openstack-provider> <juju-core:Invalid> <https://launchpad.net/bugs/1572382> | 16:15 |
| mup | Bug #1386219 changed: Usability: adding a large number of units takes too long <deploy> <performance> <scale-testing> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1386219> | 16:40 |
| mup | Bug #1386219 opened: Usability: adding a large number of units takes too long <deploy> <performance> <scale-testing> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1386219> | 16:43 |
| mup | Bug #1386219 changed: Usability: adding a large number of units takes too long <deploy> <performance> <scale-testing> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1386219> | 16:46 |
| babbageclunk | voidspace: did you forget what day it is? | 16:52 |
| voidspace | babbageclunk: yes | 16:53 |
| babbageclunk | voidspace: :) | 16:53 |
| voidspace | babbageclunk: hah, no I just copied and pasted and forgot to change it | 16:54 |
| === natefinch-afk is now known as natefinch | ||
| natefinch | sinzui, mgz: what's our 2.0 upgrade plan for non-ubuntu users? Just realized the fix I made for bug #1564622 probably should be ubuntu-only | 16:59 |
| mup | Bug #1564622: Suggest juju1 upon first use of juju2 if there is an existing JUJU_HOME dir <juju-release-support> <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1564622> | 16:59 |
| natefinch | cherylj: ^ | 17:02 |
| sinzui | natefinch: Just install the new package. it replaces the old package in the cas of windows clients. Centos and osx packages are just dirs in the $PATH. | 17:02 |
| natefinch | sinzui: uh, that's a problem for windows, isn't it? If someone wants to run them side by side. | 17:03 |
| sinzui | natefinch: could be | 17:03 |
| natefinch | sinzui: it's probably trivial to get 2.0 to install side by side with 1.x, probably just need to change the directory name we install to, and probably the installer UUID. | 17:04 |
| sinzui | natefinch: I think inno setup allows you to choose an alternate location. | 17:04 |
| natefinch | sinzui: well, yes, but if the AppId is the same as the old appId, it'll remove the old one. I think we want to change the AppId to a new UUID, so it won't remove the old one | 17:05 |
| natefinch | sinzui: and probably change the app name to "Juju 2.0" (which doesn't change the executable name, just how it shows up in add/remove programs and the start menu) | 17:06 |
| sinzui | natefinch: I will report the bug to get this done | 17:09 |
| natefinch | sinzui: while we're in there, we should change the URL from juju.ubuntu.com to jujucharms.com | 17:10 |
| sinzui | yes | 17:13 |
| natefinch | sinzui: how about homebrew? I presume we have to change something there to get them side by side. | 17:16 |
| natefinch | sinzui: my knowledge of homebrew doesn't extend much past knowledge of its existence. | 17:16 |
| sinzui | natefinch: We could propose that and they may accept it | 17:16 |
| natefinch | sinzui: I think we should. If we don't have backwards or forwards compatibility, people need to be able to run side by side. | 17:17 |
| === redir is now known as redir_afk | ||
| redir_afk | bbiab ~30 minutes | 17:39 |
| redir | natefinch, ericsnow: review please http://reviews.vapour.ws/r/4661/ | 18:43 |
| ericsnow | redir: k | 18:43 |
| redir | ericsnow: when you have a minute of course | 18:43 |
| cherylj | fwereade: if you're still around: https://bugs.launchpad.net/juju-core/+bug/1572237/comments/5 | 18:51 |
| mup | Bug #1572237: juju rc1 loses agents during a lxd deploy <lxd-provider> <juju-core:Triaged by fwereade> <https://launchpad.net/bugs/1572237> | 18:51 |
| mup | Bug #1572695 opened: Manual add-machine creates additional broken machine <ci> <intermittent-failure> <manual-provider> <precise> <juju-core:Triaged> <https://launchpad.net/bugs/1572695> | 18:52 |
| alexisb | cherylj, I think he is out for the rest of the day | 18:55 |
| TheMue | heya cherylj and alexisb | 18:56 |
| * TheMue is still in with one eye while coding in his hotel room | 18:56 | |
| perrito666 | wow utils tests are seriously not windows compatible | 18:58 |
| TheMue | perrito666: maybe windows is not unit test compatible | 18:59 |
| natefinch | TheMue: if so, only because we made it so :/ | 19:00 |
| TheMue | natefinch: did anybody ever expected our bash on win? ;) | 19:01 |
| natefinch | TheMue: right? I think that's really cool. I think someone said they tried ubuntu's juju in windows' bash, and it didn't work, but I didn't see any more details. | 19:03 |
| TheMue | natefinch: juju simply is cool | 19:04 |
| TheMue | natefinch: I'm currently working with ansible. no real environment/provider abstraction, no hiding of operating systems, more scripted approach, and nostuff like hooks or actions | 19:05 |
| perrito666 | wow, hold that thought, the tests dont pass on linux either :| | 19:05 |
| TheMue | perrito666: ouch | 19:05 |
| perrito666 | something wrong with my repo... git, I hate you | 19:06 |
| mup | Bug #1572695 changed: Manual add-machine creates additional broken machine <ci> <intermittent-failure> <manual-provider> <precise> <juju-core:Triaged> <https://launchpad.net/bugs/1572695> | 19:07 |
| perrito666 | could anyone run utils test suite for utils master and let me know if they have a success? | 19:07 |
| mup | Bug #1572695 opened: Manual add-machine creates additional broken machine <ci> <intermittent-failure> <manual-provider> <precise> <juju-core:Triaged> <https://launchpad.net/bugs/1572695> | 19:10 |
| cherylj | perrito666: I get "http: TLS handshake error from 127.0.0.1:56350: remote error: bad certificate" | 19:11 |
| perrito666 | what version of go? | 19:11 |
| cherylj | go 1.5 | 19:11 |
| cherylj | I'm on wily still | 19:11 |
| perrito666 | mm, anyone with 1.6? | 19:11 |
| cherylj | heh | 19:11 |
| perrito666 | cherylj: tx, I believe the error lies in the go version | 19:12 |
| perrito666 | as it is in exec.Exec | 19:12 |
| cherylj | I see | 19:12 |
| cherylj | I'm not advanced enough | 19:12 |
| cherylj | :P | 19:12 |
| TheMue | Oh, tomorrow is 16.04 release? Wow, thought it would be next week. | 19:13 |
| natefinch | perrito666: have you run hodeps? | 19:14 |
| natefinch | perrito666: godeps | 19:14 |
| perrito666 | yup | 19:15 |
| perrito666 | packaging/manager/manager_test.go:271: too few values in struct initializer | 19:15 |
| perrito666 | packaging/manager/utils_test.go:50: too few values in struct initializer | 19:15 |
| perrito666 | packaging/manager/utils_test.go:88: too few values in struct initializer | 19:15 |
| natefinch | perrito666: lol, yep, failures | 19:17 |
| * perrito666 picardfacepalms | 19:18 | |
| perrito666 | so, are we now 1.6 people? | 19:19 |
| natefinch | we are | 19:19 |
| natefinch | officially | 19:19 |
| perrito666 | good so if I change the tests we become 1.6 people only :) | 19:19 |
| natefinch | yep | 19:20 |
| natefinch | perrito666: looks like 1.6 changed exit error: the returned ExitError now holds a prefix and suffix | 19:20 |
| natefinch | perrito666: oh, that doesn't quite apply... but I'm sure it's just because they added a field to exiterror | 19:21 |
| perrito666 | natefinch: is it? I dont see that in the api doc | 19:21 |
| perrito666 | https://golang.org/pkg/os/exec/#ExitError | 19:21 |
| perrito666 | yes, they most likely did | 19:22 |
| natefinch | perrito666: sorry, I should copy more: he returned ExitError now holds a prefix and suffix (currently 32 kB) of the failed command's standard error output | 19:22 |
| perrito666 | I am guessing its stderr | 19:22 |
| natefinch | perrito666: which is the Stderr field | 19:22 |
| natefinch | perrito666: the backwards compatibilty guarantee only holds if we're careful to use keyed fields... i.e., if we'd made that declaration ExitError{ProcessState: &state } then it would still compile | 19:23 |
| perrito666 | yep | 19:23 |
| perrito666 | we should always do that | 19:23 |
| natefinch | yep. my editor warns me when there's code that doesn't do that | 19:24 |
| perrito666 | I really dont get why someone wouldnt it isnt like you are charged by the character | 19:24 |
| natefinch | from golint or govet, I forget which | 19:24 |
| perrito666 | sinzui: bugs against juju/utils should go in juju-core launchpad too? | 19:25 |
| sinzui | perrito666: Yes | 19:25 |
| mup | Bug #1572700 opened: Support co-installable wind clients <windows> <juju-core:Triaged> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1572700> | 19:25 |
| natefinch | ahh.. it's go vet. We run that on the merge bot for juju core... I'm guessing we're not on juju/utils for some reason | 19:26 |
| natefinch | sinzui, mgz: ^ shouldn't we run go vet for the merge bot for juju utils? The code that breaks the current unit tests in 1.6 should have failed go vet even in earlier versions of go. | 19:27 |
| perrito666 | there you go, windows tests on utils are now an issue | 19:27 |
| sinzui | natefinch: ah, very nice to know. I will discussi this with mzg. I think we want this for all juju/* projects right? | 19:28 |
| natefinch | sinzui: definitely. It detects bugs and places which might become bugs later | 19:28 |
| natefinch | (like this) | 19:29 |
| perrito666 | redir: hey, saw your comment, the tests currently in place reviewboard messed everything | 19:30 |
| perrito666 | could you please check https://github.com/juju/utils/pull/205/files ? | 19:30 |
| perrito666 | also ill need a second pair of eyes on that? natefinch ? its a short one https://github.com/juju/utils/pull/205/files | 19:30 |
| mgz | yeah, we maybe want to throw in vet with some settings as a standard part of the gating | 19:31 |
| natefinch | perrito666: kk | 19:32 |
| * perrito666 rips his shirt and screams windows gating <in the voice of kirk yelling kahn> | 19:32 | |
| redir | perrito666: claro! | 19:32 |
| redir | looking | 19:32 |
| redir | mgz: +1 | 19:34 |
| natefinch | perrito666: hm... go vet fails 102 times for utils... | 19:35 |
| natefinch | perrito666: but at least that gets us to compilation | 19:35 |
| perrito666 | natefinch: it was not me :p | 19:35 |
| perrito666 | but yeah, no pre push hook for utils | 19:36 |
| mup | Bug #1572700 changed: Support co-installable wind clients <windows> <juju-core:Triaged> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1572700> | 19:37 |
| perrito666 | natefinch: so do you or do I send the mail scolding everyone on the use of utils? | 19:38 |
| redir | perrito666: Looking at the GH PR I have a couple other questions, mostly because my windows knowledge consists of cobwebs and dust. | 19:38 |
| perrito666 | redir: shoot | 19:39 |
| natefinch | perrito666, mgz, sinzui: go vet actually fails on juju/juju too... I bet we're eliding the check for composite literals, since there are 1025 failures of that type in juju/juju | 19:39 |
| redir | perrito666: is the use of that file url on windows always for powershell? | 19:39 |
| sinzui | ouch | 19:39 |
| mgz | natefinch: yeah, or still on an older vet version | 19:39 |
| redir | perrito666: does it need to have triple slash? file:///c:/foo/bar | 19:40 |
| natefinch | mgz: ouch | 19:40 |
| perrito666 | redir: no it doesnt | 19:40 |
| natefinch | redir: the triple slash comes from having an empty drive letter, so file:///foo/bar or file://c:/foo/bar | 19:41 |
| redir | perrito666: natefinch OK, tx. LGTM then. | 19:41 |
| natefinch | perrito666: lgtm | 19:41 |
| * perrito666 $$merge$$s and then wonders if the bot is there :p | 19:42 | |
| mup | Bug #1572700 opened: Support co-installable wind clients <windows> <juju-core:Triaged> <juju-release-tools:Triaged> <https://launchpad.net/bugs/1572700> | 19:49 |
| natefinch | mgz: why are we on an old version of go vet? Just to avoid some of the checks? | 19:54 |
| mup | Bug #1572703 opened: utils tests are broken in windows. <juju-core:New> <https://launchpad.net/bugs/1572703> | 19:55 |
| mup | Bug #1572707 opened: 2.0b5: panic when running juju register <juju-release-support> <landscape> <juju-core:Triaged> <https://launchpad.net/bugs/1572707> | 19:55 |
| * perrito666 runs the whole test suite for just one deps change and cries over his tea | 19:57 | |
| natefinch | perrito666: I usually just do a test compile to make sure everything compiles, on the assumption that subtle behavior won't have changed (and if it does, CI will catch that). | 19:59 |
| natefinch | perrito666: go test ./... -run=XXX | 19:59 |
| perrito666 | natefinch: I never know when changing utils | 20:01 |
| alexisb | redir, do you know if there are plans, or have been plans for updating help text for the sapces commands? | 20:08 |
| redir | alexisb: not off the top of my head, but I'll search LP for something | 20:09 |
| alexisb | redir, k | 20:09 |
| alexisb | thanks | 20:10 |
| redir | and ask pmatulis | 20:11 |
| thumper | morning | 20:15 |
| thumper | voidspace: if you appear online, would love a quick chat catchup to see if there is something I can do to help with the container networking WIP | 20:15 |
| TheMue | morning thumper | 20:17 |
| thumper | o/ TheMue | 20:17 |
| perrito666 | one line change has conflicts... I really was someone bad in my past life | 20:27 |
| natefinch | is it in dependencies.tsv? | 20:28 |
| perrito666 | yes | 20:28 |
| natefinch | figured | 20:28 |
| natefinch | we should really rename that to conflicts.tsv | 20:28 |
| natefinch | perrito666: I started working on an auto-conflict resolution tool for dependencies.tsv. It's really totally mechanical most of the time | 20:28 |
| perrito666 | could anyone review my one line change? http://reviews.vapour.ws/r/4666/ | 20:33 |
| natefinch | perrito666: I was trying to think up something snarky to say but... nah. Ship it. | 20:34 |
| === urulama is now known as urulama|____ | ||
| voidspace | thumper: hey, hi | 21:22 |
| voidspace | thumper: I need deviceInterfaceInfo porting to maas 2 - which is pretty trivial | 21:23 |
| voidspace | thumper: then I need to write tests | 21:23 |
| voidspace | thumper: and get my KVM properly configured with multiple subnets and machines with multiple nics | 21:24 |
| voidspace | thumper: I failed to do that today | 21:24 |
| thumper | voidspace: anything I can help with, or shall I do sprint prep | 21:24 |
| voidspace | thumper: so if you can get a network config for virt-manager that gives me multiple subnets that would be awesome | 21:24 |
| voidspace | thumper: but otherwise, no - I think we're good | 21:24 |
| voidspace | thumper: should be ready to land tomorrow - and manually tested on Friday probably | 21:25 |
| thumper | \o/ | 21:25 |
| voidspace | thumper: I also need to setup my hardware maas | 21:25 |
| voidspace | thumper: then it's just bug hunting :-) | 21:25 |
| voidspace | thumper: thanks for all your help, it's been fun | 21:25 |
| thumper | cheers | 21:25 |
| thumper | it has been good | 21:25 |
| mup | Bug #1572736 opened: Cannot see 'status' from two different controllers <juju-core:New> <https://launchpad.net/bugs/1572736> | 21:31 |
| arosales | cherylj: I am guessing juju status has a controller flag I missed? | 21:40 |
| arosales | sorry, saw your comment now. | 21:41 |
| cherylj | :) | 21:41 |
| arosales | cherylj: be nice to have that in "juju help status" :-) | 21:41 |
| mup | Bug #1572736 changed: Cannot see 'status' from two different controllers <juju-core:Invalid> <https://launchpad.net/bugs/1572736> | 21:53 |
| mup | Bug #1572741 opened: list-controllers and list-models doesn't list cloud <juju-core:New> <https://launchpad.net/bugs/1572741> | 21:53 |
| mup | Bug #1572746 opened: juju help status missing controller syntax <juju-core:New> <https://launchpad.net/bugs/1572746> | 21:53 |
| thumper | um... wat? | 21:55 |
| thumper | arosales: what do you mean "status from different controllers" ? | 21:55 |
| thumper | you get status on a model, not a controller | 21:55 |
| redir | brb reboot | 21:56 |
| arosales | thumper: I was looking for the syntax "juju status -m <controller>:<model>" | 22:12 |
| arosales | thumper: specifically I wanted to watch status on tow different models on two different controllers | 22:13 |
| thumper | ah | 22:13 |
| arosales | but help only specified -m, thus I opened up 1572746 | 22:14 |
| arosales | while I am bugging here is the juju 2.0 equivalent for "juju action fetch <action-id>" ? | 22:15 |
| arosales | I suspected it would be behind show-action-output, but that only shows completed status not data returned | 22:15 |
| mgz | arosales: that sounds like a bug | 22:17 |
| arosales | mgz: ok, I'll open a bug on it | 22:20 |
| bogdanteleaga | arosales: what output are you getting? | 22:20 |
| arosales | bogdanteleaga: the action output | 22:24 |
| arosales | bogdanteleaga: juju action fetch <action-id> | 22:24 |
| arosales | was the 1.25 syntax to get more data on the action ran | 22:24 |
| arosales | but I don't see a "fetch" equivalent in 2.0 :-/ | 22:25 |
| bogdanteleaga | yeah, I meant what does that show exactly? | 22:25 |
| bogdanteleaga | it's just been renamed | 22:25 |
| arosales | bogdanteleaga: It varies by service | 22:25 |
| arosales | bogdanteleaga: ah great, whats the rename? | 22:26 |
| arosales | I thought it may be behind "show-action-output" and I didn't see any other commands in juju help commands that indicated it may be a different command | 22:27 |
| bogdanteleaga | arosales, yeah, it should be show-action-output | 22:28 |
| bogdanteleaga | I was curious if you also get the enqueued, starting, completed times, or only the status | 22:29 |
| arosales | bogdanteleaga: http://paste.ubuntu.com/15957254/ is what I have thus far | 22:32 |
| arosales | I get status, and completed times | 22:32 |
| arosales | I just need "fetch" for additional details | 22:32 |
| bogdanteleaga | arosales, interesting, could you also try running juju run with some command | 22:34 |
| bogdanteleaga | and then looking at the actions? | 22:34 |
| bogdanteleaga | it should also queue actions | 22:34 |
| arosales | bogdanteleaga: do you want that run with an action or just a shell command? | 22:34 |
| bogdanteleaga | arosales, shell command should be fine | 22:35 |
| arosales | ok | 22:35 |
| bogdanteleaga | see if juju run shows something different from show-action-status afterwards | 22:35 |
| mgz | like, arosales, just file the bug with the command + output you expect from 1.25 and what you do and get instead with 2.0 | 22:35 |
| arosales | mgz: will do it jus seemed bogdanteleaga thought this was just a rename | 22:37 |
| mgz | arosales: the bug is it's intended to just be a rename, if it's different then... | 22:37 |
| arosales | I agree its a bug | 22:37 |
| arosales | I would be surprised to see it was a rename as I searched through help output | 22:38 |
| bogdanteleaga | arosales, can you point me to a simple charm that has some actions defined? | 22:38 |
| mgz | beta4 has under help commands "show-action-output alias for 'action fetch'" | 22:38 |
| arosales | bogdanteleaga: per your request http://paste.ubuntu.com/15957322/ | 22:39 |
| arosales | I don't connect "run" with "actions" though | 22:39 |
| bogdanteleaga | arosales, for example https://paste.ubuntu.com/15957293/ | 22:40 |
| arosales | bogdanteleaga: see my previous pasebin @ http://paste.ubuntu.com/15957254/ | 22:41 |
| arosales | charm and actions in there | 22:41 |
| bogdanteleaga | arosales, not sure if my machine'll handle a big bundle :P | 22:41 |
| arosales | 5 unites, not too bad | 22:42 |
| bogdanteleaga | I'll make a simple one | 22:42 |
| wallyworld | perrito666: axw: redir: can we have standup now to avoid a clash with my next meeting? | 22:42 |
| axw | wallyworld: sure, I'll be there in a couple minutes | 22:43 |
| arosales | mgz: in beta5 I see output in help such as "show-action-status show results of all actions filtered by optional ID prefix" | 22:44 |
| mgz | arosales: things change fast :) | 22:44 |
| arosales | mgz: but will confirm 1.25 fetch output is different and file a bug if so | 22:44 |
| arosales | mgz: just tyring to test your latest bits :-) | 22:44 |
| mgz | arosales: https://github.com/juju/juju/pull/5142 is the change | 22:45 |
| arosales | does alternatives work with beta5 to go back to juju 1.25 or should I specifically just prefix the binary path for juju 1.25? | 22:47 |
| mgz | arosales: you can use the juju-1 name | 22:47 |
| arosales | mgz: thanks | 22:48 |
| perrito666 | wallyworld: oops, missed your msg, still valid? | 22:49 |
| wallyworld | perrito666: yep | 22:49 |
| mup | Bug #1572772 opened: URLsSuite.TestImageMetadataURL paths fail on windows <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1572772> | 22:53 |
| bogdanteleaga | arosales, https://paste.ubuntu.com/15957449/ | 22:55 |
| bogdanteleaga | are you sure the charm actually calls action-set? | 22:55 |
| arosales | bogdanteleaga: I am confirming that namenode and resourcemanger do that now. I you show results in our show-action-output | 22:59 |
| perrito666 | really? concatenating paths with + ? cmon people >:( | 23:02 |
| perrito666 | k ppl, lots of tests to run on windows, ill be afk, cheers | 23:11 |
| mup | Bug #1571053 changed: container networking lxd 'Missing parent for bridged type nic' <ci> <lxd> <juju-core:Fix Released> <https://launchpad.net/bugs/1571053> | 23:23 |
| mup | Bug #1572781 opened: tools info mismatch on arch with lxd containers <ci> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1572781> | 23:23 |
| mgz | hi OCR-antipode, simple review please: https://reviews.vapour.ws/r/4667/ | 23:28 |
| mgz | cmars: thanks :) | 23:30 |
| cmars | mgz, lol i guess that name change didn't cascade into unix | 23:30 |
| mwhudson | hah juju does not compile with go tip | 23:37 |
| mgz | mwhudson: ^that change is for you | 23:41 |
| mgz | axw: is there any chance bug 1572781 is a dupe/other symptom of bug 1571832 | 23:42 |
| mwhudson | mgz: <3 | 23:42 |
| mup | Bug #1572781: tools info mismatch on arch with lxd containers <ci> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1572781> | 23:42 |
| mup | Bug #1571832: Respect the full tools list on InstanceConfig when building userdata config script. <tech-debt> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1571832> | 23:42 |
| axw | mgz: le sigh. another symptom of 1571832 | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!