[00:21] axw: there are a couple of branches up for bug 1625624 that would be good if you have a chance to think about today (I sent an email) [00:21] Bug #1625624: juju 2 doesn't remove openstack security groups

[00:32] wallyworld, running behind [00:50] mgz: yup will do (although I have a mounting list of things to do, so I apologise in advance if I run out of time) [00:57] axw: don't worry about review sepcifics, just want input on api compat issues [01:03] alexisb: ping when you're ready please [01:03] axw, will do [01:03] sorry [01:07] babbageclunk: did u get a chance to see this one? https://bugs.launchpad.net/bugs/1646504 [01:07] Bug #1646504: Suite.TestLogTransferReportsProgress messages are different

[01:08] ok axw hoping on the HO [01:09] anastasiamac: no, hadn't seen that. D'oh! Will fix - thanks! [01:09] babbageclunk: \o/ [01:28] redir, you have a minute to meet with me? [01:28] alexisb: yup [01:28] 1:1? [01:30] yep [01:56] good night all, I will see the team in person next week! [02:49] anastasiamac, menn0, wallyworld: can someone review my intermittent test failure fix please? https://github.com/juju/juju/pull/6647 [02:49] for bug 1646504 [02:49] sure [02:49] Bug #1646504: Suite.TestLogTransferReportsProgress messages are different

