[00:00] perrito666: review done. just some small suggestions. wallyworld should probably take a look too since he's worked on status recently. [00:04] wallyworld: I've gotta run; could you shepherd those merges? [00:04] (already kicked off for 1.24 and master) === ericsnow is now known as ericsnow_afk [00:08] tx menn0 and waigani [00:08] wallyworld: [00:08] yo [00:08] wallyworld: was a thank you, but your connection problems drive my irc client mad [00:08] me too :-( [00:08] it just appears to be irc [00:09] can still refresh browser etc ok when irc disconnects [00:09] wallyworld: it is your client acting on too much lag [00:09] your lost connection thresold is too small [00:09] i'l check client config [00:10] wallyworld: in the mean time, could you clarify your first comment? [00:11] defer the legacy status calculation until after agent and workload status are set in the block below [00:11] then the special logic in the new method probably is not required [00:11] just call translate directly with the agent and workload status values [00:12] duh, ok makes sense and then if the result is error I set workload status to error, did I get it right? [00:12] that function should have been deleted I fisrt tried a more complex solution, because I like to complicate my life [00:51] 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] waigani: 1.18? [00:52] perrito666: okay === kadams54 is now known as kadams54-away [02:08] axw: revision 6 of http://reviews.vapour.ws/r/1481/ has the machine manager facade [02:14] 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] wallyworld: yes we do, we still need it for the state server list [02:15] ah, yeah, forgot about that [02:29] sinzui: you around? === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [03:01] Bug #1449822 was opened: storage: storage-detached should be storage-detaching

[03:13] Bug #1449822 changed: storage: storage-detached should be storage-detaching

[03:19] Bug #1449822 was opened: storage: storage-detached should be storage-detaching

[03:20] wallyworld: have you tested your latest change to ff removal against an older juju API server? [03:20] axw: yes [03:21] wallyworld: cool. I thought getting the API would error, rather than returning something with a 0 "best API version" [03:21] glad to be wrong === kadams54 is now known as kadams54-away [04:31] wallyworld: looking at the blockdevices upgrade PR now [04:31] ty [04:47] wallyworld: ship it with some fixes === urulama__ is now known as urulama [06:31] mornin' [07:32] morning o/ === liam_ is now known as Guest4187 [08:58] dooferlad: ping [08:59] voidspace: hi [08:59] dooferlad: hi, you better today? [08:59] ah, he's back. feeling better? [08:59] dooferlad: I assume the answer is yes as you're here :-) [08:59] voidspace: mostly :-| [09:00] voidspace, TheMue: hangout time! [09:00] omw [09:01] omw [09:11] 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:25] wallyworld: should cinder be going into 1.24? [09:26] (since it's not in tree atm) [09:27] wallyworld: should cinder be going into 1.24? [09:27] (since it's not in tree atm) [09:28] axw: yes, we do need it [09:28] wallyworld: ok, will look at getting that ready for merge next [09:28] axw: excellent, ty [09:32] wallyworld: got it, fixing that last bit now [09:32] perrito666: ty [09:33] a night's sleep does wonders [09:33] indeed [09:33] s/a night/6 hs/ [12:24] 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] however, I do feel like your proposal is better than what we have [12:26] jam: i think that consideration is largely orthogonal to the decisions we're making here [12:26] rogpeppe: it would let you decouple "params" from "charms" which would let you remove some of the crossing lines [12:27] 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:33] mgz: morning, ping? [12:35] * perrito666 would give his kingdom for more upload speed [12:35] s/speed/bw [12:36] quick question: is relation-broken the only relation hook for which $JUJU_REMOTE_UNIT is not guaranteed to be set? [12:36] fwereade: ^ [12:39] perrito666: yo [12:44] 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] Bug #1447853: Local charms are not added to storage on upgrade to 1.22.x

[12:45] perrito666: it won't happen if you bootstrapped on 1.22 because your charms will go in mongo straight off [12:46] perrito666: it will be an issue if you started on 1.21 or earlier regardless of how you're trying to upgrade [12:46] ah ok, then retrying with 1.21 [13:11] Bug #1441811 changed: juju-1.23beta3 breaks glance <-> mysql relation when glance is hosted in a container

[13:11] 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] 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

