[08:51] dimitern: quick review of this? https://github.com/juju/gomaasapi/pull/46 [08:51] babbageclunk: looking [08:51] dimitern: it turns out that as long as the methods return nil literally, the interface values compare == to nil [08:52] babbageclunk: hmm really? Won't the nil be wrapped still in an nil interface value, which itself is not nil? [08:53] dimitern: as long as both the type pointer and the value pointer are nil it'll == nil [08:54] dimitern: but returning something like i.subnet when it's nil will set the type pointer. [08:55] babbageclunk: you're correct, I've just tried this: http://play.golang.org/p/dQSGV-JQ87 [08:56] babbageclunk: so the compiler does the right thing as long as you return an untyped nil [08:56] dimitern: yup - and that means we can keep the interface nice while getting the right behaviour [08:56] babbageclunk: sweet! [08:57] dimitern: :) [08:59] dimitern: frobware: will be a couple of minutes late to standup [08:59] urgent coffee emergency [08:59] voidspace: np [09:00] sweet, opportunistically grabbing a tea too then [09:01] babbageclunk: reviewed [09:02] mgz: how's the release shaping up? Is CI happy or do we need some extra pokinG? [09:42] voidspace: https://bugs.launchpad.net/maas/+bug/1573046 [09:42] Bug #1573046: 14.04 images not available for commissioning as distrio-info --lts now reports xenial [09:52] voidspace: I got kicked out, back into standup HO again? [09:52] frobware: I'm still there [10:05] dooferlad: the precise /tmp issue - I wonder how it ever worked then [10:06] frobware: I don't know, but it definitely happens. [10:07] dimitern, frobware, voidspace: review please? https://github.com/juju/juju/pull/5271 [10:07] also, trying to post a comment on a bug on launchpad is timing out - is that normal? [10:07] nvm - fine now [10:10] babbageclunk: LGTM, thanks! [10:10] man, juju on maas is really neat when it's all working smoothly. [10:10] dimitern: Thanks! [10:10] babbageclunk: that was a difficult review... [10:10] dimitern: that's what a review should look like - not 17 pages! ;-) [10:11] (I jest - remove as much code as you want...) [10:11] voidspace: sorry man - I tried to keep it to a 1-line change but it wouldn't compile without the other one. [10:11] babbageclunk: yeah, I have the same change in my branch [10:12] dimitern: I can confirm that lxd doesn't work on maas for neither trusty nor xenial [10:13] dimitern: due to this bug https://bugs.launchpad.net/juju-core/+bug/1568895 [10:13] Bug #1568895: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty [10:13] babbageclunk: it should be smooth if we (and the maas guys) are doing it properly :) [10:13] dimitern: :) [10:13] voidspace: oh, not good :/ I'll give it a try here with 1.9 and 2.0 on xenial [10:14] I also can't commission new nodes at the moment [10:14] voidspace: some reviews are like that :P [10:14] which frobware reckons is probably due to the xenial transition [10:14] not an issue for me right now, but will be soon [10:14] heh, yea [10:20] babbageclunk: if you can bootstrap ok now, you can test a few things - e.g. constraints selection for nodes, bindings, deploying mult-nic lxd backed by a device, ideally as far as checking whether network-get works [10:22] dimitern: can't test lxd, multi-nic or otherwise [10:22] voidspace: 'otherwise' should work (i.e. with lxc) [10:22] dimitern: well, yes "not lxd" works... [10:23] voidspace: as long as it works for lxc (and kvm) at least we know the multi-nic code path is exercised [10:23] then it's down to fixing lxd I guess [10:24] dimitern: by the way - how is AllocateContainerAddresses tested in the maas provider [10:24] (again) [10:24] dimitern: ok - I'll probably need some hand-holding for those. [10:24] dimitern: not directly as far as I can tell [10:24] I'm writing tests for the new code path [10:24] babbageclunk: sure, just ask [10:24] voidspace: not tested except manually (live) I'm afraid [10:24] naughty :-/ [10:25] who let that past review! [10:25] easier to test with the new gomaasapi though [10:25] voidspace: yeah, but at least we can test it properly now [10:28] babbageclunk: for testing constraints, I'd suggest trying to add a machine with --constraints='...', once for each type (arch, mem, cpu, etc.) on its own, then removing the machine with --force before trying the next [10:30] ok [10:31] dimitern, voidspace: man, reading through gomaasapi/testservice.go was pretty alarming! Basically having to re-implement a baby MAAS! [10:31] different combos are also useful to test, and constraints with negatives as well (tags=^mytag1,^othertag, same for spaces=) [10:32] babbageclunk: yeah, and that's a simpler test double than we use for ec2 [10:32] dimitern: ouch [10:32] babbageclunk: yep :-) [10:38] frobware: have replied to that review... [10:42] Bug #1574564 opened: Juju tools 1.25.5 not found in https://streams.canonical.com/juju/tools/releases/ [10:44] voidspace, frobware, babbageclunk: http://reviews.vapour.ws/r/4697/ please, take a look (one page diff this time :) [10:52] babbageclunk, dimitern, voidspace: FWIW, I feel quite strongly that complex test doubles are very smelly -- for individual interactions, explicit canned request/response is usually tractable, and for broader tests there's no substitute for a real maas [10:54] fwereade: agreed - we're moving the low-level MAAS API interactions and tests inside gomaasapi itself, and using a pre-canned http server for higher-level interactions [10:55] babbageclunk, dimitern, voidspace: and it seems like a bad deal to devote effort to exactly aping a substrate -- it's very hard to maintain, and it means that the test infrastructure is biased *against* being able to test weird responses [10:55] dimitern, cool [11:15] frobware, voidspace, babbageclunk: related, but simpler review for the names package: http://reviews.vapour.ws/r/4698/ [11:18] dimitern: is there a way to ignore whitespace differences in reviewboard or github? The vertical alignment that gofmt does makes it hard to see the real change in lots of places. (The checkboxes in reviewboard don't seem to do anything for the changes I'm looking at.) [11:19] babbageclunk: I don't think so, but does it look better on github? [11:20] dimitern: oh-ho! https://github.com/blog/967-github-secrets [11:21] dimitern (and frobware): add ?w=1 on the end of the url [11:21] babbageclunk: nice! I knew there was something like that, but haven't used it yet [11:21] babbageclunk: I was looking for something like that about 30 mins ago when purveying dimitern's PR... thx [11:23] frobware: fwiw I try to make individual commits make sense on their own [11:23] dimitern: ack. I just find it a toss-up which UI is better. GH or RB. [11:33] ok, upgraded both maas-es to latest versions (1.9.1+bzr4543-0ubuntu2 (trusty1) and 2.0.0 (beta4+bzr4944), respectively) now bootstrapping to see if lxd will work [11:36] fwereade: hey, I know we don't usually do our 1:1s, but I have a few things to discuss if you have 15-20m time? [11:38] we can do it later/tommorow as well [11:40] voidspace, frobware, babbageclunk: I can successfully deploy multi-nic lxd containers on xenial with maas 1.9.1 beta4 [11:43] mgz: ping [11:55] dimitern: that's awesome === babbageclunk is now known as babbagelunch [11:56] voidspace: maybe try upgrading your maas to see if it will fix the lxd issue? [11:58] now trying the same on 2.0.0 [11:58] dimitern: ah, that's 1.9 [11:58] dimitern: I'm using the latest 2.0 from experimental 3 ppa. [11:59] dimitern: not so awesome news then. I mean, great - but it's not using my code... [11:59] dimitern: you won't be able to deploy containers on maas 2 with master - you'll need my branch [12:00] voidspace: ah, ok can you paste a link and I'll try with your branch? [12:04] dimitern: https://github.com/voidspace/juju/tree/maas2-allocate-container-addresses [12:05] voidspace: thanks! [12:09] fwereade: have you seen the "test timed out waiting for the machiner to start" ? failure in CI? [12:09] http://reports.vapour.ws/releases/3919/job/run-unit-tests-mongodb3/attempt/538 [12:10] Bug #1382131 changed: local provider configs cannot be trivially duplicated

