| 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:21 |
| alexisb | wallyworld, running behind | 00:32 |
| 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:50 |
| mgz | axw: don't worry about review sepcifics, just want input on api compat issues | 00:57 |
| axw | alexisb: ping when you're ready please | 01:03 |
| alexisb | axw, will do | 01:03 |
| alexisb | sorry | 01:03 |
| 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:07 |
| alexisb | ok axw hoping on the HO | 01:08 |
| babbageclunk | anastasiamac: no, hadn't seen that. D'oh! Will fix - thanks! | 01:09 |
| anastasiamac | babbageclunk: \o/ | 01:09 |
| alexisb | redir, you have a minute to meet with me? | 01:28 |
| redir | alexisb: yup | 01:28 |
| redir | 1:1? | 01:28 |
| alexisb | yep | 01:30 |
| alexisb | good night all, I will see the team in person next week! | 01:56 |
| 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:49 |
| babbageclunk | wallyworld: thanks! | 02:51 |
| wallyworld | babbageclunk: how do we know that the first match is always 0 sent and not 1 or 2? | 02:52 |
| 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:53 |
| wallyworld | babbageclunk: i guess it shows initially the first message and then subsequent | 02:54 |
| * babbageclunk nods | 02:54 | |
| 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:55 |
| 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:56 |
| 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 | 02:58 |
| wallyworld | makes sense looking at the code | 03:00 |
| wallyworld | +1 then, ty | 03:00 |
| babbageclunk | wallyworld: thanks. I'm not super happy with it, but I'm not sure of a better way to fix it. | 03:01 |
| wallyworld | agree with that sentiment, but import thing is to get it fixed | 03:02 |
| wallyworld | pragmatism :-) | 03:02 |
| babbageclunk | :) | 03:02 |
| * babbageclunk steps out for some pre-travel errands. | 03:04 | |
| 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 | 03:58 |
| === frankban|afk is now known as frankban | ||
| 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:52 |
| 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:53 |
| voidspace | cool | 09:54 |
| jamespage | any specific reason why application names can't start with a digit? | 10:45 |
| 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:46 |
| voidspace | jamespage: if there is no good reason for the restriction it is very easy to change the rule | 10:47 |
| jamespage | voidspace, I've emailed the juju-dev ML | 10:49 |
| 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:50 |
| mgz | >_< | 10:51 |
| voidspace | :-) | 10:51 |
| voidspace | or +a | 10:51 |
| voidspace | whichever really, maybe both | 10:51 |
| 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:52 |
| mgz | a0/0 is always a unit | 10:53 |
| voidspace | mgz: you may well be right | 11:31 |
| 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:32 |
| jamespage | voidspace, ack | 11:33 |
| 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:00 |
| SimonKLB | ive only experienced this about a week though, so it might be something added recently | 12:01 |
| SimonKLB | `juju ssh [machine number]` works fine though | 12:02 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| voidspace | sure, I just don't know what it actually does | 12:34 |
| voidspace | something different obviously | 12:34 |
| 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:35 |
| SimonKLB | it becomes a problem whem ssh:ing to a unit which have docker installed with the docker0 interface etc | 12:36 |
| frobware | SimonKLB: what's "normal set of interfaces" here? | 12:39 |
| SimonKLB | frobware: just eth0 and lo | 12:39 |
| 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:46 |
| frobware | SimonKLB: please could you raise a bug for this | 12:57 |
| SimonKLB | sure | 12:57 |
| 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:11 |
| 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:12 |
| frobware | SimonKLB: and if you try to get to the unit via the proxy does that work? | 13:15 |
| SimonKLB | yup | 13:15 |
| frobware | SimonKLB: so it's just resolving to something on your immediate network - which makes sense, no? | 13:26 |
| frobware | SimonKLB: resolving/connecting | 13:27 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| frobware | SimonKLB: thanks. it helps massively having repro steps - appreciated! | 13:39 |
| 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:13 |
| SimonKLB | it also still keeps ips in memory from interfaces that ive removed from the target machine | 14:14 |
| frobware | SimonKLB: can you explain the last sentence more | 14:15 |
| 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:16 |
| SimonKLB | frobware: can i force refresh the state somehow? | 14:17 |
| 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:50 |
| SimonKLB | frobware: thats it | 14:52 |
| SimonKLB | i can reproduce it now | 14:52 |
| frobware | SimonKLB: if it worked, that seems buggy too. :/ | 14:52 |
| 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:00 |
| 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:05 |
| 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:06 |
| frobware | SimonKLB: this was the PR for that change - http://reviews.vapour.ws/r/4478/ | 15:12 |
| frobware | SimonKLB: but what if you had libvirt interfaces too? and so on. | 15:13 |
| SimonKLB | mhm | 15:13 |
| SimonKLB | frobware: are you able to fetch network information from the cloud? | 15:15 |
| frobware | SimonKLB: in what context? | 15:15 |
| 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:16 |
| SimonKLB | frobware: shouldnt be a very big thing right? since you're using the provider api in other aspects | 15:17 |
| frobware | SimonKLB: yes - in general, we should not try and guess. That's the worst of all worlds. | 15:18 |
| SimonKLB | frobware: agreed | 15:18 |
| 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:19 |
| SimonKLB | frobware: you could filter most of it through `brctl show` however | 15:22 |
| frobware | SimonKLB: I still have to guess. | 15:22 |
| 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:23 |
| frobware | rick_h: did you want to chat? | 15:24 |
| 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:25 |
| 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:26 |
| 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:58 |
| mgz | pr #6651 | 15:59 |
| mgz | macgreagoir, voidspace: ^around for teeny review? | 16:02 |
| macgreagoir | mgz: Lemme look... | 16:03 |
| macgreagoir | mgz: lgtm | 16:06 |
| mgz | macgreagoir: ta! | 16:07 |
| voidspace | mgz: sure | 16:09 |
| voidspace | mgz: I'm waiting for something anyway | 16:09 |
| voidspace | mgz: looking | 16:10 |
| voidspace | mgz: oh, macgreagoir beat me to it... | 16:13 |
| mgz | he was fast :) | 16:13 |
| macgreagoir | Doing my OCR best ;-) | 16:13 |
| voidspace | :-) | 16:13 |
| === urulama is now known as urulama|off | ||
| === frankban is now known as frankban|afk | ||
| === redir is now known as redir_travel | ||
| * frobware is not sure landing his change as-is would be wise. :( | 18:25 | |
| frobware | wow | 18:27 |
| perrito666 | Fronware why? | 18:34 |
| 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:40 |
| perrito666 | Interesting sound like a race put in evidence by the split | 18:41 |
| frobware | perrito666: I wonder if this is actually a change in the kernel. the scripts in question down/raise network interfaces. | 18:42 |
| perrito666 | If you are using systemd i believe you can query for readyness cant you? | 18:44 |
| frobware | perrito666: this is long after the machine has booted. | 18:51 |
| voidspace | rick_h: email sent | 19:17 |
| voidspace | rick_h: see you on Monday.... | 19:17 |
| === hml_ is now known as hml | ||
| 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:22 |
| katco | natefinch: reviewed... mostly piddly stuff, but a few important questions i think | 19:36 |
| natefinch | katco: cool, thanks | 19:39 |
| natefinch | I love this: | 19:39 |
| natefinch | === RUN TestPackage | 19:39 |
| natefinch | OK: 29 passed | 19:39 |
| natefinch | --- PASS: TestPackage (0.00s) | 19:39 |
| 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:40 |
| katco | natefinch: you have some conflicts | 19:41 |
| 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:42 |
| 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:43 |
| mgz | nice and speedy :) | 19:44 |
| 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:08 |
| natefinch | katco: so you won't ever see the not implemented error, because they aren't choices we'll let you make. | 20:09 |
| katco | natefinch: yeah i saw your comment. thanks for the explanation | 20:14 |
| natefinch | cool | 20:14 |
| natefinch | internal compiler error, fun! | 21:22 |
| natefinch | why do I assume that at 4:30 the friday before a sprint, not a soul is on here but me | 21:23 |
| 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:26 |
| natefinch | Pretty sure Dave said that juju has found a bug in Go for every major release of Go. hate to break the streak | 21:27 |
| 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. | 22:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!