1.24:Triaged> [13:12] jam: that looks like a missing cloud images package [13:12] let me check the name [13:12] wallyworld: 500 Internal Server Error is not a good thing to be getting. [13:12] though they also couldn't include the all-machines.log because they were trying to "cat" as an unpriviledged user. [13:12] jam: cloud-image-utils needs to be installed or else the util to determine the lxc file name is missing [13:13] jam: if they have os-updates false, then juju has a bug it wont install needed packages [13:13] that bug is being fixed for 1.24 [13:13] 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] jam: i just happen to know/guess the issue [13:14] 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] if it tries to download just root.tar.gz and not a full lxc image file name, the util is missing [13:14] wallyworld: its a full name [13:14] 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] oh i see [13:14] that's just a lot to write :) [13:14] in that case, ignore what i said above [13:15] wallyworld: but that looks like it is expecting the Juju API server to have the cloud images, right? [13:15] Is that the changes you made with GridFS storage? [13:15] jam: the state server is a proxy - if it doesn't have the iages it fetches from cloudimages.ubuntu.com and caches [13:15] console.txt claims it is running juju-1.22-beta2-trusty-amd64.tgz [13:16] wallyworld: k, well its giving 500 ISE instead :) [13:16] the images are cached in gridfs yes [13:16] the logs would be useful [13:16] 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:17] wallyworld: they tried, but those files are: cat: /var/log/juju/all-machines.log: Permission denied [13:17] sudo ? [13:17] for local provider you need sudo for most things [13:17] wallyworld: + juju ssh -e maas 0 'cat /var/log/juju/all-machines.log' [13:17] oh maas [13:17] Is the "-e maas" to blame ? [13:18] don't think so, but is maas is current env, could try leaving it off [13:18] juju ssh i think supports -e [13:21] 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] on the maas node [13:25] wallyworld: so wget for 1/lxc/0 is failing [13:25] afaict there are no containers on machine-0 [13:25] so we don't see errors particularly there [13:25] wget to state server or from state server out to cloudimages? [13:26] wallyworld: wget 10.245.0.177:17070 I assume that is to state server [13:26] yes [13:26] wget is written as a bash file to tmp in order to specofy cert to use [13:27] wallyworld: yeah, there is stuff about tmp files, but the requset [13:27] the request *to* the state server causes the state server to return 500 ISE [13:28] and "juju ssh machine-0" is unable to read /var/log/juju/all-machines.log for debugging info [13:29] 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] we really need the log files, preferrable with debug on [13:30] what does juju ssh ls /var/log/juju give? [13:30] is all-machines.log missing [13:33] wallyworld: the message they got was "Permission Denied" not "no such file" [13:34] jam: that could be another issue then - if rsyslog pkg is missing, all-machines log won't be written === kadams54 is now known as kadams54-away [13:34] rsyslog-gnutls === kadams54-away is now known as kadams54 [13:35] that package is normally installed by cloud init, but not if os-updates-blah is false [13:35] that's the bug i mentioned earlier [13:38] does $$JFDI$$ not work anymore? Or did I just mess it up? [13:38] natefinch: aha, trying to jfdi [13:41] Bug #1440940 changed: xml/marshal.go:10:2: cannot find package "encoding"

[13:42] ericsnow_afk: you around? [13:45] perrito666: looks like it's $$__JDFI__$$ (but then the markup changes that to a bold JFDI) [13:48] ericsnow_afk: ping [13:48] natefinch: you know anything about systemd? [13:48] natefinch: anything would be more than me... :-) === ericsnow_afk is now known as ericsnow [13:49] voidspace: LOL I probably know less than that [13:49] natefinch: :-) [13:50] natefinch: looks like I'm stuck with hassling ericsnow ... [13:50] :) [13:50] voidspace: well, I know some of our handling of it. I just don't know systemd *itself* [13:50] voidspace: if that makes any sense :) [13:50] natefinch: right [13:50] natefinch: the question is about our handling of it, just formulating the question [13:51] voidspace: what's up? [13:51] ericsnow: I'm forward porting a networking fix from 1.23 to master (and 1.24) [13:51] ericsnow: I now have a test that fails with this error [13:51] http://pastebin.ubuntu.com/10940325/ [13:51] ericsnow: which looks like a systemd change [13:52] I have a fix for bug 1446264 in need of kindly review [13:52] Bug #1446264: joyent machines get stuck in provisioning