[12:10] fwereade: the very first thing that comes to mind is knowing *what* dependency is missing would be useful [12:17] dooferlad: ping [12:19] fwereade: Just sent an email about the pinger bug - can you take a look? [12:20] cherylj: are you changing the pinger? [12:20] cherylj: that's the only way to keep WS open so that apache doesn't close it by itself [12:21] urulama: this is for fixing bug 1572237 [12:21] Bug #1572237: juju rc1 loses agents during a lxd deploy

[12:22] urulama: it's to make sure the pinger restarts if it dies [12:22] cherylj: ok, thanks. just didn't want to get any surprises seeing GUI stop working all of a sudden :) [12:22] hehe :) [12:24] * dimitern is out for ~2h [12:28] anyone know if someone is working on https://bugs.launchpad.net/juju-core/+bug/1565872 ? [12:28] Bug #1565872: Juju needs to support LXD profiles as a constraint

[12:28] and what is the best option for developing docker charms for 2.0 at the moment? [12:33] jam, the infrastructure is there but I never got to exposing it -- call .Report() on an Engine and you'll get all sorts of useful diagnostic goodness [12:33] cherylj, ack [12:34] Bug #1574607 opened: Multiple Interfaces lead to stalled charm download over wrong API endpoint

[12:40] cherylj, it's a real race, in stuff my eyes completely skipped over because I thought I recognised it [13:04] Bug #1574632 opened: Data Race in apiserver/presence/pinger.go

