[00:25] axw: when you get a chance, no rush, a small tweak to series validation. i'll then update dep in the master pr https://github.com/juju/charm/pull/198 [00:40] thumper: https://github.com/juju/juju/pull/4688 [00:41] * thumper looks [00:41] i tried a few ways yesterday to merge these two handlers into one [00:41] but as the one from api/private/server comes with a compelte implementation of a python mocking framework [00:41] it was infeasable [00:41] this is a smaller change which does the same thing [00:41] and the author of the original code will have to figure out how to merge the two types [00:45] davecheney: change looks good +1 [00:46] thumper: ta [01:13] hmm... third time today I've hit bad record mac trying to land things [01:16] wallyworld: can you meet early? [01:16] thumper: sure, give me a couple of minutes [01:16] ok [01:24] evening all [01:28] evening natefinch [01:28] natefinch: kiddo feeling any better? [01:29] katco: not really... she's only had water & pedialyte since 6pm last night, and threw up even the water just before bed tonight. But that's only #3 since 8am, so I'll take it over last night, for sure. [01:30] natefinch: jees :( [01:31] katco: my wife is slightly better off... she's managed to have, I think, two crackers, besides various liquids since around 8pm last night. Crazy bad virus. [01:32] natefinch, that sounds terrible :( [01:34] alexisb: OMG, it was horrible. We had to call our babysitter at 10pm to come help with the baby until about 3am when my wife was finally able to get off the bathroom floor and be in the bedroom. [01:35] :( [01:35] worst ever, and we've had some bad ones. [01:43] * alexisb wishes she had gofmt for 'c' in her kernel days [01:45] tiotally... man, I remember having autoformat wars at my last job... if you didn't configure your autoformatter exactly right, every time you commit your stuff, you reformatted the code to be slightly differently. Another guy on my team kept doing that... the aggravating thing was that he didn't notice, which made me really wonder if he even looked at what he was checking in. [01:47] katco: ericsnow left a comment on my charmrepo PR about this needing to get merged into the new-channels-model branch. Should I just PR this against that branch as well? ref: https://github.com/juju/charmrepo/pull/65 [01:59] katco: just landed that 3 pointer in charmrepo.v2 (master) [02:12] thumper, menn0: https://github.com/juju/juju/pull/4691 [02:12] followup from previous CL [02:12] davecheney: thumper is about to drive up to Christchurch so i'll do it [02:13] ta [02:13] this is more refactoring to remove the apisever/common dependency from the resource/api [02:13] because apiserver imports resource/api [02:13] so if I want to move apiserver/common.ServerError to apiserver [02:13] i need to break that import loop [02:14] and i want to move apiserver/common.ServerErr to apiserver to pay down the technical debt from the UpgradeInProgress refactor [02:39] menn0: ping? [02:40] cherylj: howdy [02:41] menn0: hey there, wanted to pick your brain on this mongo problem [02:41] so we had mario run mgopurge [02:41] and we told it to skip objects with an invalid token [02:42] but I was wondering... do those need to get cleaned up anyhow? [02:42] some how? [02:42] cherylj: yeah, i was going to reply to that email thread today but have been flat out [02:42] we're panicking in the same sort of way now in jujud - the token is invalid [02:43] cherylj: are the bad txn tokens in the txn-queue field? [02:43] cherylj: if so, yes they'll need to be removed. I kind thought that's what we were getting mgopurge to do but I could be misremembering [02:43] menn0: that's what I'm wondering / thinking. I haven't downloaded the db yet to look [02:43] cherylj: seems likely if that's the case [02:44] cherylj: mgo/txn will be trying to look up those txns, failing to find them and panicking [02:44] menn0: but what I added in to prevent mgopurge from panicking was just to skip those transactions [02:44] cherylj: I was going to say on the email that they should get the replicaset healthy *before* trying to fix anything else [02:44] maybe there's something else I need to add which removes them from the queue [02:45] menn0: it sounds like they've done that [02:45] cherylj: he said that 2 out of the 3 nodes are ok [02:45] cherylj: that's not healthy [02:45] cherylj: they should get that 3rd node happy again first [02:45] menn0: ah, gotcha [02:46] menn0: I can ask Mario to do that [02:47] cherylj: and it sounds like making mgopurge remove the bad txn tokens needs to happen too [02:47] cherylj: a bad/empty token should just be treated the same as a missing txn [02:47] menn0: yeah, that's what I was thinking. I'll take a closer look at the PurgeMissing code [02:47] cherylj: the same logic that removes missing txns from the txn-queue field can then be used to remove the bad ones too [02:51] bleh this mgo stuff is hard to read [03:08] natefinch: i'd say just master and they an bug us if the merge conflicts are too bad [03:20] wallyworld: charm change LGTM [03:21] tyvm === akhavr1 is now known as akhavr [03:48] wallyworld: adding cloud name, etc. to controllers.yaml doesn't really work :/ if you did "juju register", we've got nowhere to pull that information from [03:48] wallyworld: so I think it goes back into bootstrap-config.yaml, and we cross-reference that in list-controllers [03:52] axw: ok, let's go with that; we can be clear about the limitations. the only other option i guess it to make an api call [03:52] axw: is this for the provider type info? [03:53] wallyworld: IMO that's out of the question [03:53] yeah, agreed, was just making sure we covered all options [03:53] rick_h__: sorta. it's for that, plus the bits we need to kill-controller if the controller is dead [03:53] rick_h__: we could store the provider type easily, but the other information not so much [03:53] axw: ah ok, for the provider type user query I'd hope we could put that in the show-controller metadata [03:53] axw: gotcha [03:54] axw: yea, /me didn't catch the rest of the convo for the kill-controller link [03:54] rick_h__: two birds, one stone :) [03:54] axw: yea, but let's make sure they're both birds and not one moose and one bird [03:54] ;) [03:55] no thumper? curses [04:16] rick_h__: thumper is driving up to christchurch (where I live). he's taking his kids to a convention up here. [04:16] rick_h__: can I help at all? === menn0 is now known as menn0-afk [04:36] wallyworld: just thinking out loud... we could forget about storing the credential label/origin, and just auto-detect and use whatever it returns, like at bootstrap [04:37] wallyworld: and if none auto-detected, say something like "no credentials detected". I guess the origin is still useful though... [04:38] wallyworld: (just trying to minimise surface for such a corner case) [05:24] axw: sorry, was out with anastasia talking lxd image caching. yeah, we went around and around on minimising the serface for the corner case didn't we. but the idea of storing the label/origin is so that if we autodetected the wrong credentials, we could prompt for the correct ones [05:24] but is the effort worth it [05:24] wallyworld: yeah, I suppose so. I'll add it later, doing the minimal work for now to support lxd [05:25] sgtm. i don't think it's that much extra to store the label/origin, let's take a view once things have settled a bit [08:00] morning o/ [08:10] Bug #1555969 opened: API server stops responding after juju add-unit [08:21] wallyworld: if you're around later and feel like looking, here's the WIP: https://github.com/juju/juju/compare/admin-controller-model...axw:bootstrapconfig-partial-ondemand [08:22] wallyworld: all working, lots of tests to update now. [09:12] voidspace: did this (http://reviews.vapour.ws/r/3955/) get back into master? [09:13] frobware: well, the code it was changing wasn't on master I don't think [09:14] frobware: I can have a look [09:15] frobware: the subnetToSpaceIds function it changes doesn't exist on current master [09:15] frobware, hey, I've realized I gave you bad advice yesterday wrt dependencies.tsv :/ === menn0-afk is now known as menn0 [09:15] dimitern: so let's fix it before we merge to master [09:15] frobware, those imports which were removed with the master merge caused issues on windows [09:16] dimitern: I was looking at the report [09:16] frobware, yeah, I suppose just adding back the missing ones will fix 3 of the curses [09:16] dimitern: can I just merge in what I had done? [09:16] originally [09:16] fwereade__: i'm aiming to review your model agent integration PR soon [09:16] frobware, I'd try to use GOOS=windows godeps -N ... as suggested in the linked bug report [09:16] voidspace: if we're going to get maas-spaces2 into master next week we can wait till then [09:17] voidspace: I was just curious if you ported that single fix into master. I guess not because it was only broken on maas-spaces2 [09:18] frobware: right, it *couldn't* be ported to master... [09:22] dooferlad, hey, I see getMongoSpace changes caused a data race in the last CI run [09:22] dimitern: really? Grr. [09:22] dooferlad, can you have a look at that? http://reports.vapour.ws/releases/3735/job/run-unit-tests-race/attempt/1095#highlight [09:23] dimitern: on it [09:23] dooferlad, cheers [09:23] menn0, <3 [09:24] menn0, I recommend ignoring everything under worker/dependendency; core/life; and all the */lifeflag bits [09:24] menn0, because I can and will extract those [09:24] fwereade__: ok will do [09:25] frobware, in my experiments yesterday I found this quick hack significantly reduces the initial boot time: http://paste.ubuntu.com/15346394/ [09:26] frobware, ~2m (average) from allocated to deployed [09:41] dimitern: the bridge wait I understand, the ntp is a step too far... [09:43] frobware, that's because of the race I was telling you about when trying to ifup a lot of static interfaces [09:44] frobware, I was seeing 4-5 bash instances trying to run ntpdata and getting blocked on trying to create a lockfile [09:47] dimitern: I'm going to try an experiment with a one-time reboot post our butchering of eni [09:47] dimitern: but somewhat secondary to getting the devices work done [09:48] frobware, I tried that as well - depending on when you reboot, it might not work at all - e.g. before installing bridge-utils [09:48] frobware, agreed [09:48] dimitern: the bridge-utils is a pre-req so is already present before we run the script [09:49] frobware, yeah, that's assuming we got the chance to even run apt-get install bridge-utils [09:49] frobware, which will happen after the bridge script completes [09:56] dimitern: it happens the other way round. [09:56] dimitern: our script would fail catastrophically if it wasn't present [09:57] dimitern: you can see this if you deploy from MAAS, cp the script, and run it. the whole thing fails because there is no brctl [09:59] frobware, that's what I'm talking about :) [09:59] frobware, since the script runs as a bootcmd, it will run before any packages listed in the generated userdata are installed.. [09:59] dimitern: I was confused. you said "after the bridge script completes" [10:00] frobware, hmm.. I might be wrong - just observed something like that [10:01] dimitern: there is no way we could bring the interface up without bridge-utils being there [10:01] dimitern, voidspace, dooferlad: standup/planning [10:02] frobware: omw [10:51] fwereade__: review done. lots of great stuff. thank you. it will be great to get this landed. [10:53] frobware, this is the gist of what's needed: http://paste.ubuntu.com/15346665/, and those API calls follow the pattern in http://paste.ubuntu.com/15241590/ [10:53] * menn0 bed [10:55] frobware, so if we agree on the interface, I can use a stub for now, and later we integrate [10:56] frobware, let me know what you think [10:59] dimitern: will look in a bit [11:03] dimitern: I don't see a great deal of diff with your godeps incantation; https://pastebin.canonical.com/151643/ [11:05] frobware, that's exactly the missing import causing the curse [11:05] dimitern: :) yes, just read the bug. [11:06] frobware, well, now we know what this package is for :) [11:06] dimitern: so another alternative is that we merge from master again this morning [11:06] dimitern: we would get that ^^ for free [11:08] frobware, also works, and will give us updated lxd stuff as a benefit [11:08] dimitern: right, I'll do that instead. [11:09] frobware, however, that should be followed up by dooferlad's fix not long after the merge lands in order not to waste a CI run [11:09] dimitern: good point [11:13] dimitern: can we HO re: the godeps stuff again. as in what's the best way to merge and or update it [11:13] frobware, ok [11:14] frobware, I'm in the sapphire HO (last one we used) [11:55] dimitern / frobware / voidspace: http://reviews.vapour.ws/r/4132/ fixes those races. [11:57] dooferlad, looking [11:59] dooferlad, did you run the test with -race? [11:59] yes [12:00] dooferlad, so the issue is easy to reproduce and verify the fix [12:01] dooferlad, LGTM, thanks that was quick :) [12:01] dimitern: yea, just running the tests with -race showed it and then it was just a moment of "oh crumbs, that was dumb" [12:02] :) [12:02] dooferlad: we should try and land the changes close together; just running make check on my merge from master and will propose [12:02] frobware: I hit $$merge$$ about two seconds before you said that. [12:03] c'est la view [12:03] vie... [12:03] frobware: it will take some time to test, so as long as we get to reviewing your code soon we will be fine. [12:32] dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4133/ -- merge master into maas-spaces2 [12:32] frobware: did you land one yesterday? [12:32] voidspace: yes [12:32] frobware: ah yes, this one isn't as huge [12:32] frobware: go for it [12:32] voidspace: that commit was also a blessed build. [12:33] voidspace: if there's one thing to look at its dependencies.txt [12:33] voidspace: I meant dependencies.tsv [12:34] frobware: yeah, I looked - LGTM [12:34] frobware: although we seem to be depending on stuff in people's own github repositories now [12:34] frobware, looks good [12:35] dooferlad, your fix should merge cleanly onto frobware's merge PR right? [12:41] dimitern: going to grab some lunch and then let's do devices... \o/ [12:41] frobware, sweet! [13:05] dimitern, voidspace, dooferlad: both merged. we should, in theory, get a blessed CI run now. [13:07] frobware, let's hope we do :) [13:13] natefinch: ping === rogpeppe2 is now known as rogpeppe [13:31] dimitern: whenever works for you let's sync [13:31] frobware, in 15m ? [13:32] yep [14:00] frobware, let's use the standup HO? [14:01] frobware, well, last one we used anyway [14:01] ok [14:24] rogpeppe: pong [14:27] fwereade__, ping? [14:35] Bug #1556113 opened: TestCleaner should have fired by now