[13:52] ericsnow: are the two "effectively equivalent", i.e. can I just change the expected value [13:52] voidspace: lol, I read that as "port forwarding a networking fix" [13:52] sinzui: ^ you may like this [13:52] heh [13:52] ericsnow: the test specifically is TestShutdownInitCommandsSystemd [13:53] mgz, \o/ [13:53] hmmmm.... [13:53] digging into the test it looks a bit weirder [13:54] voidspace: presumably that test is checking the generated script [13:54] right [13:54] I need to get it to show the whole script [13:54] ocr: [13:55] voidspace: got it [13:56] wallyworld: did you get my email btw? [13:57] ericsnow: this is the full result [13:57] http://paste.ubuntu.com/10940405/ [13:57] it looks reasonable [13:57] the test is explicitly checking for a chmod though [13:58] voidspace: which test? === liam_ is now known as Guest38949 === kadams54 is now known as kadams54-away [13:59] container_userdata_test.go [13:59] cloudconfig/containerinit/container_userdata_test.go TestShutdownInitCommandsSystemd [14:00] mgz: ship it! [14:02] natefinch: merci [14:04] voidspace: OTP, now [14:04] ericsnow: np, I'm reading through it [14:04] ericsnow: it might be a genuine failure [14:07] yeah, it looks like there's definitely a chmod missing that the test expects, trying to work out why :-) [14:14] ericsnow: this is service/systemd/testing/writeconf.go that is expecting a "chmod 0755 " + wct.scriptname() === kadams54-away is now known as kadams54 [14:42] strange, router just went into service mode and back [14:50] ericsnow: for the systemd writeconf tests, you don't know where the "chmod 0755" is supposed to be added do you? [14:54] voidspace: check out service/systemd/conf.go [14:55] voidspace: (in normalize) [14:56] ericsnow: ah, I was grepping for chmod... that helps, thanks [14:56] voidspace: np [15:00] ericsnow: hmm... normalize does a 600 though, not an 0755 [15:00] that's on the logfile [15:00] voidspace: ah [15:01] voidspace: see service/systemd/service.go [15:01] voidspace: (in InstallCommands) [15:01] ericsnow: indeed [15:01] ericsnow: thank you [15:01] voidspace: that bit is triggered when you end up with a complex command [15:01] now to work out why that isn't being called in this code path [15:01] it is now *not* being called [15:02] and it's hard to see why this branch should change that [15:02] voidspace: I'm guessing that the command was simplified [15:02] voidspace: a short review of http://reviews.vapour.ws/r/1521/? it's a forward port of a fix done by Dimiter [15:02] the execStart of the shutdown commands is different [15:02] voidspace: exactly [15:02] TheMue: looking [15:02] TheMue: did you have to make any changes? [15:03] 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] ericsnow: right [15:03] ericsnow: but the test should handle that [15:03] ericsnow: it has the same if as the InstallCommand branch [15:04] ericsnow: for some reason they're differing [15:04] TheMue: the way reviewboard renders the diff of that PR is awful :-) [15:05] voidspace: one moment, hangout [15:09] voidspace: what does the equivalent pre-patch output look like? (equivalent to http://paste.ubuntu.com/10940405/) [15:10] ericsnow: I'll check shortly, doing a review for TheMue currently [15:10] ericsnow: but good thing to check [15:10] ericsnow: and then work out what's changed [15:10] voidspace: k [15:10] voidspace: yep [15:10] ericsnow: you've given me enough clues to actually understand the code now, which is what I lacked earlier [15:10] ericsnow: I may still hassle you yet though... :-) [15:11] voidspace: np :) [15:21] voidspace: so, back again. no, no changes, only a one to one port of Dimiters changes. but two files have moved [15:24] voidspace: oh, just read dimiters comment, have to check the commit again. hmm [15:26] Bug #1450092 was opened: juju 1.23 fails to bootstrap with upstart [15:30] voidspace: this is the right one http://reviews.vapour.ws/r/1522/ [15:30] voidspace: chosen master instead of 1.24 accidently [15:31] voidspace: now it's for the correct branch [15:39] TheMue: ok, I've been reading it on github anyway [15:40] voidspace: thx ;) [15:40] voidspace: https://github.com/juju/juju/pull/2161 [16:14] natefinch, Is this like the gccfo import encoding issue? https://github.com/golang/go/issues/10173 === kadams54 is now known as kadams54-away [16:15] ^ that uses the newer compiler that Ubuntu offered to backport [16:15] sinzui: looking [16:15] sinzui: looks like something else [16:16] natefinch: the issue with your test is it's totally bogus [16:16] you have an amd64 machine with both gccgo and golang-go installed on it [16:16] which we know works [16:16] it's a ppc machine with only gccgo on it that fails [16:16] mgz: i think we were wondering if you could run that sample program on the ci machine [16:16] katco: I did, it fails [16:16] mgz: to simplify the conversation [16:17] 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] yeah, which is called 'gccgo on ppc64el' [16:18] mgz: so can we take the next step and determine whether this is a CI env. issue, or a gccgo issue? [16:18] mgz: e.g. is there a way to run that sample program on a ppc machine with gccgo installed as normal? [16:18] I don't have a fresh ppc machine to try, but I can try to find one [16:18] mgz: I find it hard to believe that gccgo on powerpc, when properly set up, simply lacks the encoding package [16:19] mgz, natefinch I am reading all the control files for gccgo-based packages. I don't see anything different from our package [16:19] TheMue: LGTM [16:19] voidspace: thx [16:19] wwitzel3, ping [16:19] i'm out [16:19] * katco looks dangerously at her old iBook aging in the corner === kadams54-away is now known as kadams54 [16:25] katco: new tasks for old (i)books? [16:25] 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] TheMue: yeah... it makes me not feel so bad about having so many old computers around :p [16:25] katco: hehe [16:26] katco: but the ibook already has been intel, hasn't it? the powerbooks have been G4 [16:27] TheMue: i think it's a G3, but it was definitely an iBook circa 2004 [16:27] katco: compiling juju on that is going to be a blast, I'm sure. [16:27] katco: oh, long time ago [16:27] natefinch: hey, go compiles fast, right? :) [16:28] natefinch: it's not going to happen anytime soon. i'm not even sure if it boots anymore. weekend project for sometime [16:31] sinzui: do you know why my http://reports.vapour.ws/releases/2576 is empty? === Spads_ is now known as Spads [16:39] perrito666, the site can be 30 minutes behind the data that was stored for it to pick up [16:40] alexisb: pong [16:40] wwitzel3, I got what I needed thank you [16:41] sinzui: oh, tx [16:41] I am mainly curious why now the windows build is broken since I have not been even closer to what blew [16:41] perrito666, I suspect bad luck and charms in the aws bundle failure. I will try to retest [16:42] tx [16:43] 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:44] perrito666, a successful run is 90 minutes for windows [16:44] Bug #1450118 was opened: vsphere provider should use OVA instead of OVF from cloud images.

