[02:03] o/ hi core friends [02:04] any idea if https://bugs.launchpad.net/juju-core/+bug/1500613 can be targeted to something (way) earlier than 1.26a1? [02:04] Bug #1500613: configstore should break fslock if time > few seconds

[06:59] Bug #1261780 opened: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient()

[07:02] Bug #1261780 changed: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient()

[07:05] Bug #1261780 opened: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient()

[07:17] Bug #1261780 changed: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient()

[07:20] Bug #1261780 opened: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient()

[08:01] TheMue: dooferlad: morning [08:01] TheMue: dooferlad: not really any worse than last night, so I'm "in" today [08:01] see you at standup [08:07] cherylj: I think you looked at the "Restore failed: error fetching address" critical issue [08:07] cherylj: just to let you know that I've got it (and it's almost certainly my fault anyway) [09:23] dooferlad: TheMue: if you have a chance, it's a nice short diff but should fix the problem [09:23] dooferlad: TheMue: http://reviews.vapour.ws/r/2835/ [09:24] The added tests fail without the change in addmachine, so pretty sure it's the right fix. (Restore creates a new machine as the bootstrap machine and then immediately asks for its address - which currently isn't set.) [09:26] voidspace: looks good [09:26] voidspace: what is the parameter from network.SelectInternalAddr that you are ignoring? [09:27] dooferlad: it's an error - which will be a "no address" error if the slice of addresses is empty [09:27] dooferlad: in that case the returned address will be empty - and setting the preferred address to an empty address is then the right thing to do [09:27] voidspace: sounds good [09:27] dooferlad: so we can safely ignore the error - even if an error is returned we still use the empty address that is also returned [09:27] TheMue: thanks [09:28] voidspace: maybe just add a comment about that logic? Then it is good to go. [09:28] dooferlad: ok [09:29] dooferlad: good idea [09:30] dooferlad: done [10:11] i hadn't realised just how broken reviewboard was until now [10:13] rogpeppe: just how broken is it? [10:13] screwed up diffs? [10:13] voidspace: unimaginably [10:14] voidspace: can't click on comments. can't close tabs. [10:14] wow [10:14] rogpeppe: to be fair, that sounds like firefox (or whatever) is broken [10:14] voidspace: it takes some serious screwups not to be able to close a tab in Chrome [10:14] voidspace: i don't think i've ever encountered that before [10:14] runaway javascript I guess [10:14] voidspace: the machine's not spinning... [10:15] rogpeppe: I thought tabs in chrome were supposed to be isolated so that couldn't happen [10:15] voidspace: indeed [10:15] it still sounds like a browser bug [10:15] I've never had that with reviewboard [10:15] voidspace: and it's just screwed up by design. the fact that if you want to reply to a review comment, it takes you to a new page. [10:16] voidspace: i've worked out how i did it, i think [10:16] voidspace: i didn't like the above behaviour (i wanted to keep my inline comment context and still reply to a review comment) so i right-clicked "open in new tab" on the Reply button. [10:16] voidspace: instant screwup [10:17] rogpeppe: a new page? hmm, never had this [10:17] rogpeppe: nice [10:18] TheMue: rogpeppe: submitting an inline comment takes you away from the review page [10:18] TheMue: so if you want to reply to a review comment (not adding a new comment which is what i was doing initially without knowing it), you click on "reply" and it doesn't take you away from the full diff context? [10:18] which is annoying [10:18] * TheMue checks [10:18] voidspace: also, it appears that you're not able to reply to issues that have been fixed or dropped [10:19] not ideal [10:20] rogpeppe: somehow I only find the link "Add comment" [10:21] TheMue: that's in the comment overview page [10:21] TheMue: i'm almost always in the "View Diff" page [10:22] rogpeppe: yes, I'm mostly in the "View Diff" too [10:22] everyday something new ... === IceyEC is now known as Icey === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [13:04] ericsnow: hey === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [14:03] voidspace: hey === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [14:49] ericsnow: a package arrived for me today [14:49] ericsnow: thank you [14:54] voidspace: you are quite welcome! :) [14:56] ericsnow: looks like there's a lot of good stuff in there, I've only dipped in so far [14:56] Voidspace you where blaming me for something but you disconnected too soon [14:59] perrito666: restore was broken [15:00] perrito666: my fault this time (originally I pinged you because I wanted some help - but then I worked it out) [15:00] I mainly blame fwereade though, my original approach didn't have that bug :-p [15:00] perrito666: http://pad.lv/1499571 [15:01] Lol if what you did broke restore, then it was probably good [15:01] perrito666: the actual fix was only a few lines though [15:01] perrito666: it nicely proves our CI system works - it was a genuine bug only caught by the CI tests === akhavr1 is now known as akhavr [15:01] voidspace, perrito666: FYI, a LXD-based provider will allow you to test restore locally [15:02] Indeed [15:02] hopefully it is coming sooner rather than later :) [15:03] Ericsnow anyway it is rather annoying to run that particular test but we could have a bootstrap test which would be nice [15:03] Lunch bbl [15:03] o/ === akhavr1 is now known as akhavr [15:12] ericsnow: I had no idea an lxd provider was coming until I watched Stephane Graber's Container Camp presentation. === akhavr1 is now known as akhavr [15:14] abentley: yeah, the LXD folks have done a great job, reducing the complexity of building a Juju provider around LXD [15:16] ericsnow: I'm excited that we're getting LXD support. Especially if that means machine 0 will not be my actual host. [15:16] abentley: yeah, that's what has me most excited as well :) [15:16] yep +1 [15:17] abentley: we'll see how it pans out, but there are a number of other possibilities that a LXD provider would open up [15:18] abentley: master is not blocked on bug 1499571 [15:18] abentley: e.g. running across multiple hosts; snapshots [15:18] Bug #1499571: Restore failed: error fetching address

[15:18] Not having to sysadmin my machine back into working a couple of times a week is already a big plus === akhavr1 is now known as akhavr [15:18] abentley: which surprises me as it blocked 1.24 and 1.25 [15:19] abentley: I've committed a fix to both those branches but master is blocked on something else [15:19] abentley: ok for me to JFDI my fix onto master, or is it better if I wait? [15:19] voidspace: sinzui demoted it to Medium. [15:19] right [15:19] I don't know why [15:19] also, having multiple distinct Juju dev environments on different series (or even distros) all at the same time [15:21] voidspace: It's better if you wait. That way, when you land, it will be clear whether your branch was blessed or cursed. [15:21] abentley: ok, no problem === akhavr1 is now known as akhavr [15:28] voidspace, o/ [15:29] dimitern: hey, hi [15:29] dimitern: how's it going? [15:30] voidspace, so far so good :) we're demoing today - well, frobware will be driving it actually [15:31] dimitern: cool, good luck [15:31] voidspace, how about that 1.9 bug? [15:31] voidspace, thanks! [15:31] dimitern: only just getting to it really [15:32] dimitern: got hit fixing a critical blocker on 1.24 - master [15:32] dimitern: plus my maas is borked and no-one seems available to help fix it [15:32] dimitern: but I have maas 1.9 in a kvm I can use [15:32] dimitern: just looking at the cloudinit code now [15:33] voidspace, right, ok then - please, post updates on the bug as you go to show we're handling it [15:33] dimitern: so the bit I actually need to fix is the *bash script* in bridgeConfigTemplate [15:33] oh joy :-) [15:34] voidspace, yes, that was the crux of the issue IIRC [15:34] cool [15:34] looks like some fun playing with sed and grep [15:34] and some test scripts [15:35] voidspace, just don't drop the "auto eth0" if we haven't rendered the bridge config [15:35] in /e/n/i [15:36] voidspace, also if /e/n/i already has a static config for the primary nic, we should move it into the juju-br0 config, and still set ethX to manual [15:36] right [15:37] dimitern: what do you mean by "if we haven't rendered the bridge config" [15:37] dimitern: bridgeConfigTemplate checks to see if the bridge already exists and exits [15:37] voidspace, so in the script there's a pipeline like grep 'iface ethX inet dhcp' && sed ... & cat << EOF [15:38] yep [15:38] voidspace, if that first grep fails, the cat is not done, and /e/n/i not modified with the bridge config [15:38] ah, but then we still remove the auto [15:38] voidspace, yeah [15:38] so that should be guarded too [15:39] voidspace, yes, but just that won't cut it [15:39] we still need to create the bridge [15:39] do we leave the primary interface definition in place and copy it into the bridge definition? [15:40] voidspace, we need to check if /e/n/i has iface ethX inet static, and copy the rest of the section into the section for iface juju-br0 inet static (e.g. address, netmask, etc.) in addition to bridge_ports [15:40] so leave the auto in place *plus* copy the details [15:40] that should be fine, need to get this kvm booting instances - it's been a while since I set it up [15:41] voidspace, let me paste you an example, just a sec [15:43] voidspace, http://paste.ubuntu.com/12697581/ [15:44] dimitern: cool, thanks - that's clear [15:44] voidspace, cheers :) [15:44] the fun part is using bash to detect the *whole* of the section to copy [15:44] not entirely sure how to express "copy everything up to the dedent" in bash :-) [15:44] I'll work it out though [15:44] voidspace, yeah, that's a bit fiddly with bash I guess [15:45] worst case I use Python :-p [15:45] but I'll try not to [15:45] voidspace, I don't mind - if you do, add it to the packages to install ;) [15:45] ok [15:46] voidspace, however, I've just realized it might not work, as this is called too early in the boot process, likely before the packages are installed - hence, bash unfortunatelly [15:47] dimitern: kk [15:47] voidspace, you could refactor what's there a bit and turn some of into functions [15:49] frobware: that sounds eminently sensible [15:49] voidspace, it would help to determine what to call based on what you discover [15:50] yep [15:50] and some good names could make it a bit clearer what's being done [15:52] abentley: https://github.com/ericsnowcurrently/juju/tree/lxd-provider-full-provider [16:02] frobware: good luck with the demo [16:02] voidspace, thx [16:04] frobware: did you do the devices demo already? [16:04] voidspace, nope [16:04] ah [16:04] cool [16:04] voidspace, does work for me though [16:04] great [16:04] that's a good sign... [16:04] it might actually work then ;-) === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [16:42] ales, anyone else: this PR adds macaroon authentication to the streaming API endpoints: http://reviews.vapour.ws/r/2838/ [16:42] review much appreciated === akhavr1 is now known as akhavr [16:54] voidspace: any news on bug 1499571? it is due to the address stability change? [16:54] Bug #1499571: Restore failed: error fetching address

=== akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [17:20] mgz: it was, fix committed on 1.24 and 1.25 - master is blocked on something else and that bug was only marked as "medium" on master [17:20] mgz: so not landed there yet [17:23] voidspace: aha, I misunderstood then [17:23] mgz: misunderstood what? [17:23] the state of the bug [17:24] ah :-) [17:24] I misunderstood your misunderstanding === akhavr1 is now known as akhavr [17:25] mgz: just seen your comment [17:25] mgz: is your comment out of date then? [17:25] mgz: it was intermittent because as soon as SetMachineAddresses or SetProviderAddresses was called on the bootstrap machine the PublicAddress and PrivateAddress would become available [17:26] mgz: with the fix already landed they should be available immediately [17:26] mgz: have they failed since my fix landed? [17:27] voidspace: I had not realised you had landed something, [17:27] ah [17:27] :-) [17:28] you had the bug in progress and CI auto-marked fix released because 1.24 was blessed [17:28] kk [17:28] mgz: it marked fix released because prior to the bless I marked the 1.24 milestone as fix committed [17:28] same with 1.25 [17:28] but master is still in progress because I can't land there yet [17:29] mgz: so you put them back to "in progress"? [17:29] right, I didn't see you'd landed anything. [17:29] :-) [17:29] fair enough [17:29] so, can put back to fix released, and make it so you can land change on master too. [17:29] mgz: mark it as critical? [17:30] that should allow me to land it [17:30] I'm not sure why it was set as medium [17:30] it's still a regression on master [17:33] voidspace: done and done [17:33] mgz: thanks === akhavr1 is now known as akhavr [17:46] voidspace: thanks for the fix, sorry for the confusion :) [17:47] mgz: np :-) [17:48] EOD [17:48] g'night all [17:48] sleep well :P === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [20:04] Bug #1496972 changed: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel

=== akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === meetingology` is now known as meetingology === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [21:37] cmars: FYI, I have a patch up that merges master into the lxd-provider branch: http://reviews.vapour.ws/r/2834/ [21:38] cmars: mind if I fold in those deps from your patch? === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [21:57] oh god why status is so cruel [22:10] Bug #1503449 opened: easy bug reporting for juju - e.g. sosreport === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr [23:39] ericsnow: awesome. wwitzel3 ^^^ what ericsnow said === akhavr1 is now known as akhavr === akhavr1 is now known as akhavr