[14:35] Bug #1556116 opened: TestDeployBundleMachinesUnitsPlacement mismatch

[14:36] mattyw, heyhey [14:50] Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement

[14:59] ericsnow: let me know if you need help with that cards you took over from me [15:02] Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement

[15:05] Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement

[15:13] ericsnow, ping? [15:13] ericsnow, do you know if the todo comment at the top of this file is currently being worked on? https://github.com/juju/juju/blob/master/cmd/juju/charmcmd/store.go [15:14] * ericsnow takes a look [15:15] mattyw: not really [15:15] ericsnow, ok that's fine, I might have to end up doing some of it for the stuff I'm working on, wanted to make sure I wasn't going to be duplicating work [15:15] mattyw: I have a patch that accomplishes that but haven't had a chance to pursue landing it [15:16] ericsnow, i'd be interested in seeing that if possible [15:16] mattyw: k, thanks for the heads up [15:16] mattyw: looking it up as we speak [15:16] ericsnow, many thanks [15:22] mattyw: pretty sure this is the branch: https://github.com/ericsnowcurrently/juju/tree/resources-charmstore-client [15:22] mattyw: it isn't quite right at this point, but the key thing is the httpcontext package [15:23] mattyw: however, it looks like the new "charm" command would use it too, so it may make more sense in some other common repo [15:29] natefinch: #1556146 [15:29] Bug #1556146: github.com/juju/juju/resource/api undefined: parseMediaType

