[01:27] perrito666: review'd! (for what it's worth!) [06:28] jam yt? [06:28] redir: hello [06:28] got a minute? [06:30] I've got an issue troubleshooting kvm in kvm on vmaas replacing uvtool for managing kvm in juju [06:31] perrito666 thought you might have some ideas [06:31] jam ^ [06:31] redir: give me a couple mins to get this test compiling and I'll be there [06:31] hangout? [06:31] np [06:32] holler [06:46] yes [06:46] hangout [06:47] jam were you asking for a hangout? [06:47] yes you were [06:47] jam https://hangouts.google.com/hangouts/_/canonical.com/jam [06:47] redir: well, I can chat with you however you would like [06:47] but a hangout seems easiest [06:48] brt [06:48] np [08:28] babbageclunk: pong [11:51] who os Trent Lloyd [11:51] *is ? [11:52] Ah, a Canonical guy [11:52] Just reading what is perhaps the best written bug report I've ever seen :-) [11:52] a bug report that fully understands and explains the problem as far as I can tell [11:52] a thing of beauty :-) [11:55] lol, link [11:58] perrito666: https://bugs.launchpad.net/juju/+bug/1631254 [11:58] Bug #1631254: [2.0rc3] lxd containers do not autostart [12:05] voidspace: beautiful report indeed [12:14] jam: did you settle on skipping the test for now? [12:15] voidspace: so I have a test which has an ExpectedFailure and then skips [12:15] jam: cool [12:15] well, it has an Assert then a skip [12:15] I don't know if gocheck supports Expected Failure [12:15] jam: ah, skip on fail [12:15] jam: same effect... [12:16] * jam still likes UnitTest a lot more [12:16] jam: the Java one? [12:16] voidspace: the python one [12:16] jam: the Python one still needs an enormous overhaul [12:17] voidspace: well, lots of stuff layered on it that Bazaar used. [12:17] jam: it could be entirely rearchitected - I began that [12:17] jam: right [12:17] lifeless was really big on unit testing, so we had quite a bit of helpers [12:17] subunit integration, ability to run just this subset of tests, etc. [12:17] jam: yep, he's prodidigious and highly intelligent [12:17] jam: he had a preference for complex apis andd over-engineering IMO [12:18] jam: his code was always obviously capable, but never quite to my tastes ;-) [12:18] jam: what I started for unittest became nose2 - which some people still use but I fear has become abandonware [12:18] jam: a lot of the APIs in that came out of discussion with lifeless though [12:19] jam: I was working on a fully event based way of integrating with (customising and extending) unittest instead of via subclassing [12:19] voidspace: python definitely plays a lot of games around how magic vs how explici [12:19] jam: it was interesting, I would have loved to have completed it - but then life happened [12:19] jam: yep, constant tension [12:20] jam: I love the guiding principle of "simple things should be simple, complex things should be possible" [12:20] jam: so I like to design the API and UX around *the most commmon obvious beginning* way to use it [12:20] jam: and then ensure that extending beyond that is possible and as intuitive (i.e. not a jarring jump) from there [12:21] similar I guess to the principle of least surprise [12:21] from Ruby [12:21] but they definitely jump into the magic-auto-configuration everywhere [12:22] the major change I wanted to make to what I did in unittest, on the good advice of Holger Krekel, was to have a test context where *all* the state for the current test run lived (including configuration) and then pass that context through everywhere - no global state [12:22] so I got as far as breaking everything to begin making that change [12:22] and that's where I left it... [12:23] like much in life, incomplete and broken ;-) [13:54] I always tell folks "start writing the code you want to be writing to get this done, then we'll go write the stuff that makes that possible" :) (re: most common beginning" [14:05] rick_h: do you know when sinzui is going to be around? [14:06] jam: no, I don't. He's normally getting online from now through the next hour in a normal work day [14:06] rick_h: I realized a bit late (today) that really all our stuff should probably be targeting the 2.1 branch, so I've updated the stuff I've landed so far, and the stuff I've proposed. [14:06] rick_h: so I think all my stuff is up for review, and frobware is doing the integration with his patches as we speak [14:06] (testing the integration on his MAAS setup.) [14:06] jam: k, would it be better to ask sinzui to test tomorrow? [14:07] rick_h: I'm pretty confident about my "restricted NIC" work, as we already landed that in develop. I'm fairly confident about the followup [14:07] rick_h: but the dynamic bridging hasn't been tested in anger mixed with my stuff. [14:07] (its what frobware is doing onw) [14:07] jam: ok, so can we email him, cc myself/torsten a binary to test with and any notes? [14:07] jam: once the bits land together [14:08] rick_h: the big thing is it feels like I should really be around as curtis is working on it/testing it, and I don't know how to make that happen. [14:08] jam: rgr, well let's try async and see if we can make it work. [14:08] jam: honestly I think it's good QA to have him play, find things, note them and do it without us over his shoulder [14:09] jam: at least in the efforts we've been trying to do to date. We declare what we think things should do and let them verify and find ways to break it. [14:21] rick_h: I'm happy to be around later in my day; there's no point (should it happen) getting stuck/broken in the first 5 minutes. [14:45] frobware: can you kick things off with an email to sinzui then when the bits are ready please? [14:46] rick_h: bits? so a branch or a juju tarball? any indication what they are expecting? [14:46] frobware: no, I think they'd start with develop, but if we have a preference we should email and indicate our preference. [14:46] frobware: be a tarball, branch, etc [14:47] frobware: rick_h: I'm putting together an email, just still writing it. [14:47] rick_h: so the integration branch I'm using is not in develop (yet) - need more work [14:47] frobware: right, but its based off develop, not 2.1 [14:47] jam, rick_h: correct [14:48] frobware: rick_h: I have patches for all of my stuff up for review, and a second set of patches against 2.1 up for review. [14:48] frobware: I told Curtis about your integration branch as the place-to-work-from for now [14:48] I probably left off that it isn't 2.1 [14:48] all the files that I've worked in are identical between 2.1 and develop, so just doing "diff + patch" works very well. [14:50] rick_h: email sent (you are CCd) [14:50] catch y'all later. You can Hangout me directly if you need something urgently. [14:50] jam: that's good news. I guess not much generally happng helps here. [14:50] jam: ty === benji is now known as Guest18237 [17:01] morning [17:10] redir: your morning starts a lot like my afternoon [17:18] :) === benji is now known as Guest32149 === carlosm__ is now known as udac === benji_ is now known as benji [18:59] bbl relocation [20:16] anyone know what else uses the $paths.DataDir/containers/juju-id-n/cloud-init data? [21:06] rogpeppe: sorry, only saw this now - was going to ask you about a bug involving macaroons and websocket connections (for log streams) [21:06] rogpeppe: I think I've sorted it out but if you're around and not busy/off to bed soon it might be worth confirming with you? [21:09] jam: did you see my response to your comment on https://github.com/juju/juju/pull/6735 [22:37] ssh [22:40] perrito666, redir: anyone know how I can construct fully-discharged macaroons for a test I'm struggling to write? [22:41] babbageclunk: no clue at all [22:44] babbageclunk: I'd start here https://github.com/go-macaroon/macaroon/blob/v1/macaroon_test.go [22:44] perrito666: [22:45] :( [22:45] redir: ooh! I'll look at that thanks [22:45] seems redir is more helpful than I [22:50] yay things don't work on trusty [22:57] perrito666: you've been helpful before - in my tally he's only a *tiny* bit ahead [22:57] :p [23:00] k redir babbageclunk I think Ill call it a day :) [23:00] if you need me email me and ill be back [23:00] [23:00] perrito666: night! [23:01] no standup :o perrito666 knows what I've been doing today [23:02] have a good night [23:08] redir: ok - my plaintive cry above is basically my status - found the solution to the macaroon problem I had, struggling to test it. [23:10] I can finally show some working kvm bits and no one is around to see. sigh [23:10] good luck with the macaroon tests [23:11] they sort of work the opposite of how I want them to