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