[15:29] natefinch: bug #1556146 [15:29] Bug #1497801 changed: provider/joyent: data races

[15:29] Bug #1461961 opened: UniterSuite teardown fails

[15:29] Bug #1556146 opened: github.com/juju/juju/resource/api undefined: parseMediaType

[15:32] ericsnow: natefinch: planning time [15:34] ericsnow, thanks, I'll take a look [15:39] Bug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace()

[15:39] Bug #1556155 opened: worker/periodicworker data race

[15:48] Bug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace()

[15:48] Bug #1556155 changed: worker/periodicworker data race

=== benji is now known as Guest47292 [16:00] Bug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace()

[16:00] Bug #1556155 opened: worker/periodicworker data race

[16:03] ericsnow: review a single character bug fix? http://reviews.vapour.ws/r/4135/diff/# [16:09] Bug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace()

[16:09] Bug # opened: 1556153, 1556157, 1556161, 1556167, 1556171 [16:31] does the Juju license is going to change? the issue is that at using a library like "juju/service", it does that all my code been AGPL [16:31] HollyRain: very doubtful that the license will change [16:33] natefinch, well, at least there is an alternative to handle services: kardianos/service [16:33] in github.com [16:36] HollyRain: if you mean github.com/juju/juju/service - anything under github.com/juju/juju is not really intended to be used as a general library [16:36] ok [16:39] Bug #1556176 opened: TestCmdLine dial unix no such file or directory