[13:12] * voidspace lunches [13:16] Bug #1574637 opened: TestScale fails intermittently

[13:22] Bug #1574637 changed: TestScale fails intermittently

[13:25] Anyone have any idea of when juju 2.0 RC1 or next Beta will rear it's head in the repo's? [13:34] Bug #1574637 opened: TestScale fails intermittently

[13:42] Garyx: I think cherylj might be able to tell you that. [13:43] sinzui, fwereade, cherylj yay for CI for catching issues [13:44] fwereade, cherylj what do we htink the turn around time will be for fixing the race? [13:45] babbageclunk: thanks [13:45] cherylj: any rough eta, not asking for a time and date ;) [13:45] Garyx, we are working on the next beat atm [13:45] trying to get it out today [13:45] beta6 [13:46] alexisb: thanks for the info :) [13:46] Bug #1574649 opened: environs/config LatestLtsSeries is not isolated from the host during testing [13:47] alexisb, more than 0 hours and hopefully less than 2; surely less than 4 [13:47] fwereade, ack thanks [13:58] Bug #1574564 changed: Juju tools 1.25.5 not found in https://streams.canonical.com/juju/tools/releases/ [14:43] Bug #1574677 opened: Designation of 'local' for both users and controllers is confusing

[15:01] * dimitern is back [15:02] ericsnow: standup time [15:22] voidspace: I'm trying your branch now on 2.0 with lxd [15:22] Bug #1570917 changed: upgrade-juju: success but then deploy fails

[15:22] dimitern: cool, happy path test (single NIC) just about ready to land [15:23] dimitern: I'll get that up for review and then do more extensive tests [15:23] dimitern: once it lands there's container support on master - so good to get it in [15:23] mind you, master is blocked so it doesn't really matter I guess [15:23] voidspace: sounds good [15:23] a review would be good though [15:24] voidspace: I was having issues with my maas2 - tgt was misbehaving again and nothing could be commissioned or deployed successfully, now it seems it works again [15:27] dimitern: I think you'll hit this bug, but we'll see: https://bugs.launchpad.net/juju-core/+bug/1568895 [15:27] Bug #1568895: Cannot add MAAS-based LXD containers in 2.0beta4 on trusty [15:28] voidspace: nope, it's not that I think, as the bug is about trusty and this is xenial [15:28] dimitern: I had the exact same error with both [15:31] voidspace: if you grep for 'tgtadm: out of memory' in /var/log/maas/rackd.log and find anything, you might be hitting my issue [15:31] dimitern: will do [15:35] dimitern: frobware: babbageclunk: I have to pick my daughter up from the childminders' at 5pm - wife is stuck at the doctors [15:35] so will be late to meeting, sorry [15:36] voidspace: ok, np [15:37] voidspace: do you have a dual-nic hardware node, and the second one is usb2eth? [15:37] dimitern: me, no [15:37] voidspace: and the node details page showing something like 'eno1' and 'enxxaabbccddeef0' ? [15:37] dimitern: my testing is kvm only [15:38] voidspace: ah, ok [15:38] dimitern: if you're talking about that bug report it is from frobware [15:39] voidspace: nope, it's about dealing with long NIC names (e.g. the second NIC on all of my NUCs shows up as e.g. 'enx00e10000163d' [15:39] ah [15:39] and that's a wee bit too long to prepend 'br-' to it [15:39] hah [15:40] bridge script fails and I can't access the node :/ [15:40] dimitern: frobware: babbageclunk: AllocateContainerAddresses with happy path test http://reviews.vapour.ws/r/4700/ [15:40] review appreciated even though it can't land yet - so I can make changes [15:40] in the meantime working on more tests [15:40] voidspace: that seems to happen if you commissioned the node with xenial instead of trusty [15:40] voidspace: looking [15:43] Bug # changed: 1556183, 1556252, 1557146, 1557148, 1557679 [15:50] dimitern, stop landing stuff in master please [15:51] alexisb: it wasn't blocked today, and I was not aware of restrictions :/ [15:52] dimitern, it is blocked [15:52] alexisb: I see now it is, but this morning it wasn't - I haven't $$__JFDI__$$'ed anything since you mailed me [15:53] thanks dimitern [15:55] dimitern, voidspace: I find it odd that in 2016 the name of the iface is so constrained. [16:03] dimitern: frobware: back, joining networking meeting [16:04] frobware: I'm nearly at the point where nothing crazy about networking can surprise me... [16:07] anyone care to help debug why I can't log in after upgrding to Xenial? http://pastebin.ubuntu.com/16050493/ [16:08] natefinch_: sure [16:09] natefinch_: expand, "cant login" [16:10] well, I get to the greeter screen, enter creds, it looks like its switching to the desktop, briefly displays "ubuntu has encountered a problem" andf then bumps me back to the greeter screen [16:11] ah, I see, well first of all you seem to be using the floss driver for nvidia, is that intentional? [16:11] (please excuse my typing, i'\m on a tiny bluetooth keyboard via my tablet) [16:11] I don't care what driver I use so long as it works.... which this noe obviously does not [16:12] if I had to guess, I would say that that your X is crashing after loggin in [16:12] I had to twiddle my modprobe.d blacklists to even get x to load [16:12] perrito666 - probably [16:13] natefinc_, did you blacklist all the gpu drivers? [16:13] natefinch_: check if the greeter doesnt provide an option for a session withouth the effects [16:14] I can switch to a console easily enough, but that's it [16:21] natefinch_: I am sure ubuntu greeter has an option to change the session you are going to log in [16:21] click on the ubuntu logo next to the user/pass prompt [16:22] evidently just reinstalling the nvidia driver fixed it [16:23] lol [16:31] lol [16:31] CRITICAL: We failed, but the fail whale is dead. Sorry.... [16:34] up [16:34] um, power outage. [16:34] shutting down for a few minutes until it comes back. [17:05] dimitern: what was the dirty hack to workaround the issue with tests complaining about xenial? [17:06] dimitern: ha :) well, put a script returning "trusty", named 'distro-info' somewhere in $PATH, before /usr/bin [17:22] Bug #1574773 opened: bootstrap --to [lxd|lxc]:N fails to validate if machine N exists

