[00:06] wallyworld: ping? [00:06] yo [00:07] wallyworld: can I have a quick hangout with you regarding a bug fix? [00:08] sure, pop into tanzanite standup https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand [00:09] wallyworld: I get "trying to join the call" but it's not making it [00:09] hmm, i'll try and invite you [01:05] perrito666: you around? [01:11] bah, I need a chrome extension so I can easily filter bug lists on launchpad. [01:22] perrito666, I had to retry the build-revision job for your branch. We were getting 503's from Google's repos. [01:29] sinzui: did you see https://github.com/juju/jujusvg/pull/29 [01:29] there's an issue merging? [01:30] I was looking at that problem... there's a couple repos under github.com/juju that import charm.v6-unstable but it doesn't look like they're referenced from juju/juju [01:31] wallyworld, natefinch, yes the fix is in. We got unlucky network immediately after the fix. http://reports.vapour.ws/releases/2587/job/build-revision/attempt/2587 [01:31] I tried the build a few minutes later and all is well [01:34] sinzui: so how do we merge https://github.com/juju/jujusvg/pull/29 ? is there a bot? [01:34] wallyworld, I don't know. since perrito666's merged worked. I think everything is fixed [01:35] oh i see [01:35] wallyworld, both git-merge-juju and build-revision agree the tree matches dependencies.tsv [01:35] sinzui: i'm wanting to see how the next CI run behaves with regard to the failed HA and bundle obs [01:35] jobs [01:36] wallyworld, I think the issue is simply the underlying git use of master that caused unwanted deps to be pulled. [01:36] gad i wish the go ecosystem had better dep management [01:36] build it [01:36] buint in [01:36] fark, can't type [01:37] wallyworld, I was helping homebrew today as well. They couldn't get the right deps either. [01:37] sinzui: oh, build just failed again generating tarball [01:37] I need to follow up with them and explain why Go wasn't giving them the versions that juju was asking for. [01:38] yeah, if proper dep mgmt was built into the go ecosystem it would be a lot easier :-/ [01:38] wallyworld: if we used godep (not godeps), this wouldn't be an issue. [01:39] wallyworld: and honestly, it's only an issue because we decided we cared if there was extra stuff in our gopath. We could stop caring about that, and this "problem" would go away. [01:39] natefinch: that's still not built into the official tool set [01:40] natefinch: we must care about the extra stuff for repeatable packaging ressons [01:40] distro have rules we must follow [01:40] like with backwards compatibility [01:40] not breaking 100000000's of deployments is hard [01:40] Bug #1450631 changed: Something is injecting gopkg.in/juju/charm.v6-unstable into the tree