[16:39] Bug #1556180 opened: MachineSuite.TestManageModelRunsRegisteredWorkers mismatch

[16:39] Bug #1556183 opened: help text for list-controllers needs improving

[16:51] cherylj: ping [16:52] frobware: in stand up, responses will be slow :) [17:16] voidspace: you still about? [17:19] frobware: yup [17:19] voidspace: any joy with MAAS 2.0? I didn't get around to installing... [17:20] frobware: not yet, recloning my vm and installing xenial - about to install a newer version of maas (different ppa) that may fix the bug [17:20] frobware: did some diagnostic work with roaksoax and he thinks it might be fixed in this version [17:27] Bug #1556207 opened: 1.25.4: "tomb: dying" in all units

[17:30] Bug #1556207 changed: 1.25.4: "tomb: dying" in all units

[17:31] cherylj: we've made sure that maas-spaces2 is up to date w.r.t to master. if we get a clean CI build on maas-spaces2 we'd like to merge into master and continue the multi-NIC and MAAS 2.0 work elsewhere. Is master still locked down? [17:33] frobware: yes, we want to merge perrito666's machine-provisioning-status before we unblock [17:33] frobware: if your branch is ready, we can put it on the list to get shepherded in next [17:34] cherylj: waiting to see if the couple of fixes we did today give us a blessed CI run; should find out a bit later. [17:37] frobware: okay, cool. I'll keep an eye on it [17:42] Bug #1556207 opened: 1.25.4: "tomb: dying" in all units