[02:51] wallyworld: thanks! [02:52] babbageclunk: how do we know that the first match is always 0 sent and not 1 or 2? [02:53] wallyworld: it logs before starting doing anything [02:53] wallyworld: it means the test's a bit toothless now, but I think that's ok [02:54] babbageclunk: i guess it shows initially the first message and then subsequent [02:54] * babbageclunk nods [02:55] babbageclunk: and just to check, we pass in a test clock to the suite [02:55] wallyworld: yup, up in the setup [02:56] babbageclunk: so in that case, off hand, why isn't the test deterministic then? [02:56] we step the clock, we should see deterministic results? [02:58] wallyworld: I *think* it's because of the nondeterminism in the select statement - if the alarm's triggered and the channel has something waiting, then either one might happen [03:00] makes sense looking at the code [03:00] +1 then, ty [03:01] wallyworld: thanks. I'm not super happy with it, but I'm not sure of a better way to fix it. [03:02] agree with that sentiment, but import thing is to get it fixed [03:02] pragmatism :-) [03:02] :) [03:04] * babbageclunk steps out for some pre-travel errands. [03:58] axw: i keep hitting itermitent failures with this one, got to go to the funeral, could you hit merge for me if it fails again? https://github.com/juju/juju/pull/6637 [03:58] wallyworld: ok === frankban|afk is now known as frankban [09:52] hey folks - anyone around able to explain model migration to me? [09:52] (for now - I just want to know what it is) [09:52] mattyw: the idea is that you can migrate everything to a new *controller* [09:52] mattyw: it doesn't migrate the services or units [09:53] mattyw: but exports the "state of the world" to be imported into a new *controller* [09:53] mattyw: which can then administer the world [09:53] mattyw: make sense? [09:53] mattyw: so it only migrates the "model of the world", not the world itself [09:53] voidspace, makes perfect sense, thanks very much [09:54] cool [10:45] any specific reason why application names can't start with a digit? [10:46] jamespage: I strongly suspect that the answer is "no good reason" [10:46] jamespage: I'd file a bug and start a discussion on the mailing list [10:46] voidspace, ok ta [10:47] jamespage: if there is no good reason for the restriction it is very easy to change the rule [10:49] voidspace, I've emailed the juju-dev ML [10:50] it's been that way for ever [10:50] voidspace, I'll skip the bug for now [10:50] jamespage: cool [10:50] jamespage: ok [10:50] might save some cycles if there is a good reason! [10:50] mgz: "this is the way we have always done it" is often the reason... [10:50] and the only reason... [10:50] mgz: o/ [10:50] 'ning [10:50] monin' [10:50] +r [10:51] >_< [10:51] :-) [10:51] or +a [10:51] whichever really, maybe both [10:52] ehehe [10:52] anyway, my assumption is it made parsing/disamiguating machines/services/units [10:52] 0 is always a machine [10:52] a0 is always an application [10:53] a0/0 is always a unit [11:31] mgz: you may well be right [11:32] jamespage: it may be required internally in juju for disambiguating names [11:32] jamespage: which is not necessarily a good reason, but may actually make it very hard to change [11:33] voidspace, ack [12:00] juju seem to be trying to use the ip-address of a unit by grabbing the first interface when ordered alphabetically, this makes it problematic to run for example `juju ssh [unit]` when you have installed docker which adds the docker0 interface [12:01] ive only experienced this about a week though, so it might be something added recently [12:02] `juju ssh [machine number]` works fine though [12:27] SimonKLB: *sigh* [12:27] SimonKLB: file a bug please [12:27] voidspace: did i do something stupid? :) [12:27] alright [12:28] SimonKLB: no, I don't think so [12:28] SimonKLB: it sounds like juju is doing the wrong thing [12:28] SimonKLB: but it's actually *hard* for juju to know what the right thing to do is when there are multiple interfaces [12:28] SimonKLB: it seems obvious as a human when you know what the purpose of all the interfaces are [12:28] SimonKLB: but juju has to infer all that [12:29] ah, we don't have a friday early standup [12:29] had forgotten [12:29] yea, i was debugging it a bit, and it looks like its actually trying different ips, so my initial thought that it was grabbing the first interface by alphabetical order might be wrong [12:29] mgz: I just came to the same realisation [12:30] SimonKLB: frobware is our expert here [12:30] SimonKLB: as much as he doesn't want to be the expert here... [12:30] :D [12:30] is he us? [12:30] SimonKLB: no, UK [12:30] ah great [12:30] SimonKLB: not sure if he's around today or not [12:31] voidspace, SimonKLB: here.... [12:31] :-) [12:31] (and gone) [12:31] * voidspace coffee [12:31] :) [12:31] frobware: nice! any idea whats going on here? [12:31] SimonKLB: context? [12:31] frobware: `juju ssh [unit]` does not grab the correct ip/interface from the looks of it [12:32] while juju ssh [machine] does [12:32] hmm [12:32] actually that's weird and interesting [12:32] SimonKLB: I'm guessing [unit] literally grabs first addr. Whereas we made some recent change for $N to try all interfaces:22 and choose the first that works [12:32] I don't know what juju does when you ask for the ip of a unit [12:33] I know what it does when you ask for the ip of a machine [12:33] since the unit is kind of linked to a machine, would it not be possible to resolv units the same way? [12:34] sure, I just don't know what it actually does [12:34] something different obviously [12:35] frobware: it looks like it's what youre saying, that juju grabs the first addr it can find, because there is no problem ssh:ing into a unit with just the normal set of interfaces [12:36] it becomes a problem whem ssh:ing to a unit which have docker installed with the docker0 interface etc [12:39] SimonKLB: what's "normal set of interfaces" here? [12:39] frobware: just eth0 and lo [12:46] frobware: it might also be interesting to note that both using proxy=true and proxy=false is trying the same ip, which i guess means both the public and the private ip is wrong? [12:57] SimonKLB: please could you raise a bug for this [12:57] sure [13:11] frobware: did some extra investigation before reporting the bug and noticed that i had an interface on my local computer with the same ip [13:11] frobware: removed that, and now it worked [13:11] oh [13:11] SimonKLB: great! :) [13:12] SimonKLB: because I was beginnging to get a little sidetracked with this. [13:12] is the problem some kind of routing story? [13:12] its odd that it says that it is trying to ssh to a local ip address when you use `juju ssh [unit]` though? [13:15] SimonKLB: and if you try to get to the unit via the proxy does that work? [13:15] yup [13:26] SimonKLB: so it's just resolving to something on your immediate network - which makes sense, no? [13:27] SimonKLB: resolving/connecting [13:31] frobware: yea, but shouldnt it ssh to the external ip of the machine, in that case any local ips shouldnt be in the way [13:31] SimonKLB: I would say no. If you were type `ssh ` wouldn't you expect that to connect based on your current routing? [13:33] frobware: ive deployed juju in aws, i dont understand how you reach it not using the external ip? [13:33] if its not trying to proxy through the controller [13:33] SimonKLB: but containers are not directly accessible without going through the containers proxy - in the AWS case I would always use juju ssh --proxy. [13:34] SimonKLB: ah, --proxy is not the default. [13:34] frobware: yea, and im not trying to reach the containers [13:34] frobware: im just trying to ssh to the machine where the units is deployed [13:34] frobware: SimonKLB right, --proxy is not the default because juju 2 introduced multiple users, read-only users, etc so we can't allow everyone to go through the controller machine for proxy to work [13:35] SimonKLB: oh, so just the host? OK - confused as I thought this conversation started off with a ... docker container. [13:35] frobware: SimonKLB so you have to either use proxy, jump host from the controller, or expose the machine in question with an external IP of some sort [13:36] frobware: yea i think the issue is when docker is installed on the host, it creates extra interfaces, and thats why juju detects the wrong ip address [13:36] frobware: but i dont get why its trying to use that local ip when i ssh from the client [13:38] frobware: im able to reproduce the problem when bringing up the docker interface on my local machine again [13:38] frobware: ill report the bug now when i know how to reproduce it [13:39] SimonKLB: thanks. it helps massively having repro steps - appreciated! [14:13] frobware: does it take a while before juju fetches new unit ips? [14:13] i cant seem to reproduce it with a newly started machine [14:14] it also still keeps ips in memory from interfaces that ive removed from the target machine [14:15] SimonKLB: can you explain the last sentence more [14:16] frobware: if i check `juju status [unit] --format=yaml` it reads ip-addresses from interfaces that are no longer on the machine [14:16] so i guess it takes a while before the state is updated? [14:16] SimonKLB: for a more immediate check bounce the controller - though this seems extreme [14:16] how? [14:17] frobware: can i force refresh the state somehow? [14:50] SimonKLB: the only sure fire way is to restart the jujud process on your controller machine [14:50] frobware: thanks [14:50] SimonKLB: but this seems wrong... [14:50] frobware: agreed, but if it restarted sometimes during my run, the ip addresses might have been updated [14:52] frobware: thats it [14:52] i can reproduce it now [14:52] SimonKLB: if it worked, that seems buggy too. :/ [15:00] frobware: https://bugs.launchpad.net/juju-core/+bug/1646863 [15:00] Bug #1646863: Cannot ssh to unit when Docker is setup on both client and unit machine [15:05] Bug #1646863 opened: Cannot ssh to unit when Docker is setup on both client and unit machine [15:06] frobware: i checked out the code a bit and noticed that LXD/LXC interfaces are filtered out, i guess a quick-fix would be to add Docker interfaces here as well https://github.com/juju/juju/blob/staging/worker/machiner/machiner.go#L141 [15:12] SimonKLB: this was the PR for that change - http://reviews.vapour.ws/r/4478/ [15:13] SimonKLB: but what if you had libvirt interfaces too? and so on. [15:13] mhm [15:15] frobware: are you able to fetch network information from the cloud? [15:15] SimonKLB: in what context? [15:16] frobware: so, if you could query for example the aws api and get the private ip from there instead of relying on the interfaces on the vm [15:16] SimonKLB: right. be data-driven from the provider. Agreed that this would be way better. [15:17] frobware: shouldnt be a very big thing right? since you're using the provider api in other aspects [15:18] SimonKLB: yes - in general, we should not try and guess. That's the worst of all worlds. [15:18] frobware: agreed [15:19] frobware: i dont see any reliable way to determine which interface is the correct one from inside the vm, even if you could filter all of the bridges, one could still have a vm with multiple nics [15:22] frobware: you could filter most of it through `brctl show` however [15:22] SimonKLB: I still have to guess. [15:23] Bug #1646863 changed: Cannot ssh to unit when Docker is setup on both client and unit machine [15:24] rick_h: did you want to chat? [15:25] frobware: oh right sorry [15:25] * rick_h goes back [15:25] ehehe [15:25] you said andy can you hang on then left? [15:25] is that like making him stay in detention and write lines on the board? [15:26] Bug #1646863 opened: Cannot ssh to unit when Docker is setup on both client and unit machine [15:58] anyone around for a quick dep bump review stamp? [15:58] the (more complex) 1.25 and 2.0 branches have landed already [15:59] pr #6651 [16:02] macgreagoir, voidspace: ^around for teeny review? [16:03] mgz: Lemme look... [16:06] mgz: lgtm [16:07] macgreagoir: ta! [16:09] mgz: sure [16:09] mgz: I'm waiting for something anyway [16:10] mgz: looking [16:13] mgz: oh, macgreagoir beat me to it... [16:13] he was fast :) [16:13] Doing my OCR best ;-) [16:13] :-) === urulama is now known as urulama|off === frankban is now known as frankban|afk === redir is now known as redir_travel [18:25] * frobware is not sure landing his change as-is would be wise. :( [18:27] wow [18:34] Fronware why? [18:40] perrito666: I split a script in two. two files. one does transformation. the other applies the transformation. If I run the original (all-in-one) it never fails. If I run them disoint, A, then B then there's occasionally a failure. [18:41] Interesting sound like a race put in evidence by the split [18:42] perrito666: I wonder if this is actually a change in the kernel. the scripts in question down/raise network interfaces. [18:44] If you are using systemd i believe you can query for readyness cant you? [18:51] perrito666: this is long after the machine has booted. [19:17] rick_h: email sent [19:17] rick_h: see you on Monday.... === hml_ is now known as hml [19:22] katco: can you review my updates to the ping code? Hopefully this puts it into the realm where it can be landed. Note that I have a card to write CI tests for these later. [19:22] natefinch: sure [19:22] here's the latest commit : https://github.com/juju/juju/pull/6621/commits/42c89729bfc4ca79a4eda03881cc1474e36e5078 [19:36] natefinch: reviewed... mostly piddly stuff, but a few important questions i think [19:39] katco: cool, thanks [19:39] I love this: [19:39] === RUN TestPackage [19:39] OK: 29 passed [19:39] --- PASS: TestPackage (0.00s) [19:40] :D [19:40] in-memory baby [19:40] So good :) [19:40] natefinch: you're going to have to rebase off of staging or develop [19:41] natefinch: you have some conflicts [19:42] natefinch: not shown, 20s compile time? :P [19:42] katco: yeah, I was going to squash before I rebased, but I didn't want to squash before you reviewed my newest commit, so you didn't have to look at all the changes all over again (if you didn't want to) [19:42] mgz: lol, well, perhaps [19:42] natefinch: ah thanks for the consideration [19:42] natefinch: will probably want another review after rebasing [19:43] mgz: this is actually a pretty isolated package. Building only takes .724s real time :) [19:43] well build and test [19:43] but test is zero, as we know :) [19:44] nice and speedy :) [20:08] katco: so about not implemetned ping methods.... those clouds without ping we also just dont' allow you to interactively add cloud, like GCE and AWS [20:09] katco: so you won't ever see the not implemented error, because they aren't choices we'll let you make. [20:14] natefinch: yeah i saw your comment. thanks for the explanation [20:14] cool [21:22] internal compiler error, fun! [21:23] why do I assume that at 4:30 the friday before a sprint, not a soul is on here but me [21:26] natefinch: i'm still here, but not for much longer :) [21:26] :) [21:26] compiling with go tip (1.8) found a compiler error... fun times [21:26] nice [21:27] Pretty sure Dave said that juju has found a bug in Go for every major release of Go. hate to break the streak [22:28] If anyone is going to be going from the airport to the hotel saturday evening the 3rd ~1600ish or so let me know if you want to share a ride.