[01:40] wallyworld: godeps is a lot more in line with what distros would like. smash all your dependencies into one big repo. [01:41] nooooooo [01:41] not one big repo :-( [01:41] that sucks so badly [01:43] sinzui: CI builds still broken :-( [01:43] Extant directories unknown: [01:43] gopkg.in/juju/charm.v6-unstable [01:43] wow, how did perrito666 get his merge in [01:43] what did we do to try to fix that? [01:44] sinzui: which one? the 1.23 one? [01:44] oh, is it just 1.24, master, and all devel branches that are affected? [01:44] i kicked off that one earlier [01:44] just 1.24 and master yeah [01:44] i think we need that svg patch [01:44] wallyworld, I think so too :( [01:45] natefinch: i think they adjusted the imports to use gopkg and pulled in a tagged version to avoid transitively pulling in the unknown code [01:45] I'm taking a look at the CI for jujusvg. Fix should be in soon. [01:45] \o/ [01:45] ty [01:46] wallyworld, I disabled http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/build-revision/ to give us time to investigate a retest in case CI tries a new build [01:46] ok [01:47] wallyworld, If I fall a sleep, you can re-enable it. I just don't want to loose a chance to get you more daya [01:47] wallyworld: do you think it's worth getting this replicaset initialisation fix into 1.23 as well? are we doing another 1.23 release? [01:47] data [01:47] menn0: yes we are [01:47] menn0: if it's fairly straightforward, wouldn't hurt [01:48] sinzui: ok, will do ty [01:48] menn0: there's a bad upgrade bug related to the JES stuff that is being fxed for 1.23 [01:48] and 1.22 [01:48] so there will be new releases next week [01:49] gah, I hate launchpad [01:49] :-) [01:49] why? [01:49] wallyworld: ok so should I aim for 1.22 as well then? [01:49] wallyworld: what's the JES upgrade bug? [01:49] well, today, because what seems like a simple filter does bizarre things [01:50] menn0: https://bugs.launchpad.net/juju-core/+bug/1447853 [01:50] Bug #1447853: Local charms are not added to storage on upgrade to 1.22.x

1.22:Fix Committed by hduran-8>

[01:50] menn0: upgrade step to add env uuid to charms collection was done in wrong place [01:50] wallyworld: if I filter juju-core bugs by "target milestone 1.24-alpha1" ... I get 1 bug listed, even though I know there's like 30 targetted to 1.24-alpha1 [01:51] natefinch: you are filtering trunk bugs [01:51] you want https://bugs.launchpad.net/juju-core/1.24/+bugs?advanced=1 [01:52] that's why i've been complaining about people entering the milestone incorrectly [01:52] natefinch: I brought this up in the team meeting yesterday. the same think has bitten me. [01:52] it's only giving you what you ask for [01:52] natefinch: you need to select the series before doing the search [01:52] you are asking to filter bugs on the trunk series [01:52] natefinch: it's not obvious [01:52] wallyworld: when I go to https://bugs.launchpad.net/juju-core/+bugs I see a ton of bugs. Some of them are targetted to 1.24-alpha1. If I then just click advanced search and click 1.24-alpha1 .... I get 1 bug [01:53] natefinch: because those bugs have the *wrong* milestone [01:53] trunk bugs must not have a milestone intended for a different series [01:53] wallyworld: for example, this bug: https://bugs.launchpad.net/juju-core/+bug/1424892 [01:53] Bug #1424892: rsyslog-gnutls is not installed when enable-os-refresh-update is false

[01:53] wallyworld: under milestone, one of the "affects" is 1.24-alpha1 [01:54] natefinch: sure, but the url you are using is looking for trunk bugs [01:54] see the url i pasted [01:54] but it shows up in the original unfiltered list [01:55] if it shows up there, and I say, of these bugs, show me the ones with milestone 1.24-alpha1.... that one should show up... or it shouldn't show in the original unfiltered list [01:55] no, the trunk bug shows up and that just happens to be targetted to 1.24 also [01:55] this is why I hate launchpad [01:55] 1.24-aplha1 bugs show up in trunk searches because thse bugs are *wrongly* targetted [01:55] why? [01:55] you are getting what you ask for [01:55] because you have to know all the internal workings to actually use the damn product [01:56] huh, git is *much* worse [01:56] and it's not internal workings [01:56] no, I'm not. That bug is in this list. It is targeted to 1.24. I said, show me all bugs in this list that are targetted at 1.24, and it DOESN'T. [01:56] it is set up to handle development series of projects [01:56] it does [01:56] did you use the url i posted [01:56] https://bugs.launchpad.net/juju-core/1.24/+bugs?advanced=1 [01:57] you didn;t ask for what youo thought you did [01:57] you asked for all the bugs against trunk [01:57] that are also targeted to 1.24 [01:57] which that one was [01:57] by clicking the milestone? [01:57] that's not a series [01:58] natefinch, wallyworld remember that Lp is bat sh*t crazy when working with series [01:58] this is why I hate launchpad [01:58] bugs.launchpad.net/juju-core <- search only trunk [01:58] bugs.launchpad.net/juju-core/1.24 <- search only 1.24 [01:58] yes [01:58] yes [01:58] how do I search EVERYTHING? [01:58] and there is no possible way to search everything [01:58] very logical [01:58] I don't give a shit about series [01:58] damn it [01:59] natefinch, We had a plan to fix this 5 years ago, but it was killed at higher levels [01:59] * natefinch turns off launchpad rant. [01:59] natefinch: lp was designed for UDD [02:00] it fits that use case very well [02:00] or else we wouldn't have ubuntu [02:00] I am very happy that it works well for ubuntu :) [02:02] natefinch, wallyworld. It doesn't Ubuntu is saddled with a million bugs, but we know most of them don't apply because the code is gone. It is not possible to say a bug is or isn't in juju each time we open a series [02:02] sorry, It is not possible to say a bug is or isn't in *Ubuntu* each time we open a series [02:04] wallyworld, remember my scripts to chart Lp bugs. [02:05] I pulled down the entire DB of bugs so that I could properly search, but since bugs can be moved to different projects, we would see bugs freeze (because the bug was moved out the project) or bugs appear at random (because someone moved the bug into the project). It isn't possible to ask lp for change set to get the bugs for your own db [02:16] wallyworld: https://jujucharms.com/docs/devel/wip-storage [02:17] wallyworld: eh, hangouts just died.. [02:33] sinzui: I never realized that you can't search across series. There's no way to find, for example, all bugs in HA, across all series? That's amazing. [02:33] ly bad [02:38] natefinch, most project don't user series since they break search [02:38] sinzui: then why are we? [02:38] natefinch, most project just use milestone, and the don't fork trunk until they are really sure [02:39] natefinch, because juju-core keeps doing multiple series of development [02:39] sinzui: branches in VCS do not have to have anything to do with launchpad series [02:40] natefinch, Lp wont let you have 3 task to say you need to merge a fix into three branches without using 3 series [02:40] natefinch, I think core is mad to try so many lines of development. [02:41] sinzui: we really only have two - master and the release we;re trying to stabilize [02:42] natefinch, there were 3 this morning, and secretly 3 now since I need to get a 1.22.3 out [02:42] sinzui: that's two and then every old one is still in maintenance mode [02:43] shrug [02:44] anyway.... I think we should drop series in LP. I don't really care if you can't use the milestone to show it needs to be put into 1.24 and master. You can show that in other ways. Being able to FIND BUGS seems like a pretty good reason not to use series. [02:44] wallyworld, can you review this sad branch http://reviews.vapour.ws/r/1543/ [02:44] but, I gotta go. kids are waking up when they're not supposed to be [02:45] natefinch, +1 and stop forking when branches aren't close to stable. much less merging and need to track and loose work [02:45] wallyworld, can you review this sad branch http://reviews.vapour.ws/r/1543/ [02:46] looking [02:46] lgtm [02:47] thank you. [03:07] jujusvg CI: I can't get it to work against gopkg.in in my post-dinner, heavily pajama'd state. I'll be on it again in the morning. If needed before then, ping rogpeppe, mhilton, or frankban for faster response. Writing an email to the rest of the UI team about this now. [03:08] Bug #1450631 was opened: Something is injecting gopkg.in/juju/charm.v6-unstable into the tree

[03:08] mup++ [03:21] wallyworld: fix for bug 1441904 [03:21] Bug #1441904: jujud won't start if apt-get of juju-mongodb package fails

[03:21] http://reviews.vapour.ws/r/1544/ [03:21] looking ty [03:31] menn0: done [03:35] wallyworld: I see what you're saying but that might have still not worked in the situation that triggered this bug report [03:35] wallyworld: apt's cache files were corrupted due to the disk having run out previously [03:37] menn0: understood, but in the general case there may be a network error or some issue preventing a monfo update but mongo is still installed [03:37] if apt-cache fails, maybe we look for /usr/bin/mongo? [03:38] wallyworld: what about "dpkg --list juju-mongodb" instead. strace indicates that hits a much smaller set of files (the pacakge DB rather than the apt cache files) [03:38] menn0: sure, my apt foo sucks [03:38] whatever is the most reliable way [03:39] so long as juju attempts to verify that some mongo is installed [03:40] wallyworld: kk [03:48] wallyworld: I just found that after attempting to apt-get the juju mongodb package EnsureServer checks that the binary exists where it expects it [03:48] wallyworld: so it looks like we get that for free [03:49] wallyworld: although it falls back to $PATH if it can't find mongo at the location that juju-mongodb puts it [03:49] wallyworld: which seems a little crazy [03:50] wallyworld: who know which version of mongo it'll get [03:50] wallyworld: ah I see. we use a non-juju-specific monogo package for precise through saucy [03:51] menn0: yes [03:51] 2.4.6 [03:51] the juju one is 2.4.9 i think [03:51] wallyworld: so I think the PR is fine as it is. [03:52] wallyworld: if mongo really isn't installed after the apt-get attempts then EnsureServer still errors [03:52] great, thanks for checking up [03:52] that rings a bell know [03:52] now [03:52] i had forgotten that [03:52] you mean you can't remember every aspect of the codebase? [03:53] :-p [03:53] just makrk my comment as a fuck off [03:53] not *every* bit [03:53] how about "politely dropped" [03:53] ? [03:53] :) [03:53] sure :-) [03:54] ok merging now [03:55] wallyworld: do we need to JFDI even for the 1.23 and 1.24 branches? [03:55] menn0: not 1.23 [03:55] just 1.24 [03:55] wallyworld: ok [04:09] wow, disabling all providers except openstack cuts jujud size by 26MB :o [04:17] 26MB!! [04:29] Makyo: thanks! [04:29] Makyo: we can pick it up again tomorrow [04:38] Bug #1450701 was opened: Juju CLI compatibility option

[05:10] anastasiamac: your PR failed due to good old bad record MAC [05:10] anastasiamac: you should resubmit === kadams54 is now known as kadams54-away [05:26] Bug #1450706 was opened: juju-core 1.23.2 fails with an error on destroying a local environment on vivid [05:35] wallyworld: still having trouble with cinder, but it looks like it might be an infrastructure issue. the volume goes to "attaching" but never progresses. I think I'll just propose anyway [05:35] ok [05:35] i have to duck out for school pickup, will be back in a bit [05:38] Bug #1450706 changed: juju-core 1.23.2 fails with an error on destroying a local environment on vivid [05:44] Bug #1450706 was opened: juju-core 1.23.2 fails with an error on destroying a local environment on vivid [07:14] morning all - any jes folks still around? [07:15] ah rogpeppe1 you might know [07:15] rogpeppe1, actually - forget that, I'm all good [07:16] * rogpeppe1 forgets everything anyway [07:21] mattyw: i'm interested what you might want to have asked anyway [07:22] rogpeppe1, if I'm talking about sending some data from a Uniter to a State Server... I wondered if these days it's more accurate to say Uniter -> Jes? [07:22] mattyw: the two terms are equivalent [07:23] rogpeppe1, I guess so, except when folks say jes in my head I always think - one or more server, but when folks say State Server I always assume just 1 [07:23] mattyw: they're just different endpoints on the same server [07:50] wallyworld: FYI, I switched to canonistack's lcy02 region and it all worked [07:50] wallyworld: also, "juju status-history" is very handy :) [07:50] axw: awesome, just looking now [07:50] :-) [07:51] axw you're going to clash nastily with my os provider branch [07:51] axw: why define a const autoAssignedMountPoint = "" ? [07:51] mgz: i hope your demo went well? [07:52] mgz: changes to existing OS code is mostly just import changes, shouldn't be too much of a hassle [07:52] wallyworld: it stumbled a bit at the start :) [07:52] oh ? :-( [07:53] axw: right, but we did the same import change, so one of us will have the to merge and resolve [07:53] wallyworld: for self-documentation -- better than just a "" literal [07:53] wallyworld: the machine didn't come out of pending, and I waited a bit too long, [07:53] mgz: ah ok. [07:53] destroying the service and deploying again worked fine [07:54] what's the demo? [07:54] axw: ah, i see, the comment confused me but it makes sense now [07:54] wallyworld: I have a note from curtis, that I want to check with you [07:54] axw: I showed of the status-set stuff again [07:54] cool [07:55] wallyworld: as I understand it, he wants CI to build the 1.22 branch next, so it's ready to go on release when he is up [07:55] so, build-revision is currently disabled [07:55] mgz: yes, i think we can enable that job now [07:55] when the current CI test run is done, I'm going to re-enable that, with the cron set to do 1.22 first, and let that go through all our tests [07:55] mgz: he added a hack to delete the unintended source [07:56] sounds good [07:56] wallyworld: the versioning the svg thing worked for now right? [07:56] I'm going to finish a branch now to resolve deps differently that I've sat on for a while, [07:57] which is at least a stop-gap till godeps can get uncoupled from go get being silly [07:58] mgz: why can't we just use "godeps -u", then delete everything under GOPATH that doesn't existing in dependencies.tsv ? [07:58] or is that what you're going to do [07:59] that's what my branch does [08:01] I don't really *like* it, because it relies on our build/test stuff to catch dep errors more, but for juju-core at least we should break noisily if we remove a dep from the tarball if we actually require [08:04] mgz: not sure, i know curtis added a hack to delete the unexpected source dir [08:14] Bug #1450729 was opened: juju should be able to use nodes acquired by the same user in MAAS

[08:26] enabling build-revision [08:28] voidspace: can we jump in a hangout and talk more about container addressing? [08:33] mgz: when will the next 1.24 CI build trigger? [08:34] wallyworld: depends if this 1.22 goes through fine, I'm going to hold CI for it [08:34] ok [08:34] wallyworld: sinzui's message said you had debugging you needed to do on something? [08:34] dooferlad: yes, let me grab coffee first [08:34] please yell if you need a hand with anything [08:36] mgz: not really, i the quickstart issue was identifed and fixed in juju. a subsequent CI run failed, but that was because the charms simply were still installing when the CI test decided to time out. i can't see how juju is at fault off hand. so i'm curious to see another run [08:36] mgz: fwiw, a master CI run also failed with machines still being allocated when the test gave up [08:36] so maybe there's a slow cloud at work [08:39] voidspace: I am in the standup hangout [08:41] wallyworld: one thing that may be relevent on this [08:42] wallyworld: the testing expects status to be responsive - this is a user requirement [08:43] wallyworld: so, we have a timeout for the whole job, but the test will also fail if we didn't have regular feedback from status during it [08:44] dooferlad: omw [08:45] dooferlad: are you sure you're in the standup hangout? [08:45] I don't see you there... [08:45] mgz: that shouldn't be a problem, the mechanism to update status hasn't changed as such. what does the deployer do? use megawatcher and expect updates to the bacjking doc? [08:46] the same underlying db status watcher is used [08:50] Bug #1450737 was opened: provider/openstack: cinder provider should reject attempts to create non-persistent volumes

[08:50] Bug #1450740 was opened: provider/openstack: volumes are recorded with 0 size

[08:51] wallyworld: yeah, it shouldn't be anything remarkable [08:53] mgz: so maybe we do need to debug, but at least the new status actually provided good info as to what the system is doing. i also saw a bunch of config change hook errors. so something is not right [08:55] wallyworld: I'm a bit confused with the newest 1.24 and master branches... it's just too messy. I'm hoping we get bad to a sane state next week. [08:55] i hope for before then [08:56] I'm not super happy with you guys smashing stuff in with jfdi while we're trying to sort out release issues [08:57] the stuff landing is all storage, which is not used unless the charm is configured [08:57] I'm really pleased everyone has been picking up bugs and fixing them [08:57] but this has just been all over the place [08:58] the blocking bugs have been quickstart related and also a bit of networking and the quickstart thing has been fixed [08:58] in terms of quickstart was failing because juju was mis reporting status [08:58] but we can't get sane confirmation that the bug fixes are good on 1.24/master [08:58] sure, but that's not due to storage code which is unused [08:59] unkess the charm requests it [09:02] Bug #1450737 changed: provider/openstack: cinder provider should reject attempts to create non-persistent volumes

[09:02] Bug #1450740 changed: provider/openstack: volumes are recorded with 0 size

[09:08] Bug #1450737 was opened: provider/openstack: cinder provider should reject attempts to create non-persistent volumes

[09:08] Bug #1450740 was opened: provider/openstack: volumes are recorded with 0 size

[10:25] dooferlad, hey there [10:25] dooferlad, can you review http://reviews.vapour.ws/r/1549/ [11:04] is there anyone around that might be able to review a change to godeps, please? https://codereview.appspot.com/230460044 [11:04] it's a fix for a very annoying issue that's been a problem for ages [11:36] sinzui: jenkins seems idle. should it be doing a CI run? [11:36] i'd be interested to see a 1.24 run [12:23] wallyworld, I had to change CI last night to ensure I get 1.22 tested and if it failed, It had to stop so humans can learn why just a version change broken it [14:01] katco: omw .. hangout is giving me issues [14:01] wwitzel3: np [15:10] natefinch: took your tips from the ML on forward porting and put them in a doc, edits/corrections welcome. http://reviews.vapour.ws/r/1551/ [15:18] wwitzel3: awesome! Should be -m 1 for the cherry-pick though [15:18] wwitzel3: don't ask what the 1 means, I don't know, but it works :) [15:42] ericsnow: in reviewboard, can we make the pull request link be [url](url) [15:43] wwitzel3: probably :) [15:43] wwitzel3: I'll take a look [15:43] wwitzel3: that has bugged me too [15:43] ericsnow: it is only frustrating because of the double click to edit [15:43] ericsnow: so when I try to highlight the link, it awlays goes in to edit mode [15:44] ericsnow: you can tell me where the code is and I'll make a PR :) [15:45] wwitzel3: https://bitbucket.org/ericsnowcurrently/rb_webhooks_extension [15:45] wwitzel3: :) [15:53] ericsnow: you have a PR :) [15:53] wwitzel3: first one! :) [15:53] wwitzel3: thanks! [16:19] wwitzel3: thanks for doing that! I kept meaning to mention that, too. [16:46] wwitzel3, ping === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [17:43] someone needs to ban wallyworld until he can fix is IRC client [18:13] natefinch: or update yours to not show join/part? :P [18:26] Hi, where i can found more info about "juju user"?. [18:43] rick_h_: I like seeing when people join or leave the channel... it's useful information, except when people's irc clients go on the fritz and spam the damn channel. === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [19:22] ericsnow: check out github.com/natefinch/plugin [19:37] natefinch: that's pretty cool [19:38] natefinch: make sure to close the pipes in error cases in Start [19:38] ericsnow: ahh yeah, thanks. [19:39] natefinch: you're right; it is simple :) [19:39] natefinch: nice job [19:39] ericsnow: the nicest thing about it is that, aside from the resources required to run a second process, and the slight overhead of serialization, to users and developers, it works much like in-process plugins. [19:39] natefinch: yep [19:40] for devs it's just function calls. For users, they just drop the plugins in a folder and forget about them. [19:40]