[17:24] ahasenack: that's a fun bug [17:25] mgz: thx! :) [17:25] and, let me fix the title [17:25] it's not bootstrap --to [17:25] it's deploy --to [17:25] obviously [17:26] ahasenack: ah, looks like bug 1365124 [17:26] Bug #1365124: "juju deploy --to

" juju still tries to deploy the service.

[17:26] just --to N worked to validate N [17:27] it failed when I added the lxc/lxd prefix [17:27] but you say that's fixed? [17:27] yeah, look at the paste in the bug [17:27] ERROR cannot deploy "ubuntu-to-machine" to machine 1: machine 1 not found [17:27] when I used --to 1 [17:27] but --to lx[dc]:1 passed that check [17:27] well, close one bug, open another [17:28] mgz: that bug you linked to is for juju 1.18! [17:28] or rather, was reported on juju 1.18 [17:28] yup :) [17:29] ahasenack: don't supose you have a 1.X env alive at present? I only have 2.0 up currently [17:29] just want to series target [17:30] nope, I made it a point to move myself to juju 2 [17:30] ahasenack: I'll stand something up and test here [17:56] Bug #1365124 changed: "juju deploy --to

" juju still tries to deploy the service.

[17:56] Bug #1574783 opened: Juju 2 status should show model name - discrepancy between output formats [18:01] can anyone point me to the code that retrieves group names from launchpad when i do `charm whoami`? [18:03] marcoceppi: ^ === natefinch__ is now known as natefinch [18:04] natefinch: pretty sure it's go code, i just can't find it [18:08] Bug #1574783 changed: Juju 2 status should show model name - discrepancy between output formats [18:20] Bug #1574783 opened: Juju 2 status should show model name - discrepancy between output formats [18:26] Bug #1574783 changed: Juju 2 status should show model name - discrepancy between output formats [18:26] Bug #1574798 opened: Surprising charm downgrade

[18:56] Bug #1574809 opened: "to: lxc:0" ignored in bundle

[20:12] and we're back === redir_ is now known as redir [20:14] Does GOOSE support the OpenStack Identity API V3? [20:16] and can you configure/use it from juju? [20:17] Bug #1574844 opened: juju2 gives ipv6 address for one lxd, rabbit doesn't appreciate it.

[20:19] mramm: it does. you just have to request a /v3/ endpoint in your accounts.yaml (i think that's the right file... might be clouds.yaml) [20:19] Thanks! [20:32] perrito666: ericsnow: meeting time [20:36] katco: tx [21:55] wallyworld, I have 5 minutes before my next call [21:55] me too, be right there [23:01] katco: yst? [23:06] thumper, I lost you [23:13] redir: kinda [23:13] k. about to tanzanitestand but was looking for some juju1 assist. I'll hit you up tomorrow. [23:13] katco: ^ [23:14] redir: ok tc, cya tomorrow [23:30] Bug # changed: 1537937, 1557747, 1564397, 1566130, 1568374, 1571832, 1571916, 1572237, 1572781, 1573148, 1573149, 1573259, 1573382, 1573659, 1574632 [23:30] Bug #1573410 opened: trusty juju 1.25.5 having issues deploying xenial lxc containers