[16:45] 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:46] sinzui: tx a lot [16:48] sinzui: will you announce when trunk is open? [16:49] katco, I will, but I think CI will may do it before me. We installed the automatic unblocking rules this morning [16:49] sinzui: oh wow, it pings irc now? [16:50] katco, no, just uses Lp to send out notification about why a bug is fix released [16:51] 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] sinzui: ah gotcha [16:52] 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] natefinch, if an issue is not doable to 1.24, then let katco and alexis know to reduce scope [16:54] natefinch: yeah definitely ping me if you see things that are incomplete so we can further groom that list [16:59] 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] Bug #1392810: upgrade-juju --upload-tools, using 1.20.11, from 1.18.4 upgraded to 1.19.4 instead

[17:00] natefinch: kind of agree... not sure why an --upload-tools bug would block a release since it's a purely dev feature [17:01] sinzui: when's feature freeze and/or code freeze for 1.24? [17:02] natefinch: last friday [17:02] natefinch: ff at least [17:02] katco: ok [17:03] natefinch, regardless of the freeze, we expect some large branches to "fix" incomplete features. [17:04] sinzui: understood. I just thought I saw a feature request targeted to 1.24, which obviously won't make it in [17:06] natefinch: actually that's a great point. we have several things with the feature tag targeted to 1.24-* [17:07] sinzui: should we re-target those do you think? [17:07] katco, I do. Lets set honest expectation about what we can do [17:13] 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:14] sorry this is the bug I mean: https://bugs.launchpad.net/juju-core/1.24/+bug/1412621 [17:14] Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap

[17:14] Bug #1450129 was opened: vsphere provider is missing firewaller, networking implementations

[17:15] natefinch, that is because of Core policy. Every bug must be assigned to a series (and milestone) to track fixes and forward ports [17:16] sinzui: ok, so... where/when should that bug be fixed? It's confusing when it's assigned to two different milestones. [17:16] natefinch, By forking long before the branch was stable Juju Core agreed to do double merges fore every issue. [17:16] natefinch, Core policy is fix it in the oldest stable, then forward port to master. Master is currrently 1.25 [17:17] 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:18] natefinch, yes exactly that [17:18] 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:19] natefinch, yep, but since 1.22 and 1.23 were troubled by missing merges, the policy was set by wallyworld and alexisb. [17:20] * sinzui thinks forking later and asking features to stay in feature branches is easier for everyone [17:21] time for lunch [17:22] 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. === kadams54 is now known as kadams54-away [17:30] 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] Bug #1412621: replica set EMPTYCONFIG MAAS bootstrap

[17:31] natefinch, +1. Fix the message and let someone fix their setup! [17:31] natefinch, I really like saying the bug is not in juju [17:37] 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] Bug #1355782: Error during bootstrap: TLS handshake failed: x509: certificate signed by unknown authority

[17:40] 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. === kadams54-away is now known as kadams54 [18:24]