[01:09] <bigjools> mwhudson: did you manage to check my fix for https://bugs.launchpad.net/maas/+bug/1307779
[01:09] <bigjools> ?
[01:09] <mwhudson> bigjools: no
[01:10] <mwhudson> i've more or less given up on armv7 :/
[01:10] <bigjools> mwhudson: well hopefully if it doesn't work now I can blame the simplestreams data :)
[01:10] <bigjools> ah
[01:10] <mwhudson> bigjools: do you want me to try?  i can probably dig up the relevant details
[01:10] <bigjools> well if it's important to you, sure
[01:10] <bigjools> but not a big deal, I already checked the use case I was fixing
[01:11] <mwhudson> ok
[01:11] <mwhudson> i'll leave it for now then :)
[01:16] <bigjools> no worries
[08:11] <rvba> allenap: arg, your new lease parser didn't make it into 1.5.1 :/
[08:12] <rvba> allenap: I think it would have made the DHCP bug less severe.
[08:23] <allenap> rvba: How very annoying :-/
[08:26] <rvba> allenap: If we get good feedback from the field about that fix, I think it's worth pushing for a 1.5.2 release.  The proper fix for the DHCP problem is going to take time and if the new parser alleviates the problem (and I think it does), it's worth releasing it.
[08:53] <allenap> rvba: Is that something we talk to lutostag about?
[08:54] <rvba> allenap: yeah, probably.
[08:54] <rvba> Anyone up for a tiny review? https://code.launchpad.net/~rvb/maas/packaging.trusty-upstream-rev/+merge/220765
[08:59] <jtv> I'll take it.
[08:59] <jtv> Being nasty to someone might cheer me up.
[09:04] <gmb> Aah, to https://bugs.launchpad.net/maas/+bug/1322336 is basically because we do the keyring writing in the wrong place… damn. I’ll get on that now.
[09:06] <jtv> allenap, remember that occasional lock-related startup failure?  Any opinions on my guess as to the cause, i.e. ordering of decorators?
[09:07] <allenap> jtv: I need to reread your analysis. Sorry I haven’t replied sooner.
[09:12] <jtv> allenap: I can sum it up very briefly right now if that makes it easier to digest.
[09:13] <allenap> jtv: Sure :)
[09:13] <jtv> "One decorator makes the function synchronous, another makes it grab a lock; but the ordering suggests that this means 1. grab lock, then 2. run synchronously."
[09:13] <jtv> And so maybe the reactor goes on to run other tests during 1.
[09:14] <jtv> Or wait, I mis-stated that.
[09:14] <jtv> Maybe the reactor _already was_ running another test.
[09:14] <jtv> Or maybe it just arbitrarily chooses to yield sometimes even though the lock is available.
[09:15] <jtv> And so the test continues without actually having run that 'synchronous' function.
[09:17] <allenap> jtv: I think the already-running-another-test hypothesis is the most likely of those.
[09:17] <jtv> Either way, I guess we just can't expect the _call to_ that function to run synchronously even if we do have a right to expect _the function_ to run synchronously.
[10:25] <rvba> jtv: thanks for the review.  Sorry that branch was so tiny; you didn't have much room to unleash your reviewing wrath ;).
[10:26] <jtv> Yeah.  I'm all pent-up now.
[10:32] <rvba> gmb: meanwhile, if you put your branch up for review, I'm happy to have a look at it while the test is running in the lab.
[10:32] <gmb> rvba: Thanks. I’ll have the MP up presently.
[10:32] <rvba> Cool.
[10:35] <gmb> rvba: https://code.launchpad.net/~gmb/maas/bug-1322336/+merge/220783
[10:35] <rvba> gmb: on it
[10:35] <gmb> Thanks.
[10:39] <gmb> jtv: Did you get a response from Alexis re: LXC?
[10:40] <jtv> gmb: she forwarded, and there was one reply saying "that's easy innit," and I said I'd like to know from a real-life example of a problematic setup.  Nothing more.
[10:42] <gmb> Ha.
[10:42] <rvba> jtv: what's stopping us from deploying stuff on canonistack (with LXC) and testing the firewall ourselves?
[10:43] <jtv> rvba: only the risk of not reproducing the real problem setup, as far as I know.
[10:57] <gmb> rvba: Thanks for the review.
[10:57] <rvba> np
[10:57]  * gmb -> out for an early lunch.
[13:01] <gmb> jtv, allenap, rvba: A review for someone, if you have a sec… all code-removal: https://code.launchpad.net/~gmb/maas/bug-1322606/+merge/220800
[13:01] <jtv> I'll take it.
[13:02] <jtv> Ah, lovely conflicts coming.
[13:02] <jtv> But I'll manage.
[13:03] <jtv> Done.
[14:01] <rvba> gmb: did you figure out what the problem was?  With the import task I mean.
[19:49] <designated> does MAAS support aggregating NICs for using LACP, and VLAN tagging yet?
[19:49] <designated> i remember reading it in the blueprint last year sometime
[23:44] <AskUbuntu> How we can define more than 2 DNS server (IP) in MAAS? | http://askubuntu.com/q/471302