[00:21] <mgz> 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] <mup> Bug #1625624: juju 2 doesn't remove openstack security groups <ci> <landscape> <openstack-provider> <sts> <juju:In Progress by gnuoy> <juju 2.0:In Progress by gnuoy> <juju-core:In Progress by gnuoy> <https://launchpad.net/bugs/1625624>
[00:32] <alexisb> wallyworld, running behind
[00:50] <axw> 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] <mgz> axw: don't worry about review sepcifics, just want input on api compat issues
[01:03] <axw> alexisb: ping when you're ready please
[01:03] <alexisb> axw, will do
[01:03] <alexisb> sorry
[01:07] <anastasiamac> babbageclunk: did u get a chance to see this one? https://bugs.launchpad.net/bugs/1646504
[01:07] <mup> Bug #1646504: Suite.TestLogTransferReportsProgress messages are different <ci> <intermittent-failure> <regression> <unit-tests> <juju:Triaged> <https://launchpad.net/bugs/1646504>
[01:08] <alexisb> ok axw hoping on the HO
[01:09] <babbageclunk> anastasiamac: no, hadn't seen that. D'oh! Will fix - thanks!
[01:09] <anastasiamac> babbageclunk: \o/
[01:28] <alexisb> redir, you have a minute to meet with me?
[01:28] <redir> alexisb: yup
[01:28] <redir> 1:1?
[01:30] <alexisb> yep
[01:56] <alexisb> good night all, I will see the team in person next week!
[02:49] <babbageclunk> anastasiamac, menn0, wallyworld: can someone review my intermittent test failure fix please? https://github.com/juju/juju/pull/6647
[02:49] <babbageclunk> for bug 1646504
[02:49] <wallyworld> sure
[02:49] <mup> Bug #1646504: Suite.TestLogTransferReportsProgress messages are different <ci> <intermittent-failure> <regression> <unit-tests> <juju:Triaged by 2-xtian> <https://launchpad.net/bugs/1646504>
[02:51] <babbageclunk> wallyworld: thanks!
[02:52] <wallyworld> babbageclunk: how do we know that the first match is always 0 sent and not 1 or 2?
[02:53] <babbageclunk> wallyworld: it logs before starting doing anything
[02:53] <babbageclunk> wallyworld: it means the test's a bit toothless now, but I think that's ok
[02:54] <wallyworld> babbageclunk: i guess it shows initially the first message and then subsequent
[02:54]  * babbageclunk nods
[02:55] <wallyworld> babbageclunk: and just to check, we pass in a test clock to the suite
[02:55] <babbageclunk> wallyworld: yup, up in the setup
[02:56] <wallyworld> babbageclunk: so in that case,  off hand, why isn't the test deterministic then?
[02:56] <wallyworld> we step the clock, we should see deterministic results?
[02:58] <babbageclunk> 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] <wallyworld> makes sense looking at the code
[03:00] <wallyworld> +1 then, ty
[03:01] <babbageclunk> wallyworld: thanks. I'm not super happy with it, but I'm not sure of a better way to fix it.
[03:02] <wallyworld> agree with that sentiment, but import thing is to get it fixed
[03:02] <wallyworld> pragmatism :-)
[03:02] <babbageclunk> :)
[03:04]  * babbageclunk steps out for some pre-travel errands.
[03:58] <wallyworld> 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] <axw> wallyworld: ok
[09:52] <mattyw> hey folks - anyone around able to explain model migration to me?
[09:52] <mattyw> (for now - I just want to know what it is)
[09:52] <voidspace> mattyw: the idea is that you can migrate everything to a new *controller*
[09:52] <voidspace> mattyw: it doesn't migrate the services or units
[09:53] <voidspace> mattyw: but exports the "state of the world" to be imported into a new *controller*
[09:53] <voidspace> mattyw: which can then administer the world
[09:53] <voidspace> mattyw: make sense?
[09:53] <voidspace> mattyw: so it only migrates the "model of the world", not the world itself
[09:53] <mattyw> voidspace, makes perfect sense, thanks very much
[09:54] <voidspace> cool
[10:45] <jamespage> any specific reason why application names can't start with a digit?
[10:46] <voidspace> jamespage: I strongly suspect that the answer is "no good reason"
[10:46] <voidspace> jamespage: I'd file a bug and start a discussion on the mailing list
[10:46] <jamespage> voidspace, ok ta
[10:47] <voidspace> jamespage: if there is no good reason for the restriction it is very easy to change the rule
[10:49] <jamespage> voidspace, I've emailed the juju-dev ML
[10:50] <mgz> it's been that way for ever
[10:50] <jamespage> voidspace, I'll skip the bug for now
[10:50] <voidspace> jamespage: cool
[10:50] <voidspace> jamespage: ok
[10:50] <jamespage> might save some cycles if there is a good reason!
[10:50] <voidspace> mgz: "this is the way we have always done it" is often the reason...
[10:50] <voidspace> and the only reason...
[10:50] <voidspace> mgz: o/
[10:50] <voidspace> 'ning
[10:50] <mgz> monin'
[10:50] <mgz> +r
[10:51] <mgz> >_<
[10:51] <voidspace> :-)
[10:51] <voidspace> or +a
[10:51] <voidspace> whichever really, maybe both
[10:52] <mgz> ehehe
[10:52] <mgz> anyway, my assumption is it made parsing/disamiguating machines/services/units
[10:52] <mgz> 0 is always a machine
[10:52] <mgz> a0 is always an application
[10:53] <mgz> a0/0 is always a unit
[11:31] <voidspace> mgz: you may well be right
[11:32] <voidspace> jamespage: it may be required internally in juju for disambiguating names
[11:32] <voidspace> jamespage: which is not necessarily a good reason, but may actually make it very hard to change
[11:33] <jamespage> voidspace, ack
[12:00] <SimonKLB> 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] <SimonKLB> ive only experienced this about a week though, so it might be something added recently
[12:02] <SimonKLB> `juju ssh [machine number]` works fine though
[12:27] <voidspace> SimonKLB: *sigh*
[12:27] <voidspace> SimonKLB: file a bug please
[12:27] <SimonKLB> voidspace: did i do something stupid? :)
[12:27] <SimonKLB> alright
[12:28] <voidspace> SimonKLB: no, I don't think so
[12:28] <voidspace> SimonKLB: it sounds like juju is doing the wrong thing
[12:28] <voidspace> SimonKLB: but it's actually *hard* for juju to know what the right thing to do is when there are multiple interfaces
[12:28] <voidspace> SimonKLB: it seems obvious as a human when you know what the purpose of all the interfaces are
[12:28] <voidspace> SimonKLB: but juju has to infer all that
[12:29] <mgz> ah, we don't have a friday early standup
[12:29] <mgz> had forgotten
[12:29] <SimonKLB> 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] <voidspace> mgz: I just came to the same realisation
[12:30] <voidspace> SimonKLB: frobware is our expert here
[12:30] <voidspace> SimonKLB: as much as he doesn't want to be the expert here...
[12:30] <SimonKLB> :D
[12:30] <SimonKLB> is he us?
[12:30] <voidspace> SimonKLB: no, UK
[12:30] <SimonKLB> ah great
[12:30] <voidspace> SimonKLB: not sure if he's around today or not
[12:31] <frobware> voidspace, SimonKLB: here....
[12:31] <voidspace> :-)
[12:31] <frobware> (and gone)
[12:31]  * voidspace coffee
[12:31] <frobware> :)
[12:31] <SimonKLB> frobware: nice! any idea whats going on here?
[12:31] <frobware> SimonKLB: context?
[12:31] <SimonKLB> frobware: `juju ssh [unit]` does not grab the correct ip/interface from the looks of it
[12:32] <SimonKLB> while juju ssh [machine] does
[12:32] <frobware> hmm
[12:32] <voidspace> actually that's weird and interesting
[12:32] <frobware> 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] <voidspace> I don't know what juju does when you ask for the ip of a unit
[12:33] <voidspace> I know what it does when you ask for the ip of a machine
[12:33] <SimonKLB> since the unit is kind of linked to a machine, would it not be possible to resolv units the same way?
[12:34] <voidspace> sure, I just don't know what it actually does
[12:34] <voidspace> something different obviously
[12:35] <SimonKLB> 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] <SimonKLB> it becomes a problem whem ssh:ing to a unit which have docker installed with the docker0 interface etc
[12:39] <frobware> SimonKLB: what's "normal set of interfaces" here?
[12:39] <SimonKLB> frobware: just eth0 and lo
[12:46] <SimonKLB> 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] <frobware> SimonKLB: please could you raise a bug for this
[12:57] <SimonKLB> sure
[13:11] <SimonKLB> 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] <SimonKLB> frobware: removed that, and now it worked
[13:11] <frobware> oh
[13:11] <frobware> SimonKLB: great! :)
[13:12] <frobware> SimonKLB: because I was beginnging to get a little sidetracked with this.
[13:12] <SimonKLB> is the problem some kind of routing story?
[13:12] <SimonKLB> 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] <frobware> SimonKLB: and if you try to get to the unit via the proxy does that work?
[13:15] <SimonKLB> yup
[13:26] <frobware> SimonKLB: so it's just resolving to something on your immediate network - which makes sense, no?
[13:27] <frobware> SimonKLB: resolving/connecting
[13:31] <SimonKLB> 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] <frobware> SimonKLB: I would say no. If you were type `ssh <ip-addr>` wouldn't you expect that to connect based on your current routing?
[13:33] <SimonKLB> frobware: ive deployed juju in aws, i dont understand how you reach it not using the external ip?
[13:33] <SimonKLB> if its not trying to proxy through the controller
[13:33] <frobware> 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] <frobware> SimonKLB: ah, --proxy is not the default.
[13:34] <SimonKLB> frobware: yea, and im not trying to reach the containers
[13:34] <SimonKLB> frobware: im just trying to ssh to the machine where the units is deployed
[13:34] <rick_h> 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] <frobware> SimonKLB: oh, so just the host? OK - confused as I thought this conversation started off with a ... docker container.
[13:35] <rick_h> 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] <SimonKLB> 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] <SimonKLB> frobware: but i dont get why its trying to use that local ip when i ssh from the client
[13:38] <SimonKLB> frobware: im able to reproduce the problem when bringing up the docker interface on my local machine again
[13:38] <SimonKLB> frobware: ill report the bug now when i know how to reproduce it
[13:39] <frobware> SimonKLB: thanks. it helps massively having repro steps - appreciated!
[14:13] <SimonKLB> frobware: does it take a while before juju fetches new unit ips?
[14:13] <SimonKLB> i cant seem to reproduce it with a newly started machine
[14:14] <SimonKLB> it also still keeps ips in memory from interfaces that ive removed from the target machine
[14:15] <frobware> SimonKLB: can you explain the last sentence more
[14:16] <SimonKLB> frobware: if i check `juju status [unit] --format=yaml` it reads ip-addresses from interfaces that are no longer on the machine
[14:16] <SimonKLB> so i guess it takes a while before the state is updated?
[14:16] <frobware> SimonKLB: for a more immediate check bounce the controller - though this seems extreme
[14:16] <SimonKLB> how?
[14:17] <SimonKLB> frobware: can i force refresh the state somehow?
[14:50] <frobware> SimonKLB: the only sure fire way is to restart the jujud process on your controller machine
[14:50] <SimonKLB> frobware: thanks
[14:50] <frobware> SimonKLB: but this seems wrong...
[14:50] <SimonKLB> frobware: agreed, but if it restarted sometimes during my run, the ip addresses might have been updated
[14:52] <SimonKLB> frobware: thats it
[14:52] <SimonKLB> i can reproduce it now
[14:52] <frobware> SimonKLB: if it worked, that seems buggy too. :/
[15:00] <SimonKLB> frobware: https://bugs.launchpad.net/juju-core/+bug/1646863
[15:00] <mup> Bug #1646863: Cannot ssh to unit when Docker is setup on both client and unit machine <juju-core:New> <https://launchpad.net/bugs/1646863>
[15:05] <mup> Bug #1646863 opened: Cannot ssh to unit when Docker is setup on both client and unit machine <juju-core:New> <https://launchpad.net/bugs/1646863>
[15:06] <SimonKLB> 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] <frobware> SimonKLB: this was the PR for that change - http://reviews.vapour.ws/r/4478/
[15:13] <frobware> SimonKLB: but what if you had libvirt interfaces too? and so on.
[15:13] <SimonKLB> mhm
[15:15] <SimonKLB> frobware: are you able to fetch network information from the cloud?
[15:15] <frobware> SimonKLB: in what context?
[15:16] <SimonKLB> 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] <frobware> SimonKLB: right. be data-driven from the provider. Agreed that this would be way better.
[15:17] <SimonKLB> frobware: shouldnt be a very big thing right? since you're using the provider api in other aspects
[15:18] <frobware> SimonKLB: yes - in general, we should not try and guess. That's the worst of all worlds.
[15:18] <SimonKLB> frobware: agreed
[15:19] <SimonKLB> 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] <SimonKLB> frobware: you could filter most of it through `brctl show` however
[15:22] <frobware> SimonKLB: I still have to guess.
[15:23] <mup> Bug #1646863 changed: Cannot ssh to unit when Docker is setup on both client and unit machine <juju-core:New> <https://launchpad.net/bugs/1646863>
[15:24] <frobware> rick_h: did you want to chat?
[15:25] <rick_h> frobware: oh right sorry
[15:25]  * rick_h goes back
[15:25] <mgz> ehehe
[15:25] <mgz> you said andy can you hang on then left?
[15:25] <mgz> is that like making him stay in detention and write lines on the board?
[15:26] <mup> Bug #1646863 opened: Cannot ssh to unit when Docker is setup on both client and unit machine <juju-core:New> <https://launchpad.net/bugs/1646863>
[15:58] <mgz> anyone around for a quick dep bump review stamp?
[15:58] <mgz> the (more complex) 1.25 and 2.0 branches have landed already
[15:59] <mgz> pr #6651
[16:02] <mgz> macgreagoir, voidspace: ^around for teeny review?
[16:03] <macgreagoir> mgz: Lemme look...
[16:06] <macgreagoir> mgz: lgtm
[16:07] <mgz> macgreagoir: ta!
[16:09] <voidspace> mgz: sure
[16:09] <voidspace> mgz: I'm waiting for something anyway
[16:10] <voidspace> mgz: looking
[16:13] <voidspace> mgz: oh, macgreagoir beat me to it...
[16:13] <mgz> he was fast :)
[16:13] <macgreagoir> Doing my OCR best ;-)
[16:13] <voidspace> :-)
[18:25]  * frobware is not sure landing his change as-is would be wise. :(
[18:27] <frobware> wow
[18:34] <perrito666> Fronware why?
[18:40] <frobware> 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] <perrito666> Interesting sound like a race put in evidence by the split
[18:42] <frobware> perrito666: I wonder if this is actually a change in the kernel. the scripts in question down/raise network interfaces.
[18:44] <perrito666> If you are using systemd i believe you can query for readyness cant you?
[18:51] <frobware> perrito666: this is long after the machine has booted.
[19:17] <voidspace> rick_h: email sent
[19:17] <voidspace> rick_h: see you on Monday....
[19:22] <natefinch> 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] <katco> natefinch: sure
[19:22] <natefinch> here's the latest commit : https://github.com/juju/juju/pull/6621/commits/42c89729bfc4ca79a4eda03881cc1474e36e5078
[19:36] <katco> natefinch: reviewed... mostly piddly stuff, but a few important questions i think
[19:39] <natefinch> katco: cool, thanks
[19:39] <natefinch> I love this:
[19:39] <natefinch> [19:39] <natefinch> OK: 29 passed
[19:39] <natefinch> --- PASS: TestPackage (0.00s)
[19:40] <katco> :D
[19:40] <katco> in-memory baby
[19:40] <natefinch> So good :)
[19:40] <katco> natefinch: you're going to have to rebase off of staging or develop
[19:41] <katco> natefinch: you have some conflicts
[19:42] <mgz> natefinch: not shown, 20s compile time? :P
[19:42] <natefinch> 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] <natefinch> mgz: lol, well, perhaps
[19:42] <katco> natefinch: ah thanks for the consideration
[19:42] <katco> natefinch: will probably want another review after rebasing
[19:43] <natefinch> mgz: this is actually a pretty isolated package.  Building only takes .724s real time :)
[19:43] <natefinch> well build and test
[19:43] <natefinch> but test is zero, as we know :)
[19:44] <mgz> nice and speedy :)
[20:08] <natefinch> 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] <natefinch> katco: so you won't ever see the not implemented error, because they aren't choices we'll let you make.
[20:14] <katco> natefinch: yeah i saw your comment. thanks for the explanation
[20:14] <natefinch> cool
[21:22] <natefinch> internal compiler error, fun!
[21:23] <natefinch> why do I assume that at 4:30 the friday before a sprint, not a soul is on here but me
[21:26] <katco> natefinch: i'm still here, but not for much longer :)
[21:26] <natefinch> :)
[21:26] <natefinch> compiling with go tip (1.8) found a compiler error... fun times
[21:26] <katco> nice
[21:27] <natefinch> 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] <redir_travel> 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.