| anastasiamac | alexisb: m in 1:1 | 00:03 |
|---|---|---|
| alexisb | anastasiamac, yep I will be there soon | 00:03 |
| anastasiamac | alexisb: k. thnx :) | 00:04 |
| alexisb | thumper, you back yet? | 00:33 |
| menn0 | wallyworld or anastasiamac: https://github.com/juju/juju/pull/6431 | 00:40 |
| wallyworld | looking | 00:41 |
| menn0 | plz :) | 00:41 |
| anastasiamac | menn0: lgtm | 00:42 |
| menn0 | anastasiamac: thanks | 00:43 |
| wallyworld | menn0: question | 00:43 |
| menn0 | wallyworld: yes? | 00:43 |
| wallyworld | in the test, we are passing the same clock value for clock and pingclock | 00:43 |
| wallyworld | so how is that doing anything different? | 00:43 |
| menn0 | wallyworld: no we're not... in these tests, PingClock is the test's clock, Clock is WallClock | 00:44 |
| menn0 | wallyworld: sampleConfig() returns a config where Clock is WallClock | 00:45 |
| wallyworld | menn0: oh right ok, i didn't realise sampleConfig() returned a clock | 00:45 |
| menn0 | wallyworld: np | 00:46 |
| wallyworld | so it's ok to use wall clock | 00:46 |
| wallyworld | we werenm'e before | 00:46 |
| wallyworld | weren't | 00:46 |
| menn0 | wallyworld: it doesn't matter for these tests | 00:46 |
| wallyworld | ok | 00:46 |
| menn0 | wallyworld: the injected clock is used for the code being tested | 00:46 |
| menn0 | wallyworld: the other goroutines can use wallclock and do what they like | 00:46 |
| wallyworld | righto, sorry for dumb question | 00:47 |
| menn0 | wallyworld: not at all, glad you're being suspicious | 00:47 |
| thumper | alexisb: am now | 00:50 |
| menn0 | wallyworld: you happy with these then? | 00:51 |
| menn0 | (that PR) | 00:51 |
| wallyworld | menn0: yeah | 00:51 |
| wallyworld | i figured you'd hit merge | 00:51 |
| thumper | wallyworld: FYI capital case should be "Last Connection" not "Last connection" | 01:29 |
| thumper | IMO | 01:29 |
| wallyworld | thumper: it's FirstLetter case | 01:30 |
| wallyworld | not CapitalCase | 01:30 |
| thumper | fugly | 01:30 |
| alexisb | "hi Jay, I missed you today, I love you" | 01:34 |
| alexisb | "mommy I dont love you" | 01:34 |
| menn0 | alexisb: :( | 01:34 |
| alexisb | "you dont, why?" | 01:34 |
| alexisb | "because your working mommy" | 01:34 |
| alexisb | :( | 01:34 |
| menn0 | alexisb: that sucks | 01:34 |
| menn0 | alexisb: last night I got "I hate you daddy, I hate you all and I want to live somewhere else" | 01:34 |
| menn0 | bed time related, not work related though | 01:35 |
| anastasiamac | ouch :( | 01:35 |
| alexisb | wow | 01:35 |
| alexisb | did you tell her to count to 182? | 01:35 |
| menn0 | bed time is not usually that tough | 01:35 |
| thumper | heh | 01:37 |
| anastasiamac | usually, when kids tell their parents "I hate u" they really mean "I hate the power u have over me" ... | 01:37 |
| wallyworld | huh, i get "i hate you ian" from everyone all the time | 01:37 |
| perrito666 | wallyworld: yup | 01:38 |
| anastasiamac | u must be very powerful :) | 01:38 |
| blahdeblah | I don't hate you, wallyworld; I just hate the fact that sensible-browser isn't, and you still use it anyway. :-P | 01:39 |
| wallyworld | ah firefox vs chrome, vi vs emacs, star trek vs star wars | 01:40 |
| wallyworld | i'd use firefox still if it weren't so slow and bloated | 01:40 |
| blahdeblah | No, nothing that religious; I was just a bit bemused that they could call something sensible-browser that is so demonstrably not so. | 01:41 |
| mup | Bug #1632530 opened: 1.25.6 cannot deploy yakkety lxc units on metal <uosci> <juju-core:New> <https://launchpad.net/bugs/1632530> | 01:42 |
| mup | Bug #1632530 changed: 1.25.6 cannot deploy yakkety lxc units on metal <uosci> <juju-core:New> <https://launchpad.net/bugs/1632530> | 02:03 |
| mup | Bug #1632530 opened: 1.25.6 cannot deploy yakkety lxc units on metal <uosci> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1632530> | 02:09 |
| mup | Bug #1632530 changed: 1.25.6 cannot deploy yakkety lxc units on metal <uosci> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1632530> | 02:12 |
| menn0 | thumper: you might like this one: https://github.com/juju/juju/pull/6432 | 02:28 |
| veebers | menn0, anastasiamac: I believe you mentioned that Christian was working on the memory leak bug? I saw some fixes from him land so I re-ran the long run test and saw a big difference in the overall memory usage (I have commented on the bug 1625774). | 02:31 |
| mup | Bug #1625774: memory leak after repeated model creation/destruction <ateam> <eda> <oil> <oil-2.0> <uosci> <juju:In Progress by 2-xtian> <https://launchpad.net/bugs/1625774> | 02:31 |
| veebers | http://people.canonical.com/~leecj2/perfscalemem/ vs http://people.canonical.com/~leecj2/perfscalemem2/ | 02:31 |
| menn0 | veebers: looking | 02:31 |
| thumper | menn0: +1 | 02:32 |
| menn0 | thumper: thanks | 02:32 |
| anastasiamac | veebers: \o/ this is awesome!!! | 02:42 |
| veebers | anastasiamac: it seems that there are a bunch less mongodb actions happening as well | 02:43 |
| anastasiamac | veebers: yeah both memory and mongodb graphs look neater \o/ | 02:45 |
| anastasiamac | veebers: m sure alexisb would love this too :D | 02:46 |
| alexisb | yay! | 02:46 |
| alexisb | wallyworld, it works | 02:47 |
| alexisb | thanks | 02:47 |
| alexisb | I will report to aaron in the morning | 02:47 |
| wallyworld | awesome | 02:47 |
| wallyworld | thanks for testing | 02:47 |
| wallyworld | i knew it would work :-D | 02:48 |
| alexisb | wallyworld, well really you tested I pressed buttons | 02:48 |
| alexisb | but you are welcome :) | 02:48 |
| alexisb | with that all I am out | 02:48 |
| wallyworld | alexisb: you definitely saw a message saying an update occurred? | 02:48 |
| alexisb | yep | 02:48 |
| wallyworld | good :-) | 02:48 |
| alexisb | wallyworld, ding | 02:49 |
| alexisb | ding | 02:49 |
| alexisb | ding | 02:49 |
| alexisb | ;) | 02:49 |
| wallyworld | dong | 02:49 |
| veebers | thumper, wallyworld: huh, this isn't good: http://reports.vapour.ws/releases/4474/job/run-unit-tests-xenial-s390x/attempt/667 | 02:51 |
| veebers | ../../../golang.org/x/sys/unix/flock.go:18: undefined: Flock_t et. al about 5 undefined in total | 02:52 |
| natefinch | ruh roh | 02:52 |
| thumper | :( | 02:53 |
| veebers | filing a bug now | 02:53 |
| thumper | just in time for GA | 02:54 |
| thumper | wonderful | 02:54 |
| mup | Bug #1632483 changed: juju says error: No selected controller. when there is a typo in the -m parameter it should say "could not find specified model" <usability> <juju:Triaged> <https://launchpad.net/bugs/1632483> | 02:54 |
| veebers | fyi bug 1632541 | 02:57 |
| mup | Bug #1632541: Build fails on s390x due to undefined variables <build> <ci> <regression> <s390x> <unit-tests> <juju:Confirmed> <https://launchpad.net/bugs/1632541> | 02:57 |
| alexisb | thumper, wallyworld we need to get on veebers bug asap ^^^ | 03:01 |
| * wallyworld is finishing addmodel upgrade steps, after that i can look | 03:03 | |
| alexisb | thanks wallyworld | 03:03 |
| natefinch | wallyworld, thumper: should just be a godeps update to newer version of golang/x/sys | 03:04 |
| wallyworld | ok, ta | 03:05 |
| * natefinch goes back to twiddling with simplestreams | 03:07 | |
| mup | Bug #1629817 changed: [arm64] bad cpu-cores detection <arm64> <openstack-provider> <juju:Incomplete> <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1629817> | 03:12 |
| * redir eod | 03:15 | |
| menn0 | anastasiamac, thumper or wallyworld : https://github.com/juju/juju/pull/6433 | 03:16 |
| wallyworld | oooh, a test fix | 03:17 |
| wallyworld | nice | 03:18 |
| alexisb | alright all, I am eod | 03:19 |
| alexisb | see y'all tomorrow | 03:20 |
| === thumper is now known as thumper-afk | ||
| wallyworld | menn0: not sur eif you have a moment for a small review. similar code to existing upgrade steps https://github.com/juju/juju/pull/6435 | 03:46 |
| wallyworld | or anastasiamac ? ^^^^ | 03:58 |
| menn0 | wallyworld: give me a sec and i'll do it | 04:13 |
| wallyworld | ty | 04:13 |
| wallyworld | menn0: and also a one liner please https://github.com/juju/juju/pull/6436 | 04:19 |
| wallyworld | nfi how such an old version of that dependency go committed :-( | 04:19 |
| menn0 | wallyworld: it probably hasn't changed since 2015 | 04:22 |
| menn0 | wallyworld: ship it | 04:22 |
| wallyworld | ty | 04:22 |
| wallyworld | menn0: i think it was a recent dep addition | 04:22 |
| menn0 | wallyworld: ok well that's dumb then | 04:22 |
| wallyworld | whoever did it just used an outdated version perhaps | 04:22 |
| wallyworld | menn0: i checked the commit history of that golang project and s390 was a recent addition, so i *think* it will fix it :-) | 04:24 |
| menn0 | wallyworld: seems plausible | 04:24 |
| menn0 | certainly worth updating | 04:24 |
| wallyworld | if we had wanted to use that package before then we would have been screwed | 04:24 |
| menn0 | wallyworld: other one reviewed. a few suggestions but looks fine. | 04:29 |
| wallyworld | menn0: ty, appreciate it, will fix the issues | 04:30 |
| wallyworld | menn0: i see you suggestions - that will teach me just to copy and tweak existing code without thinking too hard | 04:31 |
| menn0 | wallyworld: haha | 04:31 |
| wallyworld | too much to do, sigh | 04:31 |
| menn0 | I think we've all done it | 04:31 |
| wallyworld | menn0: also did you se email about moving tech board meeting forward 2 hours? | 04:31 |
| menn0 | wallyworld: yeah, I was just about to write about that | 04:32 |
| menn0 | wallyworld: works for me but I don't know about the jam | 04:32 |
| wallyworld | it *should* do, it's his 10am | 04:32 |
| menn0 | wallyworld: jam has been idle for over 41 hrs... I wonder if he's on leave | 04:33 |
| wallyworld | might just be me and you :-) | 04:33 |
| menn0 | which kind of defeats the point | 04:33 |
| * menn0 checks calendar | 04:33 | |
| wallyworld | yeah | 04:33 |
| wallyworld | although we do need to discuss at least the add-model change | 04:33 |
| menn0 | wallyworld: nothing in the calendar | 04:34 |
| wallyworld | i did check yesterday i now recall | 04:34 |
| menn0 | wallyworld: there's certainly important things to discuss | 04:34 |
| wallyworld | we can make a start even if he is not there. he may come on later for his SOD | 04:35 |
| menn0 | wallyworld: ok so meet 2 hours earlier then? | 04:38 |
| wallyworld | yep, let's | 04:38 |
| menn0 | wallyworld: ok | 04:38 |
| menn0 | wallyworld: I'll reply to that email in case John notices that. | 04:39 |
| wallyworld | sgtm, ta | 04:39 |
| thumper-afk | menn0: replied | 05:29 |
| thumper-afk | will remove critical logging :) | 05:29 |
| jam | menn0: I just don't chat as much, just Lurk. :) | 06:00 |
| jam | menn0: I'm there now, though it seems wallyworld is away again? | 06:00 |
| menn0 | jam: he emailed to say he had to pick up his kid. he'll be back at 20 past. | 06:03 |
| menn0 | jam: delay until then? | 06:03 |
| jam | menn0: either way. I don't know what your day is like. Middle of my day so anytime is fine. | 06:03 |
| menn0 | works better for me to delay as kids are going mental right now | 06:03 |
| menn0 | can help my wife | 06:04 |
| menn0 | for a bit | 06:04 |
| menn0 | jam: see you in 15mins | 06:04 |
| wallyworld | menn0: her enow | 06:22 |
| === frankban|afk is now known as frankban | ||
| === thumper-afk is now known as thumper | ||
| thumper | oh... you had the tech board meeting well before what the calendar said | 07:45 |
| thumper | oh well | 07:45 |
| voidspace | frobware: ping | 08:06 |
| frobware | voidspace: pong | 08:12 |
| frobware | voidspace: this is happening because it is latest+greatest lxd (2.4.x) | 08:12 |
| voidspace | frobware: is that right? ah, damn - it means it might not fix the vsphere issue at the same time | 08:14 |
| voidspace | frobware: does the proposed fix work for lxd < 2.4 ? | 08:14 |
| frobware | voidspace: trying now | 08:15 |
| voidspace | heh, I could try it too | 08:15 |
| frobware | voidspace: well... just started looking at this so my hypothesis may turn out to be wrong | 08:15 |
| thumper | o/ | 08:16 |
| thumper | are we expecting babbageclunk? | 08:16 |
| voidspace | thumper: as far as I know, yes | 08:17 |
| voidspace | mgz: ping | 08:19 |
| voidspace | frobware: works fine for me so far with lxd 2.0 (xenial default) | 08:20 |
| voidspace | frobware: my containers (controller plus two units) have started fine with IPv4 addresses and are active | 08:22 |
| voidspace | frobware: so the config change hasn't broken the "default case" | 08:22 |
| frobware | voidspace: which bug did https://github.com/juju/juju/pull/6430 fix? | 08:22 |
| voidspace | frobware: I'm not sure there's a specific bug to track this | 08:22 |
| frobware | voidspace: my mistake: which bug did https://github.com/juju/juju/pull/6338 fix? | 08:23 |
| voidspace | frobware: ah, looking | 08:24 |
| voidspace | frobware: https://bugs.launchpad.net/juju-ci-tools/+bug/1624495 | 08:24 |
| mup | Bug #1624495: operations fails on rackspace because of ipv6 address in dns-name <rackspace> <status> <juju:Fix Committed by mfoord> <juju-ci-tools:Won't Fix> <https://launchpad.net/bugs/1624495> | 08:24 |
| voidspace | frobware: and it seemed to fix that bug | 08:25 |
| voidspace | frobware: that pull request should ensure we get IPv4 *if* we have an IPv4 address that matches the requested scope (public) | 08:25 |
| voidspace | frobware: it won't help if we have a public IPv6 address and only a cloud local IPv4 | 08:26 |
| voidspace | frobware: which I assume is what's happening | 08:26 |
| frobware | voidspace: so in this case the defaults [auto] for IPv6 is enabled when running lxd init on lxd 2.4 | 08:26 |
| voidspace | frobware: we can tweak that code to prefer a cloud local (fallbackScope) IPv4 over a public IPv6 if that's what we want | 08:26 |
| voidspace | frobware: and that's new in 2.4? | 08:26 |
| frobware | voidspace: looking at the steps in: https://bugs.launchpad.net/juju/+bug/1632440, I would say yes. | 08:27 |
| mup | Bug #1632440: rc3, lxd 2.4.1, 16.04/16.10 use ipv6 if configured via lxd init <conjure> <ipv6> <oil-2.0> <uosci> <juju:Triaged by rharding> <https://launchpad.net/bugs/1632440> | 08:27 |
| frobware | voidspace: the question I have (and I think rick_h_ too) is why didn't our 'prefer ipv4 over ipv6' choose the former? | 08:28 |
| voidspace | frobware: see my comment above | 08:28 |
| voidspace | frobware: that pull request should ensure we get IPv4 *if* we have an IPv4 address that matches the requested scope (public) | 08:29 |
| voidspace | frobware: it won't help if we have a public IPv6 address and only a cloud local IPv4 | 08:29 |
| voidspace | frobware: we can tweak that code to prefer a cloud local (fallbackScope) IPv4 over a public IPv6 if that's what we want | 08:29 |
| voidspace | I've added this as a comment to the bug | 08:29 |
| frobware | voidspace: if we did as you suggest wouldn't that a) be better and b) catch other cases like this? | 08:29 |
| voidspace | frobware: it would be better if we were happy to return a cloud local address when a public one is requested | 08:30 |
| frobware | hmm | 08:30 |
| voidspace | frobware: I can prepare a PR with that change | 08:30 |
| voidspace | frobware: can you repro the bug? | 08:30 |
| frobware | voidspace: was about to try | 08:30 |
| voidspace | frobware: you could test my change to see if it fixes it | 08:30 |
| frobware | voidspace: ok, let's do that. if you prepare a patch, I'll look into getting a machine with lxd 2.4 on it | 08:31 |
| voidspace | frobware: cool | 08:31 |
| frobware | voidspace: I cannot repro with 2.0. I changed my local LXD setup to have IPv6 so not sure why we run into this with lxd 2.4 | 08:34 |
| voidspace | frobware: *sigh* | 08:35 |
| frobware | voidspace: I really want to understand the 2.0 case with IPv6 enabled first. | 08:35 |
| frobware | voidspace: bbiab (10 mins) | 08:40 |
| frobware | voidspace: oh... so the reason I cannot make it fail with lxd 2.0 on my machine is I disabled IPv6 for some other bug... :) | 08:58 |
| dooferlad | frobware: yay. The future is here :-) | 08:58 |
| frobware | voidspace: bug #1614953 | 09:00 |
| mup | Bug #1614953: hw csum failure when IPv6 interfaces configured in netdev_rx_csum_fault+0x38/0x40 <amd64> <apport-bug> <kernel-da-key> <kernel-fixed-upstream> <performing-bisect> <xenial> <linux (Ubuntu):In Progress by jsalisbury> <linux (Ubuntu Xenial):In Progress by jsalisbury> <linux (Ubuntu | 09:00 |
| mup | Yakkety):In Progress by jsalisbury> <https://launchpad.net/bugs/1614953> | 09:00 |
| frobware | dooferlad: ^^ :) | 09:00 |
| frobware | dooferlad: most of the time I got the csum failure and occasionally my machine panic'd. so I disabled the whole shebang. I did leave myself a note in /etc/sysctl.conf. | 09:01 |
| * frobware tries to recall what he was doing... | 09:02 | |
| babbageclunk | mgz: ping? | 09:07 |
| * dooferlad tries to think through the haze of fluffy cold brain. Stupid viruses - we have a release! | 09:07 | |
| rogpeppe | an ultra-small PR to fix a bug (8 character change). could someone review please? https://github.com/juju/juju/pull/6438 | 09:08 |
| voidspace | rogpeppe: looking | 09:09 |
| rogpeppe | voidspace: thanks | 09:09 |
| voidspace | rogpeppe: hah, LGTM | 09:10 |
| rogpeppe | voidspace: ta! | 09:10 |
| macgreagoir | I was too slow to review, that was a great one! :-D | 09:11 |
| rogpeppe | oh dammit, it causes tests to fail! | 09:11 |
| rogpeppe | macgreagoir: great but flawed! | 09:12 |
| macgreagoir | Will I look more sensibly slow when it breaks the tests? | 09:13 |
| babbageclunk | macgreagoir: showoff | 09:14 |
| macgreagoir | :-D | 09:15 |
| rogpeppe | macgreagoir: this fixes the fix: https://github.com/juju/juju/pull/6438/files | 09:16 |
| macgreagoir | *coughs* LGTM | 09:18 |
| babbageclunk | rogpeppe: too long now, I'm withdrawing my approval. | 09:24 |
| babbageclunk | I've got a dependency update PR! It's short! https://github.com/juju/juju/pull/6439 | 09:24 |
| * babbageclunk doesn't really withdraw his approval it was just a joke. | 09:28 | |
| macgreagoir | babbageclunk: lgtm, fwiw | 09:30 |
| babbageclunk | macgreagoir: Thanks! You're a graduated reviewer in my heart! | 09:31 |
| macgreagoir | I believe babbageclunk is already drinking in an NZ timezone. | 09:31 |
| * rogpeppe never "graduated" as a juju reviewer | 09:32 | |
| frobware | voidspace: can repro with LXD 2.0 and -rc3 now: http://pastebin.ubuntu.com/23312073/ | 09:37 |
| frobware | voidspace: so baby steps. trying tych0's patch | 09:37 |
| frobware | macgreagoir: your patch is tremendously helpful. http://pastebin.ubuntu.com/23312086/ | 09:41 |
| frobware | macgreagoir: we *must* land this for GA | 09:41 |
| babbageclunk | voidspace, dooferlad, frobware can I get another +1? Or rogpeppe, even though you're not graduated? :) | 09:42 |
| macgreagoir | frobware: You can only blame yourself! :-D | 09:42 |
| frobware | voidspace: ^^ that's LXD 2.0 with tych0's patch | 09:42 |
| * macgreagoir is working on it | 09:42 | |
| frobware | voidspace: I don't see tych0's patch having a positive impact on LXD 2.0... double-checking... | 09:45 |
| frobware | voidspace: and that's because it only looks for the config enabled in the new style networking. | 09:52 |
| frobware | babbageclunk: I previously ran into build issues when bumping the lxd dependencies - mgz has the detail. | 09:57 |
| babbageclunk | frobware: Hmm. Good point - I'll confirm with him. | 09:58 |
| babbageclunk | frobware: Maybe this will be better since there aren't API changes? | 09:58 |
| frobware | babbageclunk: added to the PR comment. but I think the issues are when they build the .debs. | 09:59 |
| voidspace | frobware: does my PR help? | 10:00 |
| frobware | voidspace: let me load that on top. | 10:04 |
| frobware | voidspace: looking at your PR - this is quite a change "cloud local is picked over hostname" | 10:05 |
| babbageclunk | I can't raise mgz - frobware do you know whether he's around today? Or is he just head down on release stuff? | 10:12 |
| frobware | babbageclunk: given the release you might find he's starting his day later for overlap. | 10:12 |
| babbageclunk | Ah right. | 10:12 |
| voidspace | frobware: yes it is quite a change | 10:13 |
| voidspace | frobware: does it work? | 10:13 |
| frobware | voidspace: for a sample size of 1. :) | 10:13 |
| frobware | voidspace: just looking at adding a model, adding 10 containers, verifying no IPv6, destroy model. Lather. Rinse. Repeat. | 10:14 |
| voidspace | frobware: cool | 10:14 |
| voidspace | frobware: it does mean that where we would have got a public hostname we can now get a cloud local IP address | 10:15 |
| voidspace | frobware: I could fix that with a more complex change | 10:15 |
| voidspace | but maybe we would usually prefer the IP address? | 10:15 |
| frobware | voidspace: unless I screwed up... http://pastebin.ubuntu.com/23312299/ | 10:15 |
| voidspace | frobware: so I want to know (from the logs - probably need INFO or TRACE level) what IP addresses those machines have | 10:16 |
| frobware | voidspace: looking | 10:16 |
| voidspace | frobware: I'm pretty confident the address picking code works, so the problem is more likely to be that they *only* have IPv6 addresses | 10:16 |
| frobware | voidspace: your branch has only 1 commit, correct? | 10:16 |
| voidspace | correct | 10:16 |
| voidspace | the production change is trivial | 10:17 |
| frobware | voidspace: I see IPv4 and 6. http://pastebin.ubuntu.com/23312308/ | 10:17 |
| macgreagoir | If anybody has worked on status output, I'm looking for where indentation is specified, please. | 10:22 |
| voidspace | frobware: right, but what does the machine agent see | 10:25 |
| voidspace | frobware: are they still showing ipv6? | 10:26 |
| voidspace | frobware: in juju? | 10:26 |
| frobware | voidspace: http://pastebin.ubuntu.com/23312331/ | 10:26 |
| babbageclunk | macgreagoir: I've worked on that a little bit. Do you mean in yaml serialisation? | 10:26 |
| frobware | voidspace: just adding the logs | 10:27 |
| macgreagoir | babbageclunk: I think so. I need add some indentation to a new list in status and show-machine. | 10:27 |
| macgreagoir | babbageclunk: https://github.com/juju/juju/pull/6424 | 10:27 |
| frobware | voidspace: http://pastebin.ubuntu.com/23312333/ | 10:28 |
| frobware | voidspace: the machine-0.log http://pastebin.ubuntu.com/23312338/ | 10:30 |
| frobware | voidspace: actually that log ^ is of little use | 10:31 |
| voidspace | frobware: I have a failing test case where it is picking IPv6 over IPv4 - debugging | 10:31 |
| macgreagoir | babbageclunk: Don't let me eat your time, though thanks. I'm just looking for a shortcut under time pressure, but I'm sure I can find it. | 10:32 |
| voidspace | frobware: oh for goodness sake | 10:35 |
| voidspace | frobware: network.NewAddress("10.229.221.170") creates an address with type "hostname" | 10:35 |
| frobware | voidspace: controller log: http://178.62.20.154/~aim/controller-machine-0.log | 10:35 |
| voidspace | frobware: so then juju treats it with equal priority to ipv6 | 10:35 |
| frobware | voidspace: ugh? | 10:35 |
| voidspace | frobware: http://pastebin.ubuntu.com/23312355/ | 10:36 |
| voidspace | frobware: I believe this is the cause of the problem | 10:36 |
| frobware | voidspace: we lack distinction between address and hostname, IMO. | 10:36 |
| frobware | voidspace: addresses are bytes. should never be strings until you want to print them. | 10:37 |
| voidspace | frobware: well, evidently... ;-) | 10:37 |
| frobware | voidspace: wow | 10:37 |
| rogpeppe | what's the status on landing stuff in juju master now? is it supposed to be only critical stuff, or has the release been forked now? | 10:38 |
| frobware | rogpeppe: my understanding is only critical | 10:39 |
| rogpeppe | frobware: thanks | 10:39 |
| voidspace | frobware: gah, no - my mistake | 10:40 |
| voidspace | frobware: I gave it the address 10.299.221.170 | 10:40 |
| voidspace | frobware: which is obviously invalid (299) | 10:40 |
| voidspace | frobware: given the choice between 10.199.121.170 and the ipv6 address the address selection does work - even on current master without my change | 10:41 |
| voidspace | frobware: so SelectPublicAddress is not being given that IPv4 address | 10:41 |
| voidspace | coffee | 10:41 |
| babbageclunk | macgreagoir: I think frobware's comment about the indentation is wrong (no offence frobware!). That's just how a list of items is represented in YAML. You can see the same format in the Projects section on yaml.org. | 10:42 |
| rogpeppe | voidspace: FWIW I think a string is a perfectly reasonable representation of an address :) | 10:42 |
| frobware | babbageclunk: fair enough. I just tried various /other/ indenters and they ... indented lists. | 10:42 |
| frobware | rogpeppe: semantically broken | 10:43 |
| rogpeppe | voidspace: but i don't think that Type should be part of Address - it should be a method | 10:43 |
| rogpeppe | frobware: how so? | 10:43 |
| voidspace | rogpeppe: agreed | 10:43 |
| voidspace | rogpeppe: it shouldn't be possible for it to be wrong | 10:43 |
| rogpeppe | voidspace: it's always possible for it to be wrong, even if it's just a set of bytes | 10:43 |
| voidspace | I meant Type | 10:44 |
| rogpeppe | voidspace: ah yes, indeed | 10:44 |
| frobware | rogpeppe: because you only need it as a string for display. the type system should aid us to disntinguish between hostnames and addresses. if we need a hostname (string) then convert. but the I believe the base type of an IP address is []byte. | 10:44 |
| voidspace | really coffee | 10:45 |
| macgreagoir | babbageclunk: Cheers, I'm not seeing any standard flags to indent either. frobware, maybe this could be a nicety for later if we decide it's better? | 10:45 |
| rogpeppe | frobware: it's really useful to be able to connect to an address whether it's a DNS name or IP address | 10:45 |
| rogpeppe | frobware: we do it on the command line all the time | 10:45 |
| rogpeppe | frobware: given that there's no syntactic overlap between the two, having a single string representation seems good to me | 10:46 |
| frobware | rogpeppe: sure. it's more about the internal type. | 10:46 |
| rogpeppe | frobware: why does it matter? | 10:46 |
| frobware | rogpeppe: ^^ network.NewAddress("10.229.221.170") creates an address with type "hostname" | 10:47 |
| rogpeppe | frobware: in my view, very little code should need to care about addresses as other than an opaque string | 10:47 |
| rogpeppe | frobware: it doesn't | 10:47 |
| rogpeppe | frobware: (i checked) | 10:47 |
| frobware | rogpeppe: we've also given this problem to the charmers - when we say "address" they say I want to both "address" and "name" | 10:48 |
| rogpeppe | frobware: ? | 10:48 |
| frobware | rogpeppe: network-get address | 10:48 |
| frobware | rogpeppe: it's not clear what that returns. they faff around trying IPaddress? symbolic-hostname? should I always convert? | 10:49 |
| frobware | rogpeppe: if we had: network-get hostname and network-get address then it would be clearer | 10:49 |
| rogpeppe | frobware: why should it matter? | 10:49 |
| frobware | rogpeppe: apparently it matters to the. hadoop for one. | 10:49 |
| babbageclunk | frobware: I think it's just a neither-a-bug-nor-a-feature of the particular yaml serialiser we use. | 10:49 |
| rogpeppe | frobware: if you need an ip address and your software doesn't know how to resolve it, then you can resolve it easily | 10:50 |
| rogpeppe | frobware: FWIW network-get seems to document that it returns an IP address | 10:51 |
| frobware | rogpeppe: except for the times it returns a symbolic name | 10:51 |
| rogpeppe | frobware: in that case the doc should be changed | 10:51 |
| rogpeppe | frobware: (or the code changed) | 10:52 |
| frobware | rogpeppe: the charmers want both 'name' and 'address'. where 'address' is always an IP address (in string format) | 10:52 |
| rogpeppe | frobware: what would "name" return if there's no DNS name? | 10:53 |
| frobware | rogpeppe: IP address. | 10:53 |
| rogpeppe | frobware: ha ha | 10:53 |
| frobware | rogpeppe: :) | 10:53 |
| frobware | rogpeppe: but that's OK... | 10:53 |
| frobware | rogpeppe: what needs fixing is DNS | 10:53 |
| rogpeppe | frobware: so what's wrong with just returning something that's either a name (which can be resolved) or an IP address (if there's no name) ? | 10:53 |
| rogpeppe | frobware: what's wrong with DNS? | 10:54 |
| frobware | rogpeppe: semantically they want the distinction: if I call `network-get address` I know that will always be a dotted-quad. | 10:54 |
| frobware | rogpeppe: nothing wrong with DNS except we don't always end up with a setup that resolves names. and that's just a bug. | 10:55 |
| rogpeppe | frobware: if it's really too much hassle for charm software to resolve a DNS name then you could add a --resolved or --numeric flag to network-get | 10:55 |
| frobware | rogpeppe: oh... I think the issue is more on the juju/maas/cloud side | 10:55 |
| rogpeppe | frobware: ah, so it can return a DNS name that's unresolvable? | 10:55 |
| frobware | rogpeppe: correct. bug. | 10:55 |
| rogpeppe | frobware: if that's the case, how could the charm resolve it to return it? | 10:56 |
| rogpeppe | s/the charm/juju/ | 10:56 |
| frobware | rogpeppe: they shouldn't have to. if DNS is working then `network-get address` and `network-get hostname` would just be correct. Assuming that's actually your question. | 10:57 |
| rogpeppe | frobware: so the bug is really that it's returning invalid DNS names, not that people need numeric IP addresses per se? | 10:57 |
| frobware | rogpeppe: certain s/w want both to forwars/reverse resolve correctly: http://sujee.net/2012/03/08/getting-dns-right-for-hadoop-hbase-clusters/ | 10:58 |
| frobware | rogpeppe: the java big data stacks seem to be the pickiest | 10:59 |
| frobware | rogpeppe: (hopefully) no offense, but need to step out of this discussion and fix the IPv6 issue ... | 11:00 |
| rogpeppe | frobware: np :) | 11:00 |
| * rogpeppe undistracts | 11:00 | |
| frobware | voidspace: where are we... ? :) | 11:11 |
| macgreagoir | dimitern: Just a reminder that you wanted to comment on https://github.com/juju/juju/pull/6424 too. | 11:11 |
| voidspace | frobware: well, tych0's fix works for 2.4, but not for 2.0 for you - right? | 11:12 |
| frobware | voidspace: I need to _actually_ try on 2.4. | 11:12 |
| voidspace | frobware: and my fix doesn't help 2.0? | 11:13 |
| frobware | voidspace: I understand why it doesn't. | 11:13 |
| frobware | voidspace: not unless you've pushed since | 11:13 |
| voidspace | frobware: I haven't | 11:13 |
| voidspace | frobware: so the problem is not in address selection but in the addresses we see for the machine | 11:13 |
| dimitern | macgreagoir: hey, yeah - sorry I got distracted, looking now | 11:13 |
| macgreagoir | Cheers :-) | 11:13 |
| voidspace | frobware: which I think is the same problem vsphere has | 11:14 |
| voidspace | frobware: but I can't repro | 11:14 |
| voidspace | fiddling with my lxd settings | 11:14 |
| frobware | voidspace: to repro on LXD 2.0 you need to reconfigure LXD to use IPv6 - by default I was only using IPv4. | 11:15 |
| voidspace | frobware: yeah, just done that with dpkg-reconfigure | 11:15 |
| frobware | voidspace: and for LXD 2.4 this might be the easiest way: https://lists.ubuntu.com/archives/snapcraft/2016-October/001327.html | 11:16 |
| rick_h_ | frobware: voidspace ty for helping to chase this down. As lxd 2.4 is going to get backported I'm mostly concerned there. | 11:26 |
| rick_h_ | frobware: voidspace if we can get it working back in 2.0 that's a bonus imo | 11:27 |
| frobware | rick_h_: the 2.0 case could be just a release note atm | 11:28 |
| rick_h_ | frobware: k, and we can go the route that folks need to configure an ipv4 only lxd to get it to work there, for instance. | 11:28 |
| frobware | rick_h_: yep, it's essentially the message you would [now] get on LXD 2.4 with IPv6 enabled. | 11:29 |
| * rick_h_ has to get the boy fed and dressed for school, biab | 11:29 | |
| rick_h_ | macgreagoir: how's the upgrade steps looking? | 11:30 |
| frobware | rick_h_: but having faffed around a bit, I think we could do the same change but detect in /etc/default/lxd-bridge | 11:30 |
| macgreagoir | rick_h_: They tested OK for me. Sent you and wallyworld an email with details. | 11:30 |
| rick_h_ | frobware: k, just need something as solid as we can get this morning so we can build a GA today. | 11:30 |
| * frobware goes back to actually trying LXD 2.4 | 11:31 | |
| rick_h_ | macgreagoir: k, please pull in any help to get reviewed/landed so it's not blocking GA | 11:31 |
| macgreagoir | rick_h_: It's already merged, so I think we're grand. | 11:31 |
| voidspace | with ipv6 enabled and lxd 2.0 I see containers with both IPv6 and IPv4 addresses, but juju picks (correctly) the ipv4 address | 11:34 |
| voidspace | that's with current master | 11:35 |
| voidspace | so I can't repro | 11:35 |
| voidspace | yet | 11:37 |
| frobware | voidspace: how do you determine that it correctly picks IPv4? from status, something else? | 11:37 |
| voidspace | frobware: from status | 11:37 |
| voidspace | frobware: in the problematic cases, status was showing an ipv6 address - status address comes from dns-name which is PreferredPublicAddress | 11:38 |
| voidspace | which comes from address selection | 11:38 |
| dimitern | macgreagoir: you've got a review on 6424 | 11:42 |
| * macgreagoir looks | 11:42 | |
| macgreagoir | dimitern: Cheers, I've just been looking at ScopeMachineLocal and ScopeLinkLocal in tests. | 11:43 |
| dimitern | tych0: you've got a review on 6430 as well | 11:47 |
| voidspace | mgz: ping | 13:24 |
| mgz | voidspace: yo | 13:28 |
| voidspace | mgz: I'm still trying to connect to vsphere and I wondered if you had any further ideas | 13:31 |
| voidspace | mgz: I can ssh in now | 13:31 |
| mgz | voidspace: okay, so now do exactly what the vsphere-deploy-trusty-amd64 job does? | 13:33 |
| mgz | be jenkins, export JUJU_DEV_FEATURE_FLAGS=vsphere-provider | 13:33 |
| mgz | and run the ci script? | 13:34 |
| voidspace | mgz: ok, will try - otp right now | 13:34 |
| voidspace | mgz: thanks | 13:34 |
| rick_h_ | natefinch: ping | 13:49 |
| natefinch | rick_h_: yo | 13:50 |
| rick_h_ | natefinch: howdy, how goes the streams tool work? It's the last issue blocking GA atm. | 13:51 |
| natefinch | rick_h_: I couldn't reproduce the problem last night. It seems to work fine for me | 13:51 |
| natefinch | rick_h_: I was just about to ping sinzui about it | 13:52 |
| rick_h_ | natefinch: please get with sinzui then as he's pretty confident it doesn't work. I think there's some misunderstanding about what works and what doesn't. | 13:52 |
| katco | rogpeppe: hey, fyi discussion of your retry package was bumped from this week's tech board meeting due to time. it's on the docket for next week | 13:52 |
| rogpeppe | katco: thanks. yeah, i heard from menno this morning. | 13:53 |
| rogpeppe | katco: unfortunately i'll be away at a sprint next week | 13:53 |
| katco | rogpeppe: I responded to your review yesterday with some questions. just a few; we should be able to get this landed | 13:53 |
| rogpeppe | katco: i thought it might be nice to join that discussion | 13:53 |
| katco | rogpeppe: agreed. i think it's in your morning? | 13:54 |
| rogpeppe | katco: i'm not sure i should land it now as it's all frozen for GA, right? | 13:54 |
| sinzui | natefinch: the bug was reported after you were trying to make streams with 2.x agents. If generate-tools now makes streams with 2.x agents, and juju can bootstrap with them, then the bug is fixed | 13:54 |
| katco | rogpeppe: oh, has that happened already? | 13:54 |
| rogpeppe | katco: it'll be at 10am CET I think | 13:54 |
| rogpeppe | katco: i'm not sure. someone assured me we should only land critical bug fixes and i don't think that really counts as that. | 13:54 |
| rick_h_ | rogpeppe: katco +1 | 13:55 |
| katco | rogpeppe: hm, ok. | 13:55 |
| rick_h_ | rogpeppe: katco we've got one blocker landing atm and natefinch's is the last thing we're waiting for GA to go final | 13:55 |
| katco | rogpeppe: well at any rate, happy to carry on discussion so we can land for 2.1 | 13:55 |
| katco | rick_h_: cool | 13:55 |
| rogpeppe | katco: i actually wanted to get the next PR (dependent on that one) landed because that changes a controller config attribute name, but i think the delays to that PR have made that infeasible | 13:55 |
| natefinch | sinzui: I'm not sure the repro steps in the bug are sufficient for me to be confident about the fix. I trust that you tried it and it didn't work... I'm just not sure where the disconnect it | 13:55 |
| natefinch | s/it/is/ | 13:55 |
| sinzui | natefinch: i have not tried in in weeks | 13:56 |
| rogpeppe | katco: i guess we'll just have to live with the wrong config attribute name for 5 years :) | 13:56 |
| rick_h_ | rogpeppe: juju 2.0 isn't on a 5yr plan :P | 13:57 |
| natefinch | sinzui: I would appreciate if you could give it a try. I hope it was just a momentary thing that is now past... but I think it would be faster for you to just try it than to try to give me exact steps. | 13:57 |
| rogpeppe | katco: thanks for the on-going reviews BTW | 13:57 |
| rick_h_ | rogpeppe: so I think only 18mo? | 13:57 |
| rogpeppe | rick_h_: oh, that's good! | 13:57 |
| rick_h_ | rogpeppe: or we make it backward compatible. Accept both values, but move the docs/etc to the new value name | 13:57 |
| rick_h_ | rogpeppe: so you can push things forward in a clean way | 13:57 |
| katco | rogpeppe: more than happy to do so. trying to find that balance between expediency and making sure we're moving the codebase in a good direction with every commit | 13:57 |
| sinzui | natefinch: so you got streams with 2,x in them and juju bootstrapped with them. If, so the bug is fixed | 13:57 |
| rick_h_ | sinzui: this can be used with canonistack correct? to test it out? | 13:58 |
| voidspace | having to reset network | 13:58 |
| voidspace | bbiab | 13:58 |
| rick_h_ | natefinch: have you generated the file and attempted to use it as streams to bootstrap against? | 13:59 |
| rick_h_ | natefinch: sinzui this means sticking the file up at some url and referencing that via bootstrap config correct? | 13:59 |
| natefinch | rick_h_: I generated the streams and they have 1.25 and 2.x in then... I don't actually know how to bootstrap with them | 13:59 |
| sinzui | rick_h_: yep, any cloud and lxd. So long as your localhost and the controller machine can see the streams that agent-metadata-url point to, the test is valid. bootstrap with --debug so that juju will show you where it downloaded the agent from. | 14:00 |
| rick_h_ | natefinch: https://jujucharms.com/docs/2.0/howto-privatecloud | 14:00 |
| rick_h_ | natefinch: does that work with the file you get | 14:00 |
| mgz | stand-de-up? | 14:01 |
| rick_h_ | natefinch: dimitern voidspace ping for standup | 14:01 |
| natefinch | rick_h_: I don't have openstack. I have a maas, not sure how to use these generated simplestreams with them though | 14:01 |
| natefinch | rick_h_: figuring it out now... bootstrapping with tools-metadata-url IIRC | 14:04 |
| sinzui | natefinch: The problem is the same. run generate-tools with some agents you downloaded. push the generate tree to a website iike people.canonical.com or to swift like canonistack, or to s3 in aws. | 14:04 |
| sinzui | natefinch: use "agent-metadata-url" tools-* was obsoleted more than 6 months ago | 14:05 |
| natefinch | sinzui: oh yeah, I was looking at old docs | 14:06 |
| natefinch | sinzui: it's too bad, the old docs were a lot clearer | 14:07 |
| tych0 | dimitern: you around? | 14:08 |
| sinzui | natefinch: https://jujucharms.com/docs/2.0/howto-privatecloud is not about agents. | 14:09 |
| sinzui | natefinch: That is about image streams. So the new docs are missing 50% of the work | 14:09 |
| sinzui | natefinch: https://jujucharms.com/docs/1.25/howto-privatecloud#tools-metadata is the relavent part from the old docs | 14:10 |
| macgreagoir | frobware dimitern: PR 6424 has a new commit, whenever you're ready, please. | 14:11 |
| natefinch | sinzui: when I specified agent-metadata-url ... do I specify the /tools directory, or the directory above that? I can never remember | 14:13 |
| sinzui | natefinch: the directory that contains streams/ | 14:14 |
| dimitern | macgreagoir: one comment added, but I couldn't see tests with IPv6 addresses? | 14:19 |
| macgreagoir | dimitern: https://github.com/juju/juju/pull/6393 | 14:20 |
| macgreagoir | dimitern: ignore ^ | 14:20 |
| macgreagoir | dimitern: https://github.com/juju/juju/pull/6424/files#diff-e3aecf740b74fe827fbd780d709c29e5R2605 | 14:20 |
| rick_h_ | dooferlad: I'm going to head back from the coffee shop, should be back on in time for our meeting, but if I'm a min/two late be right there | 14:20 |
| natefinch | aaahhhh $ juju credentials | 14:29 |
| natefinch | ERROR removing secrets from credentials for cloud azure: auth-type "userpass" not supported | 14:29 |
| katco | rogpeppe: your pr lgtm | 14:29 |
| rogpeppe | katco: thanks | 14:29 |
| katco | rogpeppe: ty | 14:29 |
| rogpeppe | katco: BTW I don't always for two LGTMs from core, but I would never submit a PR after someone had asked for changes without getting their +1 first. | 14:30 |
| rogpeppe | s/for/ask for/ | 14:30 |
| katco | rogpeppe: ack; that is very gracious of you | 14:31 |
| katco | rogpeppe: i feel the same way | 14:31 |
| rogpeppe | katco: isn't that, like, a thing | 14:31 |
| katco | rogpeppe: i dunno, i've seen review-points get summarily dropped | 14:31 |
| rogpeppe | katco: i'd be disappointed in general if someone did it to me. otherwise i could just go around to someone else if i didn't like the review someone had given me. | 14:31 |
| katco | rogpeppe: yeah | 14:32 |
| rogpeppe | katco: well, if that really happens, it's not ok | 14:32 |
| natefinch | Hopefully no one just drops review points without a discussion. Sometimes the discussion may happen outside the review tool, so it may not be obvious (which is I why I try to note it if it was - "per discussion with x...") | 14:36 |
| katco | natefinch: saw it happen a few times ("disagree" & close) | 14:39 |
| natefinch | rick_h_, sinzui: bootstrapping with the generated file and agents in 2.0 seems to work fine. | 14:41 |
| sinzui | :) | 14:41 |
| rick_h_ | natefinch: <3 is that with any change or just as it is in trunk? | 14:42 |
| natefinch | rick_h_, sinzui: as it is in trunk | 14:42 |
| rick_h_ | katco: can you please get with natefinch and provide a confirmation there please? | 14:42 |
| sinzui | natefinch: you used 2.0.0? | 14:42 |
| natefinch | sinzui: current master, yes | 14:42 |
| sinzui | natefinch: maybe devel agents are the problem...I am not sure I care if juju cannot make streams for devel agents | 14:42 |
| katco | rick_h_: natefinch: sure... what do you need me to do? | 14:42 |
| natefinch | katco: I'm looknig at this bug: https://bugs.launchpad.net/juju/+bug/1613858 | 14:43 |
| mup | Bug #1613858: generate-tools ignores 2.x agents and creates bad path <jujuqa> <metadata> <regression> <rteam> <simplestreams> <streams> <juju:Incomplete by natefinch> <https://launchpad.net/bugs/1613858> | 14:43 |
| rick_h_ | katco: natefinch maybe best to hop on a HO and walk through it and make sure it's replicatable | 14:43 |
| natefinch | katco: moonstone? | 14:44 |
| natefinch | https://hangouts.google.com/hangouts/_/canonical.com/moonstone?authuser=2 | 14:44 |
| katco | natefinch: sure | 14:44 |
| macgreagoir | dimitern: This time :-) https://github.com/juju/juju/pull/6424 | 15:09 |
| macgreagoir | dimitern frobware katco: I'm not sure if that PR qualifies as changing a published API (adding IPAddreses). ^ | 15:10 |
| dimitern | macgreagoir: strictly speaking, yes it does | 15:11 |
| rogpeppe | natefinch: FWIW i replied to your comment and made some minor changes to https://github.com/juju/utils/pull/245. | 15:12 |
| * macgreagoir takes a look to see if that can be avoided... | 15:12 | |
| dimitern | macgreagoir: LGTM | 15:13 |
| katco | macgreagoir: hm, i don't know our stance on that. I don't think adding fields should break backwards compatibility | 15:13 |
| katco | macgreagoir: but i'm not positive | 15:13 |
| dimitern | macgreagoir: it can't be avoided, but adding stuff is less of an issue than changing/removing stuff | 15:13 |
| katco | macgreagoir: don't those fields need comments? | 15:13 |
| katco | dimitern: well, it can be avoided by bumping the facade revision | 15:13 |
| dimitern | katco: sure :) .. if there was a release with the new api version so far | 15:14 |
| katco | rick_h_: do you happen to know if adding fields to API params requires a facade revision bump? | 15:14 |
| katco | dimitern: we have promised backwards compatibility from rc1 i think? | 15:14 |
| rick_h_ | katco: adding should not, the name of the field is new/different? or have we changed the type of an existing field? | 15:15 |
| katco | rick_h_: macgreagoir correct me if i'm wrong, but looks like just new fields | 15:15 |
| rick_h_ | katco: as long as we add it as a new field and didn't remove the old then no, shouldnot require any bump | 15:15 |
| macgreagoir | katco: You are not wrong. | 15:15 |
| macgreagoir | Added | 15:16 |
| katco | macgreagoir: cool, should be good then. please throw some comments on there. i don't know why we seem to be ignoring that rule in this file... | 15:16 |
| macgreagoir | rick_h_: Aye, it is a new field, no existing have been changed. | 15:17 |
| macgreagoir | katco: Let me add some comments... | 15:17 |
| rick_h_ | macgreagoir: <3 | 15:17 |
| natefinch | rick_h_: katco was able to generate the streams as well, do we need to do the whole upload to s3 thing from her machine as well? | 15:34 |
| natefinch | sinzui: ^ | 15:34 |
| rick_h_ | natefinch: a whole bootstrap. if we can bootstrap --debug and it's using the streams/etc then cool | 15:35 |
| natefinch | rick_h_: ok | 15:35 |
| katco | does anyone know how to use s3cmd to get the url for an s3 bucket? | 15:58 |
| natefinch | if you can get the UUID of the bucket, it should just be https://s3.amazonaws.com/<uuid> | 15:59 |
| macgreagoir | katco: If you please, https://github.com/juju/juju/pull/6424/files#diff-8af0b17f03b1bac65594c1e20a5798ecR47 | 16:06 |
| katco | macgreagoir: look great, ta! | 16:07 |
| macgreagoir | It's all my fault from here on in if the comments are misleading! | 16:07 |
| katco | macgreagoir: lol | 16:07 |
| redir | macgreagoir: I think your last comment was misleading | 16:21 |
| macgreagoir | redir: It's not alwayas real hardware, I know. | 16:21 |
| redir | apparently I need to work on my deadpan delivery | 16:23 |
| macgreagoir | :-D | 16:23 |
| redir | so I got an alert today that I am OCR next week, and I have no idea where that comes from.; | 16:25 |
| frankban | hey rick_h_: who can we ping for problems bootstrapping juju on openstack provider? | 16:25 |
| macgreagoir | rick_h_: The list-ip-addrs-in-status PR is approved. Is it good to merge or has it missed the deadline? | 16:26 |
| frobware | rick_h_: in respect of the deadline I'm still doing the LXD fix | 16:28 |
| rick_h_ | frankban: what's up? file a bug and we'll see if we can see what's up | 16:29 |
| rick_h_ | macgreagoir: yes please land | 16:29 |
| macgreagoir | rick_h_: ack | 16:30 |
| frankban | rick_h_: we are trying to bootstrap juju on openstack in bastion, and it's stuck on "waiting for address", but at this point we don;t know if we missed something in the process or if it's a juju bug | 16:30 |
| frankban | rick_h_: we'd like some help to unblock us, in preparation for demos | 16:31 |
| redir | anyone seen this cannot start bootstrap instance: no "xenial" images in us-west-1 with arches [amd64] | 16:33 |
| redir | ? | 16:33 |
| katco | sinzui: how would i tell bootstrap to look for devel streams instead of released? | 16:34 |
| rick_h_ | frankban: k, you're vpn'd in or have access to the address that was allocated to the machine? | 16:35 |
| katco | larger question, how do i enumerate the possible config values? | 16:35 |
| rick_h_ | frankban: k, the best folks might be other folks using bastion or openstack users there unfortunately. Maybe reach out to nice OS folks like beisner or thedac | 16:36 |
| frankban | rick_h_: yes we'll ask them, ty | 16:36 |
| natefinch_ | katco: you mean bootstrap --config values? (I may have missed a bit, had to log out and back in). | 16:37 |
| sinzui | katco: add "--config agent-stream=devel" at boostrap | 16:37 |
| natefinch_ | katco: I don't think we have a way to list them... there's docs, but I don't know how up to date they are | 16:38 |
| redir | katco: --config agent-stream=devel or something | 16:38 |
| redir | doh | 16:38 |
| katco | natefinch_: couldn't find docs =/ | 16:39 |
| katco | sinzui: ta, i was using image-stream | 16:39 |
| natefinch_ | yeah, the docs are well hidden | 16:39 |
| natefinch_ | katco: https://jujucharms.com/docs/2.0/models-config | 16:40 |
| redir | so are the images | 16:40 |
| redir | I can't deploy xenial or trusty to us-*-* | 16:41 |
| sinzui | redir: is that aws us-west-1? | 16:44 |
| natefinch_ | I hate the way we call that model config even though almost all of those are controller-specific. I mean, you can't have a different agent-metadata-url per model, can you? | 16:44 |
| sinzui | redir: no, I think it is google | 16:44 |
| sinzui | natefinch_: yes, I think juju should be more like snaps in this case. juju bootstrap --devel | 16:45 |
| redir | sinzui aws us-west/east-1/2 | 16:45 |
| * redir removes custom clouds | 16:46 | |
| sinzui | redir us-west-1, us-west-2, and us-east-1 do have both xenial and trusty | 16:48 |
| sinzui | in aws | 16:48 |
| redir | sinzui: yea I have a custom cloud which makes the closest region to me the default and speeds up dev time waiting for it to spin up... It has worked since April and suddenly seems to have stopped | 16:49 |
| redir | which is probably unrelated to streams other than the error | 16:50 |
| redir | next I blame --build-agent | 16:50 |
| frobware | rick_h_: https://github.com/juju/juju/pull/6430 is good to merge - did I miss the deadline? | 16:54 |
| rick_h_ | frobware: no, we're holding for athat and natefinch_'s work so please go ahead and merge | 16:55 |
| rick_h_ | natefinch_: katco how are we doing? is it still working properly and can bootstrap with the generated streams file? | 16:56 |
| katco | rick_h_: i am still trying to bootstrap with the generated streams | 16:57 |
| rick_h_ | katco: k, ty for the update | 16:57 |
| frobware | rick_h_: I need to run but $$merge'd. | 16:57 |
| redir | looks like we changed things in rc2 | 16:58 |
| rick_h_ | frobware: k, will watch it ty | 16:58 |
| === frankban is now known as frankban|afk | ||
| natefinch_ | sinzui: do we have a CI test for this? Seems like "two devs tried it and it sorta seemed to work" is not the best verification strategy ;) | 17:03 |
| sinzui | natefinch_: we do not. We stopped using generate-tools in January. When you asked me how to make streams a few weeks ago, you reported that your 2.x agents were not found, when I ran the commands, I confirmed 2.x agents were skipped and that the directory structure was incorrect | 17:05 |
| natefinch_ | I just retried, making sure to use --agent-stream=devel and it still seems to work. The log output is kind of hard to read, so it's possible it's not actually downloading from my S3 bucket... but I think it is: http://pastebin.ubuntu.com/23313802/ | 17:14 |
| natefinch_ | oh, no, wait, it's not | 17:15 |
| natefinch_ | crud | 17:15 |
| katco | sinzui: natefinch_: that's where i'm stuck at. this concerns me: found 0 packaged agent binaries | 17:15 |
| natefinch_ | No packaged binary found, preparing local Juju agent binary | 17:15 |
| katco | natefinch_: that's the message i'm getting so i was triyng to figure out if i had it set up wrong or if it really just isn't | 17:15 |
| sinzui | katco: does the com file for released or devel list the binaries you made | 17:15 |
| natefinch_ | sinzui: mine does: http://pastebin.ubuntu.com/23313815/ | 17:17 |
| natefinch_ | I gotta run. Doctor time. Good luck guys, sorry I can't be of more help debugging. | 17:18 |
| natefinch_ | s/guys/fellow engineers/ | 17:18 |
| redir | yup, it ignores old region endpoints, replacing it with new region endpoints from goamz. But then it must ignore that change or just use the now bad endpoint data to find instances. Not too sure, but updating endpoints in my custom config WFM. | 17:19 |
| katco | sinzui: i don't think it does, just the 1.24.1 series, not 2.0? | 17:24 |
| sinzui | katco: :( | 17:25 |
| katco | sinzui: looking at nate's comment on the bug, it looks like it does? i was running master | 17:26 |
| katco | sinzui: i.e.: "com.ubuntu.juju:16.04:amd64": { | 17:26 |
| sinzui | katco: I will try with a recent juju and and a few agents | 17:27 |
| katco | sinzui: sorry, i don't deal with this a lot. i might be fumbling somewhere | 17:27 |
| sinzui | katco: I think that fact that "juju metadata generate-tools -d <tools_dir>" doesn't just work or doesn't work with --stream means we have an enterrpise problem | 17:28 |
| katco | sinzui: if that is indeed the case, then i agree | 17:30 |
| sinzui | katco: We are special though. We have lots of jujus and possibly juju-metadata plugins. I am removing everything juju juju-2.0 from my host | 17:32 |
| katco | sinzui: ah i had the dir structure wrong when i generated, retrying the bootstrap | 17:41 |
| sinzui | katco: indeed I think I did that too. I just say juju-dist/tools/tools appear | 17:42 |
| katco | sinzui: i'm still getting: 12:42:20 INFO juju.environs.bootstrap tools.go:74 found 0 packaged agent binaries | 17:43 |
| katco | sinzui: but i still don't trust my result. i have a feeling i'm doing something wrong | 17:43 |
| sinzui | katco: do you see tools/streams/v1/index2.json and does its point to a com file with the agents you have? the end agent-metadata-url you set needs to end with the "tools" | 17:44 |
| katco | sinzui: yes, the generated stuff looks correct. the url is not as you say. let me append it with the path up to and including "tools" | 17:45 |
| katco | sinzui: yay: 12:46:29 INFO juju.environs.bootstrap tools.go:74 found 1 packaged agent binaries | 17:46 |
| katco | sinzui: so i think it's working as intended? | 17:47 |
| sinzui | katco: I am getting bogus results | 17:48 |
| sinzui | katco: the com file has every puiblished agent ever, but not just the 3 agents I want in my cloud's streams | 17:49 |
| katco | sinzui: mine has just the agents i specified | 17:49 |
| katco | sinzui: when i didn't have the directory structure correct, it had every agent ever | 17:49 |
| katco | so now i have mystreams/tools/devel/*.tgz | 17:50 |
| katco | juju metadata generate-tools -d mystreams --stream devel --debug | 17:50 |
| katco | sinzui: and that works for me | 17:50 |
| sinzui | katco: This is what I did https://pastebin.canonical.com/167729/ | 17:55 |
| katco | sinzui: can you do a --debug on metadata generate-tools ? | 17:57 |
| sinzui | katco: https://pastebin.canonical.com/167730/ | 18:05 |
| sinzui | katco: per the bug, I think I can instread pass juju-dist/tools and the agents will be found, bug I get a tools/tools dir :( | 18:06 |
| katco | sinzui: i just pass the parent of tools | 18:06 |
| katco | sinzui: can you name your root something more boring? foo or something? | 18:06 |
| sinzui | katco: the debug out shows streams.canonical.com was called. the mirrors is only on that host | 18:06 |
| sinzui | katco: yes, foo it will be | 18:07 |
| katco | sinzui: and what version of juju is this? | 18:07 |
| sinzui | katco: juju version | 18:08 |
| sinzui | 2.0.0-xenial-amd64 | 18:08 |
| sinzui | ^ katco froma few hours ago | 18:08 |
| katco | sinzui: from tip? | 18:08 |
| sinzui | it was tip a few hours ago | 18:08 |
| katco | sinzui: cool, same here | 18:08 |
| sinzui | katco: you don't pass -m? | 18:09 |
| * sinzui wonders if juju is reading something like his racksapce model and deciding that streams.canonical.com is to be used | 18:10 | |
| sinzui | katco: with foo and again streams.canonical.com was used https://pastebin.canonical.com/167732/ | 18:12 |
| katco | sinzui: i get the same result you do if i don't pass a --stream | 18:12 |
| sinzui | katco: okay, I will pass --stream released | 18:12 |
| katco | sinzui: that may be the bug | 18:13 |
| sinzui | that is different :) | 18:13 |
| katco | sinzui: so that works? | 18:13 |
| sinzui | katco: yes: https://pastebin.canonical.com/167733/ | 18:14 |
| katco | sinzui: ok, and then i assume a bootstrap will work as well | 18:14 |
| sinzui | katco: I think we hit a problem with juju 1's old "releases" dir. I am going to reset and rename released => release and see if it finds the agents | 18:15 |
| sinzui | yep, . the bug is that there is a juju-1 ism in it | 18:16 |
| sinzui | katco: https://pastebin.canonical.com/167734/ shows that juju defaults/requires tools/releases, btu the help says "released" and the product file (com file) is also "released" | 18:18 |
| bodie__ | so I was just now using dlv debugger to step through an io.ReadAtLeast where len(buf) and min both were 0 | 18:24 |
| bodie__ | but once I was inside the func, printing the value of the int return value ("n") gave a result I didn't expect: 2325760 | 18:25 |
| bodie__ | can anyone help me understand how this could happen? | 18:25 |
| bodie__ | it was being called from io.ReadFull | 18:25 |
| sinzui | katco: --stream devel or beta or pting works. So I think --stream is required, not an option. Since juju assumes the stream name is "released" I think we should fix juju to look for that dir. | 18:25 |
| bodie__ | damn. this was intended for #go-nuts -- sorry! | 18:25 |
| rick_h_ | bodie__: :P | 18:26 |
| * bodie__ awkwardly takes his leave :D | 18:26 | |
| katco | sinzui: sorry got a phone call (otp) | 18:31 |
| sinzui | katco: the juju 1 docs for private cloud do wook for juju2 because it tell uses to put agents in "releases" it makes no mention of --streams. | 18:35 |
| perrito666 | is there anybody from the tech board awake? | 18:39 |
| katco | perrito666: o/ but i need to get lunch | 18:40 |
| perrito666 | katco: defer ping() | 18:40 |
| katco | perrito666: do you have a question i can mull while i lunch? | 18:40 |
| perrito666 | katco: sure, typing | 18:41 |
| katco | sinzui: can we clean up your bug to be more about the streams flag default not working? | 18:42 |
| katco | sinzui: and do you feel that represents the problem wholly? | 18:42 |
| perrito666 | our s390 build is broken because of the introduction of golang.org/x/sys/unix which requires some extra steps by hand to compile (which include cgo) I believe I might be able to remove said dependency since its used for a very small thing (calculating fs free space in a more accurate way than previously done iiuc) | 18:42 |
| perrito666 | so my question is | 18:42 |
| perrito666 | nothing is worth the pain of cgo right? | 18:43 |
| katco | perrito666: almost certainly not, but let me mull | 18:43 |
| perrito666 | katco: thanks for the shared head procesing :) | 18:43 |
| sinzui | katco: yes, I think the --streams is the extent of the issue now | 18:44 |
| sinzui | katco: I updated the bug https://bugs.launchpad.net/juju/+bug/1613858 | 19:03 |
| mup | Bug #1613858: generate-tools ignores 2.x agents and creates bad path <jujuqa> <metadata> <regression> <rteam> <simplestreams> <streams> <juju:In Progress by natefinch> <https://launchpad.net/bugs/1613858> | 19:03 |
| perrito666 | I would really appreciate a rather urgent review https://github.com/juju/juju/pull/6440 | 19:20 |
| alexisb | katco would appriciate a review on https://github.com/juju/juju/pull/6440 | 19:26 |
| thumper | perrito666: s390x fix approved | 19:30 |
| perrito666 | thumper: tx, merging | 19:30 |
| thumper | perrito666: did you test it on s390 already? | 19:30 |
| perrito666 | thumper: its a revert | 19:30 |
| thumper | ah | 19:31 |
| thumper | ok | 19:31 |
| perrito666 | thumper: that method was the way it was done before | 19:31 |
| thumper | ack | 19:31 |
| perrito666 | np | 19:31 |
| perrito666 | brb, small errand before the sky falls on our heads | 19:43 |
| rick_h_ | katco: ping, do you have a sec to fill me in on the bug update and where we go from here please? | 19:48 |
| katco | rick_h_: yep | 19:48 |
| rick_h_ | katco: meet you in standup meeting? | 19:48 |
| katco | rick_h_: ok | 19:48 |
| babbageclunk | thumper: ping | 20:11 |
| thumper | babbageclunk: hey | 20:11 |
| * thumper joins hangout | 20:11 | |
| menn0 | perrito666 (and thumper): I see you merged the change to remove the golang.org/x/sys dep | 20:15 |
| menn0 | wallyworld updated that to the latest version yesterday | 20:15 |
| menn0 | the newer version claimed to include s390x support | 20:16 |
| menn0 | we were using a rev from 2015 before | 20:16 |
| menn0 | did that not help? | 20:16 |
| wallyworld | the commit logs lied it seems :-( | 20:16 |
| menn0 | wallyworld: or it wasn't complete s390 support | 20:18 |
| menn0 | thumper: I see you hit a few intermittent test failures... I'm making sure there's bugs for them | 20:19 |
| thumper | menn0: thanks | 20:20 |
| menn0 | thumper, wallyworld: do you know why Juju prints this at bootstrap? "Launching controller instance(s) on maas2..." | 20:22 |
| menn0 | why plural on controllers? | 20:22 |
| menn0 | instances even | 20:22 |
| menn0 | is there ever a case where bootstrap will result in more than once instance | 20:23 |
| menn0 | ? | 20:23 |
| thumper | no | 20:23 |
| thumper | seems stupid | 20:23 |
| redir | looks like model-defaults is broken. when supllying a region it now complains "error: No selected controller" | 20:27 |
| alexisb | redir, we need to get on top of that | 20:30 |
| redir | :| | 20:33 |
| katco | last remaining blocker (an honor) for 2.0 need review. very simple: https://github.com/juju/juju/pull/6441 | 20:40 |
| menn0 | katco: looking | 20:41 |
| katco | menn0: ta | 20:41 |
| menn0 | katco: done. just some help tweaks. | 20:50 |
| katco | menn0: tal | 20:50 |
| perrito666 | wallyworld: menn0 the commit logs where true-ish, for support there are a set of steps required to be run | 20:51 |
| perrito666 | wallyworld: menn0 we are a bit on the edge to add all that to the build procedure | 20:51 |
| perrito666 | it depends on cgo | 20:51 |
| menn0 | perrito666: that's fine. just making sure you and wallyworld weren't tackling the same problem in different ways. | 20:52 |
| katco | menn0: addressed your comments, thanks | 21:07 |
| alexisb | menn0, when you are done with the review i am on our 1x1 HO | 21:09 |
| menn0 | katco: looks good but I noticed one minor problem. | 21:09 |
| katco | menn0: sure | 21:09 |
| menn0 | katco: oh, and you didn't do the "#" change? | 21:10 |
| katco | menn0: sorry, the "#" change? | 21:11 |
| katco | menn0: lol sorry just saw it | 21:11 |
| alexisb | so redir what command exactly is failing? | 21:11 |
| menn0 | katco: sorry, I shouldn't have mixed up 2 things in the one comment | 21:12 |
| katco | menn0: no worries should have caught that | 21:12 |
| katco | menn0: should it still be a bulleted list? or just #? | 21:12 |
| menn0 | katco: the examples for other command seem to just use "#" | 21:12 |
| katco | menn0: k i'll fix it up | 21:13 |
| katco | menn0: k try that out | 21:13 |
| redir | juju model-defaults <region> ... | 21:13 |
| redir | alexisb: ^ | 21:13 |
| alexisb | redir, looking at the help for the model-defaults I am not seeing anything about specifying regions | 21:17 |
| redir | then the help is out of date:/ | 21:17 |
| redir | it looks like something changed in modelcommand, so that now the command doesn't correctly get the current controller | 21:18 |
| === akhavr1 is now known as akhavr | ||
| redir | which appears to have changed in https://github.com/juju/juju/commit/a5f95c441ac29ed1a98c8efafbb71869ed89e7b6 | 21:19 |
| wallyworld | menn0: thumper: it prints that at bootstrap because a certain someone asked for it | 21:20 |
| thumper | pfft | 21:20 |
| redir | alexisb: it is in the Usage string but not the detailed help. | 21:21 |
| alexisb | redir, I am confused | 21:22 |
| alexisb | we should chat | 21:22 |
| alexisb | will ping whne I am done | 21:23 |
| redir | OK | 21:23 |
| redir | alexisb: ^ | 21:23 |
| === lazyPowe_ is now known as lazyPower | ||
| alexisb | redir, https://hangouts.google.com/hangouts/_/canonical.com/alexis-ian | 21:55 |
| alexisb | when you are ready | 21:56 |
| redir | brt | 21:56 |
| anastasiamac_ | katco: in ur recent charm related work, have u come accross this? https://bugs.launchpad.net/juju/+bug/1606684 | 22:03 |
| mup | Bug #1606684: upgrade-charm fails to upgrade local charm <regression> <juju:Triaged> <https://launchpad.net/bugs/1606684> | 22:03 |
| katco | rick_h_: there were failing tests | 22:03 |
| katco | anastasiamac_: tal | 22:04 |
| katco | anastasiamac_: that looks like a dupe of bug 1609463 ? | 22:05 |
| mup | Bug #1609463: upgrade-charm command is inconsistent with deploy when using local charms <2.0> <usability> <juju:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1609463> | 22:05 |
| katco | anastasiamac_: if you agree, please flag it as such | 22:06 |
| anastasiamac_ | katco: awesome :) | 22:06 |
| katco | anastasiamac_: hello btw | 22:06 |
| anastasiamac_ | katco: \o/ | 22:07 |
| anastasiamac_ | rogpeppe: wallyworld: do u know if bug 1614010 has already been addressed as part of othr movements in the area? | 22:23 |
| mup | Bug #1614010: juju register: cannot register a user when controller already exists <juju:In Progress by rogpeppe> <https://launchpad.net/bugs/1614010> | 22:23 |
| wallyworld | what do you mean by fixed? there's disagreement about what's needed. the bug comments explain it a bit | 22:26 |
| wallyworld | there was a functionality change. but there's disagreement now whether the change is for the best | 22:27 |
| anastasiamac_ | wallyworld: k. i guess i was asking whether rogpeppe has done anything in the area one way or another. nm | 22:27 |
| wallyworld | not that i know of | 22:27 |
| wallyworld | i think it' | 22:28 |
| wallyworld | s something we should discuss for 2.0.1 | 22:28 |
| wallyworld | i sort of agree with roger tbh | 22:28 |
| wallyworld | but since there's disagreement, it needs to be hashed out | 22:28 |
| anastasiamac_ | k | 22:28 |
| katco | alexisb: rick_h_: fix landed for bug 1613858... last blocker, yes? | 22:52 |
| mup | Bug #1613858: generate-tools ignores 2.x agents and creates bad path <jujuqa> <metadata> <regression> <rteam> <simplestreams> <streams> <juju:Fix Committed by cox-katherine-e> <https://launchpad.net/bugs/1613858> | 22:52 |
| alexisb | katco we found another just a minute ago wallyworld has picked up | 22:52 |
| alexisb | but katco thanks for the fix! | 22:53 |
| katco | wallyworld: wth! release blocker | 22:53 |
| katco | wallyworld: \/ | 22:53 |
| katco | alexisb: k i'm off to dinner. gl | 22:53 |
| alexisb | wallyworld, always causing trouble | 22:53 |
| katco | so true | 22:53 |
| wallyworld | there's always one more :-) | 22:53 |
| alexisb | bye and enjoy | 22:53 |
| katco | pfffbt | 22:53 |
| wallyworld | wot? me? | 22:53 |
| alexisb | redir, I gave you a task on teh release notes | 22:59 |
| redir | :) | 22:59 |
| alexisb | :) | 23:00 |
| alexisb | redir, if you get things down I will review | 23:00 |
| redir | k | 23:00 |
| alexisb | anastasiamac_, wallyworld ping | 23:16 |
| alexisb | redir, ping | 23:16 |
| wallyworld | shit sorry, was talkin g to heather | 23:18 |
| hml | alexisb: hi - do you have a date for 2.0.1? | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!