[18:24] sinzui: hey, is this a spurious curse? http://reports.vapour.ws/releases#nate-minver [18:31] katco: maybe. The lack of bless might be because the branch makes juju less reliable. The azure arm-bundle looks interesting. I can retest it [18:32] spurious curse is the name of my goth metal band [18:32] sinzui: thanks, i would appreciate it. i don't think there should be anything in there that would cause it to be less reliable [18:32] sinzui: but appreciate your more informed opinion [18:42] Bug #1556238 opened: Missing a Juju shell [19:18] Bug #1556249 opened: help text for juju list-models needs improving

=== ericsnow is now known as ericsnow_afk [19:48] Bug #1556252 opened: help text for juju show-user needs improving

[20:15] sinzui: is juju2 the name of the binary going forward? [20:15] I noticed juju-core and juju are no longer listed and installing juju2 removes them [20:21] marcoceppi: it's a vast underworld conspiracy [20:28] well, it breaks the new charm and charm-tools command [20:28] so I'd just like to align those packages [20:29] it also means we can't install 1.25 and 2.0 sidebyside which completely kills this blog post from last week [20:29] http://marcoceppi.com/2016/03/testing-juju-without-wrecking-juju/ [20:30] oh, jk, it doesn't break juju-core, just juju-core2 [20:30] marcoceppi: I'm 99% sure that we are supposed to be able to run them side by side. WE've done a lot of work to enable that. [20:30] I'm actually okay with that [20:30] I'll jus tneed to update the packaging for charm and charm-tools [20:31] marcoceppi: I think it's juju-core and juju (the latter being juju 2) [20:31] marcoceppi: but I am certainly not the authority on these things [20:31] natefinch: I upgraded and both versions are still there, I jus tneed to update the other packaging [20:33] rick_h__, katco: charm publish --channel=stable cs:rabbit-22 --resources "foo-6 bar-3" ... this command seems to require that resource names not have spaces in them, in order to parse them in a single string like that. Do we want to start to enforce that, or should we change this to be --resource foo-3 --resource bar-6? or some third way? [20:34] natefinch: yes, separate flags to mirror deploy [20:34] natefinch: check out rick_h__ 's comment in the 1-pager [20:34] katco: awesome. I love consistency [20:34] +1 [20:39] omg I just bootstrapped lxd \o/ [20:41] marcoceppi: huzzah [20:57] katco: I kinda wish that for publish, it was --resource foo=3 --resource foo=5 ... but I understand that we're trying to make them like charm revisions, where it's part of the name [20:57] s/foo=5/bar=5 [20:58] natefinch: yeah, i prefer = as well [20:58] natefinch: but, precedent and all [21:05] natefinch: ericsnow_afk: we don't need to do a standup === ericsnow_afk is now known as ericsnow [21:05] katco: k [21:13] marco yes, juju2 is the package name. juju2 is also the name of binary. [21:13] marcoceppi: if you havw juju-core and juju2 installed, you can use alternates to switch which Juju is /usr/bin/juju [21:14] sinzui: right, it's just that juju2 removes some packages, including charm and charm-tools [21:15]