| beisner | o/ hi core friends | 02:03 |
|---|---|---|
| beisner | any idea if https://bugs.launchpad.net/juju-core/+bug/1500613 can be targeted to something (way) earlier than 1.26a1? | 02:04 |
| mup | Bug #1500613: configstore should break fslock if time > few seconds <amulet> <openstack-provider> <tech-debt> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1500613> | 02:04 |
| mup | Bug #1261780 opened: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient() <security> <tech-debt> <juju-core:In Progress> <https://launchpad.net/bugs/1261780> | 06:59 |
| mup | Bug #1261780 changed: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient() <security> <tech-debt> <juju-core:In Progress> <https://launchpad.net/bugs/1261780> | 07:02 |
| mup | Bug #1261780 opened: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient() <security> <tech-debt> <juju-core:In Progress> <https://launchpad.net/bugs/1261780> | 07:05 |
| mup | Bug #1261780 changed: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient() <security> <tech-debt> <juju-core:In Progress> <https://launchpad.net/bugs/1261780> | 07:17 |
| mup | Bug #1261780 opened: api.Client().AddLocalCharm() uses utils.GetNonValidatingHTTPClient() <security> <tech-debt> <juju-core:In Progress> <https://launchpad.net/bugs/1261780> | 07:20 |
| voidspace | TheMue: dooferlad: morning | 08:01 |
| voidspace | TheMue: dooferlad: not really any worse than last night, so I'm "in" today | 08:01 |
| voidspace | see you at standup | 08:01 |
| voidspace | cherylj: I think you looked at the "Restore failed: error fetching address" critical issue | 08:07 |
| voidspace | cherylj: just to let you know that I've got it (and it's almost certainly my fault anyway) | 08:07 |
| voidspace | dooferlad: TheMue: if you have a chance, it's a nice short diff but should fix the problem | 09:23 |
| voidspace | dooferlad: TheMue: http://reviews.vapour.ws/r/2835/ | 09:23 |
| voidspace | 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:24 |
| TheMue | voidspace: looks good | 09:26 |
| dooferlad | voidspace: what is the parameter from network.SelectInternalAddr that you are ignoring? | 09:26 |
| voidspace | dooferlad: it's an error - which will be a "no address" error if the slice of addresses is empty | 09:27 |
| voidspace | 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 |
| dooferlad | voidspace: sounds good | 09:27 |
| voidspace | 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 |
| voidspace | TheMue: thanks | 09:27 |
| dooferlad | voidspace: maybe just add a comment about that logic? Then it is good to go. | 09:28 |
| voidspace | dooferlad: ok | 09:28 |
| TheMue | dooferlad: good idea | 09:29 |
| voidspace | dooferlad: done | 09:30 |
| rogpeppe | i hadn't realised just how broken reviewboard was until now | 10:11 |
| voidspace | rogpeppe: just how broken is it? | 10:13 |
| voidspace | screwed up diffs? | 10:13 |
| rogpeppe | voidspace: unimaginably | 10:13 |
| rogpeppe | voidspace: can't click on comments. can't close tabs. | 10:14 |
| voidspace | wow | 10:14 |
| voidspace | rogpeppe: to be fair, that sounds like firefox (or whatever) is broken | 10:14 |
| rogpeppe | voidspace: it takes some serious screwups not to be able to close a tab in Chrome | 10:14 |
| rogpeppe | voidspace: i don't think i've ever encountered that before | 10:14 |
| voidspace | runaway javascript I guess | 10:14 |
| rogpeppe | voidspace: the machine's not spinning... | 10:14 |
| voidspace | rogpeppe: I thought tabs in chrome were supposed to be isolated so that couldn't happen | 10:15 |
| rogpeppe | voidspace: indeed | 10:15 |
| voidspace | it still sounds like a browser bug | 10:15 |
| voidspace | I've never had that with reviewboard | 10:15 |
| rogpeppe | 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:15 |
| rogpeppe | voidspace: i've worked out how i did it, i think | 10:16 |
| rogpeppe | 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 |
| rogpeppe | voidspace: instant screwup | 10:16 |
| TheMue | rogpeppe: a new page? hmm, never had this | 10:17 |
| voidspace | rogpeppe: nice | 10:17 |
| voidspace | TheMue: rogpeppe: submitting an inline comment takes you away from the review page | 10:18 |
| rogpeppe | 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 |
| voidspace | which is annoying | 10:18 |
| * TheMue checks | 10:18 | |
| rogpeppe | voidspace: also, it appears that you're not able to reply to issues that have been fixed or dropped | 10:18 |
| voidspace | not ideal | 10:19 |
| TheMue | rogpeppe: somehow I only find the link "Add comment" | 10:20 |
| rogpeppe | TheMue: that's in the comment overview page | 10:21 |
| rogpeppe | TheMue: i'm almost always in the "View Diff" page | 10:21 |
| TheMue | rogpeppe: yes, I'm mostly in the "View Diff" too | 10:22 |
| TheMue | everyday something new ... | 10:22 |
| === IceyEC is now known as Icey | ||
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| voidspace | ericsnow: hey | 13:04 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| ericsnow | voidspace: hey | 14:03 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| voidspace | ericsnow: a package arrived for me today | 14:49 |
| voidspace | ericsnow: thank you | 14:49 |
| ericsnow | voidspace: you are quite welcome! :) | 14:54 |
| voidspace | ericsnow: looks like there's a lot of good stuff in there, I've only dipped in so far | 14:56 |
| perrito666 | Voidspace you where blaming me for something but you disconnected too soon | 14:56 |
| voidspace | perrito666: restore was broken | 14:59 |
| voidspace | perrito666: my fault this time (originally I pinged you because I wanted some help - but then I worked it out) | 15:00 |
| voidspace | I mainly blame fwereade though, my original approach didn't have that bug :-p | 15:00 |
| voidspace | perrito666: http://pad.lv/1499571 | 15:00 |
| perrito666 | Lol if what you did broke restore, then it was probably good | 15:01 |
| voidspace | perrito666: the actual fix was only a few lines though | 15:01 |
| voidspace | perrito666: it nicely proves our CI system works - it was a genuine bug only caught by the CI tests | 15:01 |
| === akhavr1 is now known as akhavr | ||
| ericsnow | voidspace, perrito666: FYI, a LXD-based provider will allow you to test restore locally | 15:01 |
| perrito666 | Indeed | 15:02 |
| ericsnow | hopefully it is coming sooner rather than later :) | 15:02 |
| perrito666 | Ericsnow anyway it is rather annoying to run that particular test but we could have a bootstrap test which would be nice | 15:03 |
| perrito666 | Lunch bbl | 15:03 |
| voidspace | o/ | 15:03 |
| === akhavr1 is now known as akhavr | ||
| abentley | ericsnow: I had no idea an lxd provider was coming until I watched Stephane Graber's Container Camp presentation. | 15:12 |
| === akhavr1 is now known as akhavr | ||
| ericsnow | abentley: yeah, the LXD folks have done a great job, reducing the complexity of building a Juju provider around LXD | 15:14 |
| abentley | ericsnow: I'm excited that we're getting LXD support. Especially if that means machine 0 will not be my actual host. | 15:16 |
| ericsnow | abentley: yeah, that's what has me most excited as well :) | 15:16 |
| voidspace | yep +1 | 15:16 |
| ericsnow | abentley: we'll see how it pans out, but there are a number of other possibilities that a LXD provider would open up | 15:17 |
| voidspace | abentley: master is not blocked on bug 1499571 | 15:18 |
| ericsnow | abentley: e.g. running across multiple hosts; snapshots | 15:18 |
| mup | Bug #1499571: Restore failed: error fetching address <backup-restore> <blocker> <ci> <regression> <reliability> <retry> <juju-core:In Progress by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Committed by mfoord> <https://launchpad.net/bugs/1499571> | 15:18 |
| perrito666 | Not having to sysadmin my machine back into working a couple of times a week is already a big plus | 15:18 |
| === akhavr1 is now known as akhavr | ||
| voidspace | abentley: which surprises me as it blocked 1.24 and 1.25 | 15:18 |
| voidspace | abentley: I've committed a fix to both those branches but master is blocked on something else | 15:19 |
| voidspace | abentley: ok for me to JFDI my fix onto master, or is it better if I wait? | 15:19 |
| abentley | voidspace: sinzui demoted it to Medium. | 15:19 |
| voidspace | right | 15:19 |
| voidspace | I don't know why | 15:19 |
| ericsnow | also, having multiple distinct Juju dev environments on different series (or even distros) all at the same time | 15:19 |
| abentley | 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 |
| voidspace | abentley: ok, no problem | 15:21 |
| === akhavr1 is now known as akhavr | ||
| dimitern | voidspace, o/ | 15:28 |
| voidspace | dimitern: hey, hi | 15:29 |
| voidspace | dimitern: how's it going? | 15:29 |
| dimitern | voidspace, so far so good :) we're demoing today - well, frobware will be driving it actually | 15:30 |
| voidspace | dimitern: cool, good luck | 15:31 |
| dimitern | voidspace, how about that 1.9 bug? | 15:31 |
| dimitern | voidspace, thanks! | 15:31 |
| voidspace | dimitern: only just getting to it really | 15:31 |
| voidspace | dimitern: got hit fixing a critical blocker on 1.24 - master | 15:32 |
| voidspace | dimitern: plus my maas is borked and no-one seems available to help fix it | 15:32 |
| voidspace | dimitern: but I have maas 1.9 in a kvm I can use | 15:32 |
| voidspace | dimitern: just looking at the cloudinit code now | 15:32 |
| dimitern | voidspace, right, ok then - please, post updates on the bug as you go to show we're handling it | 15:33 |
| voidspace | dimitern: so the bit I actually need to fix is the *bash script* in bridgeConfigTemplate | 15:33 |
| voidspace | oh joy :-) | 15:33 |
| dimitern | voidspace, yes, that was the crux of the issue IIRC | 15:34 |
| voidspace | cool | 15:34 |
| voidspace | looks like some fun playing with sed and grep | 15:34 |
| voidspace | and some test scripts | 15:34 |
| dimitern | voidspace, just don't drop the "auto eth0" if we haven't rendered the bridge config | 15:35 |
| dimitern | in /e/n/i | 15:35 |
| dimitern | 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 |
| voidspace | right | 15:36 |
| voidspace | dimitern: what do you mean by "if we haven't rendered the bridge config" | 15:37 |
| voidspace | dimitern: bridgeConfigTemplate checks to see if the bridge already exists and exits | 15:37 |
| dimitern | voidspace, so in the script there's a pipeline like grep 'iface ethX inet dhcp' && sed ... & cat << EOF | 15:37 |
| voidspace | yep | 15:38 |
| dimitern | voidspace, if that first grep fails, the cat is not done, and /e/n/i not modified with the bridge config | 15:38 |
| voidspace | ah, but then we still remove the auto | 15:38 |
| dimitern | voidspace, yeah | 15:38 |
| voidspace | so that should be guarded too | 15:38 |
| dimitern | voidspace, yes, but just that won't cut it | 15:39 |
| voidspace | we still need to create the bridge | 15:39 |
| voidspace | do we leave the primary interface definition in place and copy it into the bridge definition? | 15:39 |
| dimitern | 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 |
| voidspace | so leave the auto in place *plus* copy the details | 15:40 |
| voidspace | that should be fine, need to get this kvm booting instances - it's been a while since I set it up | 15:40 |
| dimitern | voidspace, let me paste you an example, just a sec | 15:41 |
| dimitern | voidspace, http://paste.ubuntu.com/12697581/ | 15:43 |
| voidspace | dimitern: cool, thanks - that's clear | 15:44 |
| dimitern | voidspace, cheers :) | 15:44 |
| voidspace | the fun part is using bash to detect the *whole* of the section to copy | 15:44 |
| voidspace | not entirely sure how to express "copy everything up to the dedent" in bash :-) | 15:44 |
| voidspace | I'll work it out though | 15:44 |
| dimitern | voidspace, yeah, that's a bit fiddly with bash I guess | 15:44 |
| voidspace | worst case I use Python :-p | 15:45 |
| voidspace | but I'll try not to | 15:45 |
| dimitern | voidspace, I don't mind - if you do, add it to the packages to install ;) | 15:45 |
| voidspace | ok | 15:45 |
| dimitern | 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:46 |
| voidspace | dimitern: kk | 15:47 |
| frobware | voidspace, you could refactor what's there a bit and turn some of into functions | 15:47 |
| voidspace | frobware: that sounds eminently sensible | 15:49 |
| frobware | voidspace, it would help to determine what to call based on what you discover | 15:49 |
| voidspace | yep | 15:50 |
| voidspace | and some good names could make it a bit clearer what's being done | 15:50 |
| mgz | abentley: https://github.com/ericsnowcurrently/juju/tree/lxd-provider-full-provider | 15:52 |
| voidspace | frobware: good luck with the demo | 16:02 |
| frobware | voidspace, thx | 16:02 |
| voidspace | frobware: did you do the devices demo already? | 16:04 |
| frobware | voidspace, nope | 16:04 |
| voidspace | ah | 16:04 |
| voidspace | cool | 16:04 |
| frobware | voidspace, does work for me though | 16:04 |
| voidspace | great | 16:04 |
| voidspace | that's a good sign... | 16:04 |
| voidspace | it might actually work then ;-) | 16:04 |
| === 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 | ||
| rogpeppe | ales, anyone else: this PR adds macaroon authentication to the streaming API endpoints: http://reviews.vapour.ws/r/2838/ | 16:42 |
| rogpeppe | review much appreciated | 16:42 |
| === akhavr1 is now known as akhavr | ||
| mgz | voidspace: any news on bug 1499571? it is due to the address stability change? | 16:54 |
| mup | Bug #1499571: Restore failed: error fetching address <backup-restore> <blocker> <ci> <intermittent-failure> <regression> <reliability> <retry> <juju-core:In Progress by mfoord> <juju-core 1.24:In Progress by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1499571> | 16:54 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| voidspace | 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 |
| voidspace | mgz: so not landed there yet | 17:20 |
| mgz | voidspace: aha, I misunderstood then | 17:23 |
| voidspace | mgz: misunderstood what? | 17:23 |
| mgz | the state of the bug | 17:23 |
| voidspace | ah :-) | 17:24 |
| voidspace | I misunderstood your misunderstanding | 17:24 |
| === akhavr1 is now known as akhavr | ||
| voidspace | mgz: just seen your comment | 17:25 |
| voidspace | mgz: is your comment out of date then? | 17:25 |
| voidspace | 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:25 |
| voidspace | mgz: with the fix already landed they should be available immediately | 17:26 |
| voidspace | mgz: have they failed since my fix landed? | 17:26 |
| mgz | voidspace: I had not realised you had landed something, | 17:27 |
| voidspace | ah | 17:27 |
| voidspace | :-) | 17:27 |
| mgz | you had the bug in progress and CI auto-marked fix released because 1.24 was blessed | 17:28 |
| voidspace | kk | 17:28 |
| voidspace | mgz: it marked fix released because prior to the bless I marked the 1.24 milestone as fix committed | 17:28 |
| voidspace | same with 1.25 | 17:28 |
| voidspace | but master is still in progress because I can't land there yet | 17:28 |
| voidspace | mgz: so you put them back to "in progress"? | 17:29 |
| mgz | right, I didn't see you'd landed anything. | 17:29 |
| voidspace | :-) | 17:29 |
| voidspace | fair enough | 17:29 |
| mgz | so, can put back to fix released, and make it so you can land change on master too. | 17:29 |
| voidspace | mgz: mark it as critical? | 17:29 |
| voidspace | that should allow me to land it | 17:30 |
| voidspace | I'm not sure why it was set as medium | 17:30 |
| voidspace | it's still a regression on master | 17:30 |
| mgz | voidspace: done and done | 17:33 |
| voidspace | mgz: thanks | 17:33 |
| === akhavr1 is now known as akhavr | ||
| mgz | voidspace: thanks for the fix, sorry for the confusion :) | 17:46 |
| voidspace | mgz: np :-) | 17:47 |
| voidspace | EOD | 17:48 |
| voidspace | g'night all | 17:48 |
| mgz | sleep well :P | 17:48 |
| === 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 | ||
| mup | Bug #1496972 changed: juju bootstrap fails to successfully configure the bridge juju-br0 when deploying with wily 4.2 kernel <hs-arm64> <kernel-da-key> <network> <Linux:Triaged by jsalisbury> <https://launchpad.net/bugs/1496972> | 20:04 |
| === 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 | ||
| ericsnow | cmars: FYI, I have a patch up that merges master into the lxd-provider branch: http://reviews.vapour.ws/r/2834/ | 21:37 |
| ericsnow | cmars: mind if I fold in those deps from your patch? | 21:38 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| perrito666 | oh god why status is so cruel | 21:57 |
| mup | Bug #1503449 opened: easy bug reporting for juju - e.g. sosreport <juju-core:New> <https://launchpad.net/bugs/1503449> | 22:10 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
| katco | ericsnow: awesome. wwitzel3 ^^^ what ericsnow said | 23:39 |
| === akhavr1 is now known as akhavr | ||
| === akhavr1 is now known as akhavr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!