| menn0 | perrito666: review done. just some small suggestions. wallyworld should probably take a look too since he's worked on status recently. | 00:00 |
|---|---|---|
| ericsnow | wallyworld: I've gotta run; could you shepherd those merges? | 00:04 |
| ericsnow | (already kicked off for 1.24 and master) | 00:04 |
| === ericsnow is now known as ericsnow_afk | ||
| perrito666 | tx menn0 and waigani | 00:08 |
| perrito666 | wallyworld: | 00:08 |
| wallyworld | yo | 00:08 |
| perrito666 | wallyworld: was a thank you, but your connection problems drive my irc client mad | 00:08 |
| wallyworld | me too :-( | 00:08 |
| wallyworld | it just appears to be irc | 00:08 |
| wallyworld | can still refresh browser etc ok when irc disconnects | 00:09 |
| perrito666 | wallyworld: it is your client acting on too much lag | 00:09 |
| perrito666 | your lost connection thresold is too small | 00:09 |
| wallyworld | i'l check client config | 00:09 |
| perrito666 | wallyworld: in the mean time, could you clarify your first comment? | 00:10 |
| wallyworld | defer the legacy status calculation until after agent and workload status are set in the block below | 00:11 |
| wallyworld | then the special logic in the new method probably is not required | 00:11 |
| wallyworld | just call translate directly with the agent and workload status values | 00:11 |
| perrito666 | duh, ok makes sense and then if the result is error I set workload status to error, did I get it right? | 00:12 |
| perrito666 | that function should have been deleted I fisrt tried a more complex solution, because I like to complicate my life | 00:12 |
| waigani | wallyworld: thanks for review. I'm new to control-bucket. I was just taking the error on face value - It looked like a string that needed to be zero valued to "" instead of nil. Any tips on where to look to grok control-bucket and what it's default value should be? | 00:51 |
| perrito666 | waigani: 1.18? | 00:51 |
| waigani | perrito666: okay | 00:52 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | axw: revision 6 of http://reviews.vapour.ws/r/1481/ has the machine manager facade | 02:08 |
| wallyworld | axw: there's currently work being done to tweak the control bucket logic for ec2, but with tools and charms in storage, we don't need control buckets for new environments anymore. i'm wondering if we shouldn't just delete control bucket creation | 02:14 |
| axw | wallyworld: yes we do, we still need it for the state server list | 02:14 |
| wallyworld | ah, yeah, forgot about that | 02:15 |
| natefinch | sinzui: you around? | 02:29 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| mup | Bug #1449822 was opened: storage: storage-detached should be storage-detaching <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1449822> | 03:01 |
| mup | Bug #1449822 changed: storage: storage-detached should be storage-detaching <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1449822> | 03:13 |
| mup | Bug #1449822 was opened: storage: storage-detached should be storage-detaching <storage> <juju-core:Triaged> <https://launchpad.net/bugs/1449822> | 03:19 |
| axw | wallyworld: have you tested your latest change to ff removal against an older juju API server? | 03:20 |
| wallyworld | axw: yes | 03:20 |
| axw | wallyworld: cool. I thought getting the API would error, rather than returning something with a 0 "best API version" | 03:21 |
| axw | glad to be wrong | 03:21 |
| === kadams54 is now known as kadams54-away | ||
| menn0 | wallyworld: looking at the blockdevices upgrade PR now | 04:31 |
| wallyworld | ty | 04:31 |
| menn0 | wallyworld: ship it with some fixes | 04:47 |
| === urulama__ is now known as urulama | ||
| mgz | mornin' | 06:31 |
| TheMue | morning o/ | 07:32 |
| === liam_ is now known as Guest4187 | ||
| voidspace | dooferlad: ping | 08:58 |
| dooferlad | voidspace: hi | 08:59 |
| voidspace | dooferlad: hi, you better today? | 08:59 |
| TheMue | ah, he's back. feeling better? | 08:59 |
| voidspace | dooferlad: I assume the answer is yes as you're here :-) | 08:59 |
| dooferlad | voidspace: mostly :-| | 08:59 |
| dooferlad | voidspace, TheMue: hangout time! | 09:00 |
| TheMue | omw | 09:00 |
| voidspace | omw | 09:01 |
| Bardhi|2 | hello i am trying to deploy some services with juju but it gets stucked on allocating units and services are not deployed. i just started using juju and i am not an expert in using it and i dont know very well how it all works but i need this service up and running as soon as possible. if someone could help me i would appreciate it. thank you | 09:11 |
| axw | wallyworld: should cinder be going into 1.24? | 09:25 |
| axw | (since it's not in tree atm) | 09:26 |
| axw | <axw> wallyworld: should cinder be going into 1.24? | 09:27 |
| axw | <axw> (since it's not in tree atm) | 09:27 |
| wallyworld | axw: yes, we do need it | 09:28 |
| axw | wallyworld: ok, will look at getting that ready for merge next | 09:28 |
| wallyworld | axw: excellent, ty | 09:28 |
| perrito666 | wallyworld: got it, fixing that last bit now | 09:32 |
| wallyworld | perrito666: ty | 09:32 |
| perrito666 | a night's sleep does wonders | 09:33 |
| wallyworld | indeed | 09:33 |
| perrito666 | s/a night/6 hs/ | 09:33 |
| jam | rogpeppe: so ultimately, I feel like if we are "crossing the streams" then we have our layering and abstractions a bit wrong. Like I don't see why API Parameters would be defined in terms of model objects (params depending on charms) | 12:24 |
| jam | however, I do feel like your proposal is better than what we have | 12:24 |
| rogpeppe | jam: i think that consideration is largely orthogonal to the decisions we're making here | 12:26 |
| jam | rogpeppe: it would let you decouple "params" from "charms" which would let you remove some of the crossing lines | 12:26 |
| rogpeppe | jam: even if params didn't depend on the charm package, we'd still need to solve the cyclic issue (params has never been the problem here) | 12:27 |
| perrito666 | mgz: morning, ping? | 12:33 |
| * perrito666 would give his kingdom for more upload speed | 12:35 | |
| perrito666 | s/speed/bw | 12:35 |
| rogpeppe | quick question: is relation-broken the only relation hook for which $JUJU_REMOTE_UNIT is not guaranteed to be set? | 12:36 |
| rogpeppe | fwereade: ^ | 12:36 |
| mgz | perrito666: yo | 12:39 |
| perrito666 | mgz: do you know if this happens going from any contiguous a to b from 1.22 on? https://bugs.launchpad.net/juju-core/+bug/1447853 | 12:44 |
| mup | Bug #1447853: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged by hduran-8> <https://launchpad.net/bugs/1447853> | 12:44 |
| mgz | perrito666: it won't happen if you bootstrapped on 1.22 because your charms will go in mongo straight off | 12:45 |
| mgz | perrito666: it will be an issue if you started on 1.21 or earlier regardless of how you're trying to upgrade | 12:46 |
| perrito666 | ah ok, then retrying with 1.21 | 12:46 |
| mup | Bug #1441811 changed: juju-1.23beta3 breaks glance <-> mysql relation when glance is hosted in a container <charms> <network> <oil> <regression> <juju-core:Invalid by dooferlad> <juju-core 1.23:Fix Released by dooferlad> <https://launchpad.net/bugs/1441811> | 13:11 |
| jam | wallyworld: or axw: I'm looking at https://bugs.launchpad.net/juju-core/+bug/1410876 and it seems to be trying to download a root.tar.gz from a Juju API server. | 13:11 |
| mup | Bug #1410876: Error executing lxc-clone: lxc_container: utils.c: mkdir_p 220 Not a directory - Could not destroy snapshot %s - failed to allocate a pty; Insufficent privileges to control juju-trusty-lxc-template <lxc> <oil> <stakeholder-critical> <trusty> <juju-core:Triaged> <juju-core | 13:11 |
| mup | 1.24:Triaged> <https://launchpad.net/bugs/1410876> | 13:11 |
| wallyworld | jam: that looks like a missing cloud images package | 13:12 |
| wallyworld | let me check the name | 13:12 |
| jam | wallyworld: 500 Internal Server Error is not a good thing to be getting. | 13:12 |
| jam | though they also couldn't include the all-machines.log because they were trying to "cat" as an unpriviledged user. | 13:12 |
| wallyworld | jam: cloud-image-utils needs to be installed or else the util to determine the lxc file name is missing | 13:12 |
| wallyworld | jam: if they have os-updates false, then juju has a bug it wont install needed packages | 13:13 |
| wallyworld | that bug is being fixed for 1.24 | 13:13 |
| jam | wallyworld: what file are you looking at? I'm looking at "juju_status.yaml" and trying to parse through the agent-state-info error message. | 13:13 |
| wallyworld | jam: i just happen to know/guess the issue | 13:13 |
| jam | wallyworld: so regardless, do we give a better error than 500 ISE if you try to download a cloud image we don't have? | 13:14 |
| wallyworld | if it tries to download just root.tar.gz and not a full lxc image file name, the util is missing | 13:14 |
| jam | wallyworld: its a full name | 13:14 |
| jam | wallyworld: https://10.245.0.177:17070/environment/97640150-37d0-4356-80b1-095a39c78437/images/lxc/trusty/amd64/ubuntu-14.04-server-cloudimg-amd64-root.tar.gz; | 13:14 |
| wallyworld | oh i see | 13:14 |
| jam | that's just a lot to write :) | 13:14 |
| wallyworld | in that case, ignore what i said above | 13:14 |
| jam | wallyworld: but that looks like it is expecting the Juju API server to have the cloud images, right? | 13:15 |
| jam | Is that the changes you made with GridFS storage? | 13:15 |
| wallyworld | jam: the state server is a proxy - if it doesn't have the iages it fetches from cloudimages.ubuntu.com and caches | 13:15 |
| jam | console.txt claims it is running juju-1.22-beta2-trusty-amd64.tgz | 13:15 |
| jam | wallyworld: k, well its giving 500 ISE instead :) | 13:16 |
| wallyworld | the images are cached in gridfs yes | 13:16 |
| wallyworld | the logs would be useful | 13:16 |
| jam | wallyworld: and we don't have all-machines.log or machine-0.log to know if we're logging a real error internally. (like not being able to access cloud-images, or somesuch.) | 13:16 |
| jam | wallyworld: they tried, but those files are: cat: /var/log/juju/all-machines.log: Permission denied | 13:17 |
| wallyworld | sudo ? | 13:17 |
| wallyworld | for local provider you need sudo for most things | 13:17 |
| jam | wallyworld: + juju ssh -e maas 0 'cat /var/log/juju/all-machines.log' | 13:17 |
| wallyworld | oh maas | 13:17 |
| jam | Is the "-e maas" to blame ? | 13:17 |
| wallyworld | don't think so, but is maas is current env, could try leaving it off | 13:18 |
| wallyworld | juju ssh i think supports -e | 13:18 |
| wallyworld | jam: the lxc-clone error - that nromally happens after the image has been downloaded (via the state server). is there a tarball in /var/cache/lxc/trusty... ? | 13:21 |
| wallyworld | on the maas node | 13:21 |
| jam | wallyworld: so wget for 1/lxc/0 is failing | 13:25 |
| jam | afaict there are no containers on machine-0 | 13:25 |
| jam | so we don't see errors particularly there | 13:25 |
| wallyworld | wget to state server or from state server out to cloudimages? | 13:25 |
| jam | wallyworld: wget 10.245.0.177:17070 I assume that is to state server | 13:26 |
| wallyworld | yes | 13:26 |
| wallyworld | wget is written as a bash file to tmp in order to specofy cert to use | 13:26 |
| jam | wallyworld: yeah, there is stuff about tmp files, but the requset | 13:27 |
| jam | the request *to* the state server causes the state server to return 500 ISE | 13:27 |
| jam | and "juju ssh machine-0" is unable to read /var/log/juju/all-machines.log for debugging info | 13:28 |
| wallyworld | so it seems the secure wget is succeeding, but then the state server fails to reach out to cloudimages to fetch the tarball from there to 1. cache it, and 2. stream it back to wegt | 13:29 |
| wallyworld | we really need the log files, preferrable with debug on | 13:29 |
| wallyworld | what does juju ssh ls /var/log/juju give? | 13:30 |
| wallyworld | is all-machines.log missing | 13:30 |
| jam | wallyworld: the message they got was "Permission Denied" not "no such file" | 13:33 |
| wallyworld | jam: that could be another issue then - if rsyslog pkg is missing, all-machines log won't be written | 13:34 |
| === kadams54 is now known as kadams54-away | ||
| wallyworld | rsyslog-gnutls | 13:34 |
| === kadams54-away is now known as kadams54 | ||
| wallyworld | that package is normally installed by cloud init, but not if os-updates-blah is false | 13:35 |
| wallyworld | that's the bug i mentioned earlier | 13:35 |
| natefinch | does $$JFDI$$ not work anymore? Or did I just mess it up? | 13:38 |
| perrito666 | natefinch: aha, trying to jfdi | 13:38 |
| mup | Bug #1440940 changed: xml/marshal.go:10:2: cannot find package "encoding" <blocker> <ci> <regression> <test-failure> <juju-core:Fix Released by ericsnowcurrently> <juju-core 1.24:Fix Released by ericsnowcurrently> <juju-release-tools:In Progress by gz> <https://launchpad.net/bugs/1440940> | 13:41 |
| natefinch | ericsnow_afk: you around? | 13:42 |
| natefinch | perrito666: looks like it's $$__JDFI__$$ (but then the markup changes that to a bold JFDI) | 13:45 |
| voidspace | ericsnow_afk: ping | 13:48 |
| voidspace | natefinch: you know anything about systemd? | 13:48 |
| voidspace | natefinch: anything would be more than me... :-) | 13:48 |
| === ericsnow_afk is now known as ericsnow | ||
| natefinch | voidspace: LOL I probably know less than that | 13:49 |
| voidspace | natefinch: :-) | 13:49 |
| voidspace | natefinch: looks like I'm stuck with hassling ericsnow ... | 13:50 |
| ericsnow | :) | 13:50 |
| natefinch | voidspace: well, I know some of our handling of it. I just don't know systemd *itself* | 13:50 |
| natefinch | voidspace: if that makes any sense :) | 13:50 |
| voidspace | natefinch: right | 13:50 |
| voidspace | natefinch: the question is about our handling of it, just formulating the question | 13:50 |
| ericsnow | voidspace: what's up? | 13:51 |
| voidspace | ericsnow: I'm forward porting a networking fix from 1.23 to master (and 1.24) | 13:51 |
| voidspace | ericsnow: I now have a test that fails with this error | 13:51 |
| voidspace | http://pastebin.ubuntu.com/10940325/ | 13:51 |
| voidspace | ericsnow: which looks like a systemd change | 13:51 |
| mgz | I have a fix for bug 1446264 in need of kindly review | 13:52 |
| mup | Bug #1446264: joyent machines get stuck in provisioning <bootstrap> <joyent-provider> <reliability> <repeatability> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1446264> | 13:52 |
| voidspace | ericsnow: are the two "effectively equivalent", i.e. can I just change the expected value | 13:52 |
| natefinch | voidspace: lol, I read that as "port forwarding a networking fix" | 13:52 |
| mgz | sinzui: ^ you may like this | 13:52 |
| voidspace | heh | 13:52 |
| voidspace | ericsnow: the test specifically is TestShutdownInitCommandsSystemd | 13:52 |
| sinzui | mgz, \o/ | 13:53 |
| voidspace | hmmmm.... | 13:53 |
| voidspace | digging into the test it looks a bit weirder | 13:53 |
| ericsnow | voidspace: presumably that test is checking the generated script | 13:54 |
| voidspace | right | 13:54 |
| voidspace | I need to get it to show the whole script | 13:54 |
| mgz | ocr: <http://reviews.vapour.ws/r/1519/> | 13:54 |
| ericsnow | voidspace: got it | 13:55 |
| mgz | wallyworld: did you get my email btw? | 13:56 |
| voidspace | ericsnow: this is the full result | 13:57 |
| voidspace | http://paste.ubuntu.com/10940405/ | 13:57 |
| voidspace | it looks reasonable | 13:57 |
| voidspace | the test is explicitly checking for a chmod though | 13:57 |
| ericsnow | voidspace: which test? | 13:58 |
| === liam_ is now known as Guest38949 | ||
| === kadams54 is now known as kadams54-away | ||
| voidspace | container_userdata_test.go | 13:59 |
| voidspace | cloudconfig/containerinit/container_userdata_test.go TestShutdownInitCommandsSystemd | 13:59 |
| natefinch | mgz: ship it! | 14:00 |
| mgz | natefinch: merci | 14:02 |
| ericsnow | voidspace: OTP, now | 14:04 |
| voidspace | ericsnow: np, I'm reading through it | 14:04 |
| voidspace | ericsnow: it might be a genuine failure | 14:04 |
| voidspace | yeah, it looks like there's definitely a chmod missing that the test expects, trying to work out why :-) | 14:07 |
| voidspace | ericsnow: this is service/systemd/testing/writeconf.go that is expecting a "chmod 0755 " + wct.scriptname() | 14:14 |
| === kadams54-away is now known as kadams54 | ||
| TheMue | strange, router just went into service mode and back | 14:42 |
| voidspace | ericsnow: for the systemd writeconf tests, you don't know where the "chmod 0755" is supposed to be added do you? | 14:50 |
| ericsnow | voidspace: check out service/systemd/conf.go | 14:54 |
| ericsnow | voidspace: (in normalize) | 14:55 |
| voidspace | ericsnow: ah, I was grepping for chmod... that helps, thanks | 14:56 |
| ericsnow | voidspace: np | 14:56 |
| voidspace | ericsnow: hmm... normalize does a 600 though, not an 0755 | 15:00 |
| voidspace | that's on the logfile | 15:00 |
| ericsnow | voidspace: ah | 15:00 |
| ericsnow | voidspace: see service/systemd/service.go | 15:01 |
| ericsnow | voidspace: (in InstallCommands) | 15:01 |
| voidspace | ericsnow: indeed | 15:01 |
| voidspace | ericsnow: thank you | 15:01 |
| ericsnow | voidspace: that bit is triggered when you end up with a complex command | 15:01 |
| voidspace | now to work out why that isn't being called in this code path | 15:01 |
| voidspace | it is now *not* being called | 15:01 |
| voidspace | and it's hard to see why this branch should change that | 15:02 |
| ericsnow | voidspace: I'm guessing that the command was simplified | 15:02 |
| TheMue | voidspace: a short review of http://reviews.vapour.ws/r/1521/? it's a forward port of a fix done by Dimiter | 15:02 |
| voidspace | the execStart of the shutdown commands is different | 15:02 |
| ericsnow | voidspace: exactly | 15:02 |
| voidspace | TheMue: looking | 15:02 |
| voidspace | TheMue: did you have to make any changes? | 15:02 |
| ericsnow | voidspace: if the command is complex, it gets written out to a script and the path to the script is set to ExecStart | 15:03 |
| voidspace | ericsnow: right | 15:03 |
| voidspace | ericsnow: but the test should handle that | 15:03 |
| voidspace | ericsnow: it has the same if as the InstallCommand branch | 15:03 |
| voidspace | ericsnow: for some reason they're differing | 15:04 |
| voidspace | TheMue: the way reviewboard renders the diff of that PR is awful :-) | 15:04 |
| TheMue | voidspace: one moment, hangout | 15:05 |
| ericsnow | voidspace: what does the equivalent pre-patch output look like? (equivalent to http://paste.ubuntu.com/10940405/) | 15:09 |
| voidspace | ericsnow: I'll check shortly, doing a review for TheMue currently | 15:10 |
| voidspace | ericsnow: but good thing to check | 15:10 |
| voidspace | ericsnow: and then work out what's changed | 15:10 |
| ericsnow | voidspace: k | 15:10 |
| ericsnow | voidspace: yep | 15:10 |
| voidspace | ericsnow: you've given me enough clues to actually understand the code now, which is what I lacked earlier | 15:10 |
| voidspace | ericsnow: I may still hassle you yet though... :-) | 15:10 |
| ericsnow | voidspace: np :) | 15:11 |
| TheMue | voidspace: so, back again. no, no changes, only a one to one port of Dimiters changes. but two files have moved | 15:21 |
| TheMue | voidspace: oh, just read dimiters comment, have to check the commit again. hmm | 15:24 |
| mup | Bug #1450092 was opened: juju 1.23 fails to bootstrap with upstart <juju-core:New> <https://launchpad.net/bugs/1450092> | 15:26 |
| TheMue | voidspace: this is the right one http://reviews.vapour.ws/r/1522/ | 15:30 |
| TheMue | voidspace: chosen master instead of 1.24 accidently | 15:30 |
| TheMue | voidspace: now it's for the correct branch | 15:31 |
| voidspace | TheMue: ok, I've been reading it on github anyway | 15:39 |
| TheMue | voidspace: thx ;) | 15:40 |
| TheMue | voidspace: https://github.com/juju/juju/pull/2161 | 15:40 |
| sinzui | natefinch, Is this like the gccfo import encoding issue? https://github.com/golang/go/issues/10173 | 16:14 |
| === kadams54 is now known as kadams54-away | ||
| sinzui | ^ that uses the newer compiler that Ubuntu offered to backport | 16:15 |
| natefinch | sinzui: looking | 16:15 |
| mgz | sinzui: looks like something else | 16:15 |
| mgz | natefinch: the issue with your test is it's totally bogus | 16:16 |
| mgz | you have an amd64 machine with both gccgo and golang-go installed on it | 16:16 |
| mgz | which we know works | 16:16 |
| mgz | it's a ppc machine with only gccgo on it that fails | 16:16 |
| katco | mgz: i think we were wondering if you could run that sample program on the ci machine | 16:16 |
| mgz | katco: I did, it fails | 16:16 |
| katco | mgz: to simplify the conversation | 16:16 |
| natefinch | mgz: that's sort of my point.... the *code* is valid. There's a problem with the environment in which the code is run on that machine. | 16:17 |
| mgz | yeah, which is called 'gccgo on ppc64el' | 16:17 |
| katco | mgz: so can we take the next step and determine whether this is a CI env. issue, or a gccgo issue? | 16:18 |
| katco | mgz: e.g. is there a way to run that sample program on a ppc machine with gccgo installed as normal? | 16:18 |
| mgz | I don't have a fresh ppc machine to try, but I can try to find one | 16:18 |
| natefinch | mgz: I find it hard to believe that gccgo on powerpc, when properly set up, simply lacks the encoding package | 16:18 |
| sinzui | mgz, natefinch I am reading all the control files for gccgo-based packages. I don't see anything different from our package | 16:19 |
| voidspace | TheMue: LGTM | 16:19 |
| TheMue | voidspace: thx | 16:19 |
| alexisb | wwitzel3, ping | 16:19 |
| mgz | i'm out | 16:19 |
| * katco looks dangerously at her old iBook aging in the corner | 16:19 | |
| === kadams54-away is now known as kadams54 | ||
| TheMue | katco: new tasks for old (i)books? | 16:25 |
| natefinch | encoding/json imports the encoding package.... and we import json in juju, so there's definitely some code that is referencing "encoding" indirectly already... but there is notably no other code importing "encoding" directly. | 16:25 |
| katco | TheMue: yeah... it makes me not feel so bad about having so many old computers around :p | 16:25 |
| TheMue | katco: hehe | 16:25 |
| TheMue | katco: but the ibook already has been intel, hasn't it? the powerbooks have been G4 | 16:26 |
| katco | TheMue: i think it's a G3, but it was definitely an iBook circa 2004 | 16:27 |
| natefinch | katco: compiling juju on that is going to be a blast, I'm sure. | 16:27 |
| TheMue | katco: oh, long time ago | 16:27 |
| katco | natefinch: hey, go compiles fast, right? :) | 16:27 |
| katco | natefinch: it's not going to happen anytime soon. i'm not even sure if it boots anymore. weekend project for sometime | 16:28 |
| perrito666 | sinzui: do you know why my http://reports.vapour.ws/releases/2576 is empty? | 16:31 |
| === Spads_ is now known as Spads | ||
| sinzui | perrito666, the site can be 30 minutes behind the data that was stored for it to pick up | 16:39 |
| wwitzel3 | alexisb: pong | 16:40 |
| alexisb | wwitzel3, I got what I needed thank you | 16:40 |
| perrito666 | sinzui: oh, tx | 16:41 |
| perrito666 | I am mainly curious why now the windows build is broken since I have not been even closer to what blew | 16:41 |
| sinzui | perrito666, I suspect bad luck and charms in the aws bundle failure. I will try to retest | 16:41 |
| perrito666 | tx | 16:42 |
| sinzui | perrito666, it was a panic. Since we know this test should pass in 1.24, I will increase the reties. It was set to 1 when we knew it wouldn't pass | 16:43 |
| sinzui | perrito666, a successful run is 90 minutes for windows | 16:44 |
| mup | Bug #1450118 was opened: vsphere provider should use OVA instead of OVF from cloud images. <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1450118> | 16:44 |
| sinzui | perrito666, I don't think there is anything for you to look at. I will whip CI to give a success, or concrete failure results | 16:45 |
| perrito666 | sinzui: tx a lot | 16:46 |
| katco | sinzui: will you announce when trunk is open? | 16:48 |
| sinzui | katco, I will, but I think CI will may do it before me. We installed the automatic unblocking rules this morning | 16:49 |
| katco | sinzui: oh wow, it pings irc now? | 16:49 |
| sinzui | katco, no, just uses Lp to send out notification about why a bug is fix released | 16:50 |
| natefinch | sinzui: are all the bugs assigned to 1.24-alpha1 required to be fixed for 1.24? Some of them don't seem like they're in a state to be fixed | 16:51 |
| katco | sinzui: ah gotcha | 16:51 |
| sinzui | natefinch, I cannot say. when we decided to fork 1.24 from master, all the bugs that said they had to be fixed for the milestone got a new task | 16:52 |
| sinzui | natefinch, if an issue is not doable to 1.24, then let katco and alexis know to reduce scope | 16:52 |
| katco | natefinch: yeah definitely ping me if you see things that are incomplete so we can further groom that list | 16:54 |
| natefinch | katco: I doubt this one will ever be understood, certainly it's not fixable on any kind of a short timeline: https://bugs.launchpad.net/juju-core/1.24/+bug/1392810 | 16:59 |
| mup | Bug #1392810: upgrade-juju --upload-tools, using 1.20.11, from 1.18.4 upgraded to 1.19.4 instead <canonical-bootstack> <canonical-is> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1392810> | 16:59 |
| katco | natefinch: kind of agree... not sure why an --upload-tools bug would block a release since it's a purely dev feature | 17:00 |
| natefinch | sinzui: when's feature freeze and/or code freeze for 1.24? | 17:01 |
| katco | natefinch: last friday | 17:02 |
| katco | natefinch: ff at least | 17:02 |
| natefinch | katco: ok | 17:02 |
| sinzui | natefinch, regardless of the freeze, we expect some large branches to "fix" incomplete features. | 17:03 |
| natefinch | sinzui: understood. I just thought I saw a feature request targeted to 1.24, which obviously won't make it in | 17:04 |
| katco | natefinch: actually that's a great point. we have several things with the feature tag targeted to 1.24-* | 17:06 |
| katco | sinzui: should we re-target those do you think? | 17:07 |
| sinzui | katco, I do. Lets set honest expectation about what we can do | 17:07 |
| natefinch | sinzui: I keep seeing bugs like this one that say at the bottom "Changed in juju-core: milestone: 1.24-alpha1 → 1.25.0" but they're still assigned to 1.24-alpha1 as well... are they supposed to be in both? | 17:13 |
| natefinch | sorry this is the bug I mean: https://bugs.launchpad.net/juju-core/1.24/+bug/1412621 | 17:14 |
| mup | Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <bootstrap> <maas-provider> <mongodb> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621> | 17:14 |
| mup | Bug #1450129 was opened: vsphere provider is missing firewaller, networking implementations <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1450129> | 17:14 |
| sinzui | natefinch, that is because of Core policy. Every bug must be assigned to a series (and milestone) to track fixes and forward ports | 17:15 |
| natefinch | sinzui: ok, so... where/when should that bug be fixed? It's confusing when it's assigned to two different milestones. | 17:16 |
| sinzui | natefinch, By forking long before the branch was stable Juju Core agreed to do double merges fore every issue. | 17:16 |
| sinzui | natefinch, Core policy is fix it in the oldest stable, then forward port to master. Master is currrently 1.25 | 17:16 |
| natefinch | sinzui: ok, so 1.25 and 1.24 just means 1.24 (and of course make sure it's fixed in trunk as well) | 17:17 |
| sinzui | natefinch, yes exactly that | 17:18 |
| natefinch | sinzui: still doesn't seem like it needs to actually say "1.25" on the bug anywhere. The "also put in master" should be implied. | 17:18 |
| sinzui | natefinch, yep, but since 1.22 and 1.23 were troubled by missing merges, the policy was set by wallyworld and alexisb. | 17:19 |
| * sinzui thinks forking later and asking features to stay in feature branches is easier for everyone | 17:20 | |
| katco | time for lunch | 17:21 |
| natefinch | I don't, because then it's pig-pile on master once the fork is cut, and whoever gets in last gets a merging nightmare of epic proprotions. By cutting the branch early, work can be ongoing on master and everyone can happily merge incrementally rather than in one hellish lump. Most things that go in after the branch is cut should be relatively small, in theory. | 17:22 |
| === kadams54 is now known as kadams54-away | ||
| natefinch | sinzui: this bug appears to be mainly a DNS problem in their MAAS setup, not really a juju problem, other than we might be able to improve some error messages: https://bugs.launchpad.net/juju-core/1.24/+bug/1412621 | 17:30 |
| mup | Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap <bootstrap> <maas-provider> <mongodb> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1412621> | 17:30 |
| sinzui | natefinch, +1. Fix the message and let someone fix their setup! | 17:31 |
| sinzui | natefinch, I really like saying the bug is not in juju | 17:31 |
| natefinch | sinzui: this one really sounds like it's a maas/networking issue, not really juju: https://bugs.launchpad.net/juju-core/1.24/+bug/1355782 | 17:37 |
| mup | Bug #1355782: Error during bootstrap: TLS handshake failed: x509: certificate signed by unknown authority <bootstrap> <cloud-installer> <landscape> <oil> <juju-core:Triaged> <juju-core 1.24:Triaged> <MAAS:New> <https://launchpad.net/bugs/1355782> | 17:37 |
| sinzui | natefinch, I and others agree, but I think we need to prove that. Maybe mark it Incomplete and ask for the information needed to confirm the origin. | 17:40 |
| === kadams54-away is now known as kadams54 | ||
| mup | Bug #1450146 was opened: vsphere provider feature flag should apply only to bootstrap <juju-core:In Progress by ericsnowcurrently> <juju-core 1.24:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1450146> | 18:24 |
| sinzui | perrito666, We can now see http://reports.vapour.ws/releases/2576 | 19:02 |
| sinzui | perrito666, There are two failures that suspiciously align with addressable containers on maas and aws. We are retesting. maybe the maas 1.7 is ill | 19:04 |
| perrito666 | sinzui: tx, why are there keyboard interrupts in the logs? | 19:04 |
| sinzui | perrito666, We know that 1.23 passed these tests before and after the feature flag. Ans we know the aws fix that went into 1.23 has nto yet merged into 1.24 and master | 19:04 |
| sinzui | perrito666, timeouts. we try to make tests pass quickly instead of let you wait 5 bours for results | 19:05 |
| perrito666 | sinzui: k, Ill be checking for new builds, the errors do seem alien to the previous problem | 19:05 |
| sinzui | perrito666, in aws the bundle completes between 13 and 17 minutes, with a 30 minutes timeout. I am testing a 45 minute timeout now | 19:06 |
| perrito666 | iirc, 372 secons here | 19:06 |
| perrito666 | the bundle you provided against aws | 19:06 |
| sinzui | perrito666, since errors are in the aws containers. I am inclined to escalate the bug that has a fix and mark you bug as fix released. master and 1.24 and blocked, but maybe a merge is only a hour away | 19:27 |
| perrito666 | sinzui: I would wait until your EOD arrives | 19:27 |
| perrito666 | but in principle, the problem seems to be adifferent bug, which might have been there all the time but masked by this other issue, | 19:29 |
| === kadams54 is now known as kadams54-away | ||
| perrito666 | dont you love when everybody you need to ask a question to is in the other side of the globe? | 19:42 |
| natefinch | perrito666: yep, sucks. | 19:43 |
| sinzui | katco, wallyworld: I believe that perrito666's Megawatcher fix is good, but aws and maas are still broken. 1.24 and master are still blocked. I escalated bug 1442801 which appears to be the aws issue and has an unmerged fix available | 19:52 |
| mup | Bug #1442801: aws containers are broken in 1.23 <blocker> <ci> <deployer> <ec2-provider> <lxc> <regression> <juju-core:In Progress by dooferlad> <juju-core 1.23:Fix Released by dooferlad> <juju-core 1.24:Triaged by dooferlad> <https://launchpad.net/bugs/1442801> | 19:52 |
| katco | sinzui: ty | 19:53 |
| sinzui | katco, wallyworld : We are still looking into the maas, failure, hoping it is a substrate issue, not juju | 19:53 |
| katco | sinzui: fix for 1442801 just hasn't been forward ported to v1.24? | 19:59 |
| katco | am i reading that right? | 19:59 |
| sinzui | katco, that is my reading too | 19:59 |
| natefinch | sinzui: is this even really a bug anymore? https://bugs.launchpad.net/juju-core/1.24/+bug/1442719 it sounds like it was just a problem of using an old version of juju that didn't support windows, so we had to do some rigamarole to do the upgrade. | 20:00 |
| mup | Bug #1442719: juju sync-tools fails <sync-tools> <windows> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1442719> | 20:00 |
| katco | oh my goodness... seen in a SetUpSuite(...): cmd := exec.Command("go", "build", "github.com/juju/juju/cmd/jujud") | 20:22 |
| perrito666 | yup, the comment above is fantastic | 20:23 |
| katco | yeah lol | 20:23 |
| natefinch | heh.... I should have figured it was the uniter tests | 20:25 |
| katco | that is a new one for me | 20:25 |
| katco | performing a compile... in a test... | 20:26 |
| katco | https://www.youtube.com/watch?v=6nSKkwzwdW4 | 20:26 |
| mup | Bug #1450191 was opened: quickstart cannot talk juju on maas 1.7 <api> <blocker> <ci> <quickstart> <regression> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1450191> | 20:30 |
| perrito666 | yay new bug | 20:30 |
| natefinch | katco, sinzui: this bug appears to be "juju upgrade-juju fails when the disk is full" ... which does not seem to be something we should really care about fixing: https://bugs.launchpad.net/juju-core/1.24/+bug/1441913 | 20:32 |
| mup | Bug #1441913: juju upgrade-juju failed to configure mongodb replicasets <canonical-is> <mongodb> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1441913> | 20:32 |
| sinzui | natefinch, *reliability* Juju needs to make a sensible decision when it doesn't have resources to justify starting an upgrade | 20:33 |
| katco | i can get behind that | 20:35 |
| sinzui | Mongo burned its bridges with me when it filled the disk with db and logs for two different deployments. | 20:36 |
| natefinch | I gotta run, kids are crazy, wife is sick. I think that's valid, but that's true of every action we'd try to do | 20:36 |
| alexisb | natefinch, quality software is ... ? | 20:37 |
| alexisb | natefinch, but go take care of your family first | 20:37 |
| natefinch | alexisb: yes... I am just looking for return on investment | 20:37 |
| katco | alexisb: we can talk about this on the release call, but nate brought up a great point in that we're past the FF for v1.24, and we should move all new features out past 1.24 | 20:38 |
| * perrito666 calls his isp to negotiate more upload and runs scared | 20:38 | |
| katco | alexisb: not sure if this is a feature or not :) | 20:38 |
| alexisb | yes there can be a fine line between features and bugs, that is fine | 20:38 |
| alexisb | but we need to be careful to not ignore robustness issues | 20:39 |
| alexisb | it is important | 20:39 |
| katco | absolutely it is important | 20:39 |
| alexisb | juju is awesome because it is so powerful | 20:39 |
| alexisb | but ... | 20:39 |
| perrito666 | robustnes is a feature in terms of adding new failure vectors | 20:39 |
| alexisb | anyhow we can chat about it on the release call | 20:40 |
| katco | perrito666: that is a great way of putting that | 20:41 |
| wwitzel3 | bugs are just incomplete features ;) | 20:42 |
| perrito666 | wwitzel3: lol | 20:42 |
| perrito666 | wwitzel3: software is like an infinite surface of minesweeper :p | 20:43 |
| wwitzel3 | perrito666: any every time you you don't hit a mine, it is just the number 8 | 20:44 |
| perrito666 | hehe | 20:44 |
| * katco now knows what wwitzel3 really does during the day | 20:45 | |
| wwitzel3 | vimsweeper | 20:46 |
| wwitzel3 | I wonder if that is a thing? | 20:46 |
| katco | you can bet in emacs it is | 20:46 |
| katco | i know emacs has tetris... | 20:46 |
| katco | our kanban is so useful. it's quite plain to see something is wrong by how all of our bug fixes are blocked. | 20:47 |
| katco | 1 liner up for grabs: http://reviews.vapour.ws/r/1523/ | 20:48 |
| perrito666 | wwitzel3: all it takes for something to come to existence in vim is for someone to wonder if its a thing. | 20:50 |
| katco | ugh. i really need to take a weekend and set up a bunch of environments that i can use for triaging bugs | 20:51 |
| perrito666 | mmpfh,is alt f2 not present in unity for vivid? | 20:52 |
| katco | how do i disconnect from an lxc console? C-a q isn't working | 20:59 |
| sinzui | katco, control-d? | 21:00 |
| katco | sinzui: nah that just dumps me back to the login prompt | 21:00 |
| sinzui | katco, stop the container from another session, then start the container with -n so you can ssh into it | 21:02 |
| katco | sinzui: yeah, just wondering how to exit its jail since i always forget to daemonize it | 21:02 |
| sinzui | katco, C-a q is correct. I doubt those keys are remapped for you. | 21:03 |
| katco | sinzui: not working... wondering if its because it's for a machine i'm sshed into | 21:04 |
| perrito666 | katco: ca aq | 21:10 |
| perrito666 | katco: you seem to be suffering of double shell with the same escape clause | 21:11 |
| katco | perrito666: tried that as well =/ | 21:11 |
| perrito666 | used to bite me in screen all the time | 21:11 |
| perrito666 | tried C-a ? | 21:11 |
| katco | yeah C-a a q | 21:12 |
| katco | C-a q | 21:12 |
| perrito666 | why in the universe is there no preview in launchpad comments | 21:13 |
| perrito666 | is there any kind of formatting on the comments? | 21:14 |
| katco | perrito666: there is, but i haven't taken the time to figure out what it is | 21:15 |
| perrito666 | it has quite a user foe approach | 21:15 |
| perrito666 | sinzui: ? | 21:15 |
| sinzui | perrito666, no formatting supported. It was designed 10 years ago | 21:16 |
| perrito666 | sinzui: damn, if only software was updateable... | 21:16 |
| sinzui | perrito666, I use lots of new lines and many comments honour leading spaces | 21:16 |
| sinzui | perrito666, If It was I would jump ship to tear down the bug, blueprint, and question trackers | 21:17 |
| katco | wow i'm impressed... my old ibook booted right up. G4 1.07GHz with 768Mb ram | 21:17 |
| katco | apparently i took really good care of this | 21:17 |
| perrito666 | katco: apple did | 21:18 |
| perrito666 | :p | 21:18 |
| katco | lol | 21:18 |
| katco | i do love apple hardware | 21:18 |
| perrito666 | ibook g4s where white thinkpads | 21:18 |
| perrito666 | the ibook g4 was my all time favorite machine, I almost cried when I replaced it | 21:18 |
| katco | yeah it was my college machine after some crappy compaq gave up the ghost | 21:19 |
| katco | i scrimped and saved for it... good investment. | 21:19 |
| katco | haha... how i know it's old: in my browser history: google reader | 21:19 |
| sinzui | katco, My daugher might want to buy your old computer. Her favourite marble game doesn't play on the intel Macs | 21:19 |
| katco | sinzui: i am toying with the idea of turning this into a build slave | 21:20 |
| sinzui | katco Power7 and power8 isn't going to help | 21:20 |
| katco | oh =/ | 21:21 |
| sinzui | katco, Ubuntu desupported PPC years ago. P8 is different, more than just the switch in endianess | 21:21 |
| perrito666 | debian might, but iirc, by the time I sold the thing the only os running smoothly was osx.. Tiger? | 21:26 |
| katco | i think this is running mtn. lion | 21:27 |
| perrito666 | katco: does it run ok with less than 1g? | 21:27 |
| katco | seems to | 21:27 |
| katco | i mean i'm mostly on the terminal, but safari is doing ok | 21:27 |
| katco | it's a really old version of safari though... i think i'd have to install FF or something if i wanted to browse seriously | 21:28 |
| sinzui | katco, The community is made trusty for G4 http://cdimage.ubuntu.com/releases/14.04/release/ | 21:29 |
| katco | if anything the original HD is what slows me down the most | 21:29 |
| katco | sinzui: well, no point if i can't use it to test juju | 21:29 |
| sinzui | katco: true | 21:29 |
| sinzui | katco, Our current ppc64el machines will be removed in a few months. One option for QA and Core is to use Canonistack, which might get two power8 machines | 21:30 |
| menn0 | /wii alexisb | 21:31 |
| alexisb | heya menn0 | 21:32 |
| katco | sinzui: http://juju-ci.vapour.ws:8080/job/github-merge-juju/2966/ has been running for 5h41m? | 22:04 |
| sinzui | katco, wow, let me look | 22:05 |
| katco | sinzui: it looks like it might be the new functionality | 22:05 |
| katco | check-blockers.py or w/e | 22:05 |
| sinzui | katco, yes it is | 22:05 |
| sinzui | katco, oops, it is waiting for human input. I will have this fixed ina few minutes, but I will need ti resubmit this for the victim | 22:07 |
| katco | sinzui: np | 22:07 |
| perrito666 | waigani: ping | 22:21 |
| waigani | perrito666: pong (or did you mean wallyworld?) | 22:22 |
| perrito666 | nope, you | 22:23 |
| perrito666 | waigani: https://github.com/juju/juju/commit/45f84f50 is it possible that the step you add in steps121.go was meant for steps122.go? | 22:23 |
| perrito666 | I know its an old patch, but its worth trying | 22:24 |
| perrito666 | waigani: we will know in like 20 mins anyway :p the test is running with the change applied | 22:25 |
| waigani | perrito666: cool, reading / remembering. There where a few cases we found where the same upgrade step had to be run for 1.21 and 1.22 - due to the timing of tweaks and releases | 22:26 |
| waigani | perrito666: so if it does pass, I wouldn't remove it from 1.21, but also add it to 1.22. Does that make sense? | 22:27 |
| perrito666 | waigani: the thing is, that patch, and I might be wrong, is not merged into 1.21 | 22:27 |
| waigani | perrito666: ah | 22:28 |
| perrito666 | I am right | 22:28 |
| perrito666 | https://github.com/juju/juju/blob/1.21/upgrades/steps121.go | 22:28 |
| perrito666 | My guess, the merging got pushed | 22:28 |
| perrito666 | and it entered after 1.21 cut | 22:28 |
| waigani | right, it would make sense for a 1.21 upgrade step to be on 1.21 | 22:30 |
| waigani | perrito666: shall I can merge that back into 1.21? | 22:30 |
| perrito666 | waigani: mm, I am not sure | 22:31 |
| perrito666 | ask sinzui | 22:31 |
| perrito666 | btw, kudos on the commit it is very concise it made discovering the issue quite easy when I figured out where it was | 22:31 |
| waigani | thanks :) at least I make my issues obvious ;) | 22:32 |
| perrito666 | waigani: anyway, it is, I think, causing https://bugs.launchpad.net/juju-core/+bug/1447853 so I might fix it as part of that once I learn in which versions we want that applied | 22:35 |
| waigani | perrito666: so you're running tests on 1.23 with the upgrade test targeting 1.22 instead of 1.21? | 22:35 |
| mup | Bug #1447853: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:In Progress by hduran-8> <https://launchpad.net/bugs/1447853> | 22:35 |
| perrito666 | indeed, it was | 22:35 |
| perrito666 | waigani: the thing is, all upgrade paths are broken because of that | 22:36 |
| waigani | perrito666: okay, well if the tests pass, definitely add it as a 1.22 upgrade step | 22:37 |
| perrito666 | sinzui: please let me know where can this patch be applied, 1.22, 23 and 24? | 22:37 |
| perrito666 | waigani: cheers, thanks a lot | 22:38 |
| waigani | perrito666: actually, I don't think we need to backport to 1.21. All the charm id changes are in the same PR as the upgrade step - intended to hit 1.21 but ended up in 1.22 | 22:39 |
| alexisb | anastasiamac, ping | 22:48 |
| waigani | wallyworld: I've reverted http://reviews.vapour.ws/r/1512/ to my original PR. could you take a look at my last comment which explains why and let me know if that makes sense? | 23:37 |
| wallyworld | waigani: i'm not sure it's correct | 23:42 |
| wallyworld | if cBucket, ok := attrs["control-bucket"]; !ok <--- this will not result in ok = true if control bucket defaults to "" | 23:43 |
| wallyworld | hence the control bucket will not be generated | 23:43 |
| waigani | wallyworld: yep, that's what I was thinking and it's why I put that logic in. But the TestPrepareInsertsUniqueControlBucket passes without the logic | 23:45 |
| wallyworld | so the test is wrong | 23:45 |
| wallyworld | :-) | 23:45 |
| wallyworld | maybe | 23:45 |
| wallyworld | haven't looked | 23:45 |
| wallyworld | i bet if you test live it would fail | 23:46 |
| waigani | wallyworld: openstack also works like this. It looks like the configDefaults are used for validating unknown attrs - let me track down where the config used in prepare is being build | 23:47 |
| waigani | wallyworld: I'll test live too | 23:47 |
| sinzui | perrito666, 1.24 and 1.25 per the bug. 1.22 is dead to me. 1.23 is doable, though we are not committing to a 1.23.3 | 23:52 |
| sinzui | waigani, we cannot release 1.22 fixes though our PPAs because the version is superseded by 1.23.2. We can merge a fix into 1.23 for 1.23.3, but we are not commiting to a 1.23.3 at this time. | 23:55 |
| waigani | sinzui: okay. How do we resolve this bug then: https://bugs.launchpad.net/juju-core/+bug/1447853, we need to add an upgrade step to 1.22 to fix it? | 23:59 |
| mup | Bug #1447853: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:In Progress by hduran-8> <https://launchpad.net/bugs/1447853> | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!