[00:11] its the checker that does reflective stuff, ill try [00:18] axw, made an update to the TB call, let me know if that time sitll works [00:26] * perrito666 loves git squash [00:34] squash perito666 +1 [01:00] wallyworld: did you see https://github.com/juju/juju/pull/5341/files#diff-0ceede1328e8e268f09822be9fc4cf5fR70 ? [01:01] perrito666: one sec, otp [01:02] alexisb: sorry went to take charlotte to school. that time is fine for me [01:06] see you tomorrow juju-dev [01:18] wallyworld: ping me when you are !otp [01:19] perrito666: yo [01:20] wallyworld: yo? [01:21] perrito666: a colloquial term for "hello" or "i'm here" [01:21] ah, also means I in spanish [01:21] wallyworld: the link I passed, did you see that before asking for ernonnilless? (or you meanth something else?) [01:22] didn't see the link [01:23] perrito666: which link? [01:23] https://github.com/juju/juju/pull/5341/files#diff-0ceede1328e8e268f09822be9fc4cf5fR70 [01:24] perrito666: oh, didn't see that [01:24] * perrito666 clicks fixed [01:24] we want jc.ErrorIsNil though right? [01:24] we do, actually [01:24] I wonder I used isnil [01:25] errorisnil covers some corner cases [01:25] let me try with errorisnil [01:26] wallyworld: the code got dizzy with everything we tried and I forgot to errorisnil that [01:26] np [01:26] ... value *params.Error = [01:26] ... value of (*params.Error) is nil, but a typed nil [01:26] meh [01:26] that is a fine example of a useless error message [01:28] ah its the apiserver [01:29] its a params.Error [01:36] well fine people, I need sleep [01:36] see you all tomorrow [02:13] fuck [02:13] fuckity fuck [02:13] * thumper composes email... === natefinch-afk is now known as natefinch [02:20] wallyworld, menn0: see email for WTF moment [02:20] looking [02:20] ok [02:23] thumper: +1 from me on fixing [02:23] wallyworld: I may quickly whip up a branch that cleans this up [02:24] the idea of a unique index on something that can be empty is werid [02:24] wierd [02:24] weird [02:24] ? [02:24] one of those [02:25] thumper: isn't the issue though that the providerid isn't necessarily known in this case? [02:25] does sparse mean ignore empty? [02:25] thumper: nil values aren't stored in sparse indexes [02:25] ok [02:25] thumper: the index doesn't include documents where the indexed value is nil [02:27] thumper, wallyworld: I don't know what the behaviour is when you have a compound sparse index [02:28] docs are here: https://docs.mongodb.org/manual/core/index-sparse/#sparse-compound-indexes [02:28] but I don't know what they mean by "ascending/descending index keys" [02:29] Sparse compound indexes that only contain ascending/descending index keys will index a document as long as the document contains at least one of the keys. [02:29] axw: that bug you linked to in the mail about os.Exit in a test.... that test should just return unless you somehow have JUJU_WANT_HELPER_PROCESS set in the environment [02:29] yeah [02:29] natefinch: it does not. [02:29] natefinch: it calls Main, and Main is calling os.Exit [02:29] natefinch: Main should return rc, and main should call os.Exit [02:29] which is what I'm changing it to do now [02:30] axw: I explicitly changed main *not* to os.exit [02:30] axw: maybe that change got overridden somehow [02:30] er Main that is [02:31] natefinch: blame says the line is unchanged since 2014 *shrug* [02:31] menn0: perhaps we should be doing the provider unique check in a different way [02:31] axw: weird, maybe I reverted it by accident.. [02:31] thumper: I think we should.... I'm replying to the thread now [02:31] thanks [02:33] Bug #1578456 opened: cmd/juju/commands: not all tests are being run [02:34] axw: you're right, I don't see it. That's so weird. [02:35] axw: oh crap, here it is: https://github.com/juju/juju/pull/5250 [02:35] natefinch: heh :) [02:36] axw: mind if I land mine? it has some better testing in it, too [02:36] natefinch: fine with me, but I think you'll have some ssh/scp tests to fix too [02:36] natefinch: I've just run with my changes, and there's some test failures [02:36] axw: blech [02:37] natefinch: if you like I can press on, and you can land over the top [02:37] should be mostly the same anyway, apart from your other changes [02:37] axw: fine by me [02:38] axw: sorry to make you waste time debugging that. [02:39] natefinch: no worries, didn't take long to track down. I was mostly concerned about the tests being skipped, but thankfully there's just a couple of small ones broken [02:40] ugh, my writing has become atrocious, constantly missing words out [02:40] axw: who needs words [02:40] you know... [02:40] thingy [02:40] * axw beams thoughts [02:41] menn0: bugger [02:41] menn0: migration fails... [02:41] for spaces with a provider set [02:41] github.com/juju/juju/state/spaces.go:141: ProviderId "provider" not unique [02:41] so I'm not sure it is actually working... [02:42] thumper: nuts [02:42] * thumper pokes and adds a bucket of logging [02:44] ha [02:44] it isn't the import [02:44] but the factory creation [02:44] WTF [02:48] menn0: ok, need help [02:48] got a minute? [02:48] I *think* what I'm doing should work [02:48] but it isn't [02:49] thumper: 1:1? [02:49] ack [03:04] spontaneous shutdown is one way to get me to update my kernel [03:06] lol [03:09] what is supposed to happen if you juju deploy trusty/ubuntu --series xenial? :/ [03:13] menn0: where is the manifold for the apiserver [03:13] ? [03:13] why do we even have a --series on deploy? isn't that what the foo/bar format is for? [03:14] thumper: that's one fo the things that jesse was working on but I don't think it's done yet [03:14] oh fark... [03:15] thumper: I believe he got it mostly working but there were issues, or he had to wait for some other stuff to land or something [03:15] * thumper nods [03:15] we probably want that landed very soon [03:15] definitely pre 2.0 [03:16] * menn0 checks jesse's repo [03:17] thumper: here it is: https://github.com/waigani/juju/tree/MADE-apiserver [03:18] natefinch: --series is for multi-series charms. we're moving away from "ubuntu/trusty", to plain old "ubuntu" [03:18] natefinch: and IIRC you should be able to force charms to series of the same OS by using --series, wallyworld will remember better tho [03:18] thumper: I can take a look at that once this SSH stuff is done [03:19] menn0: ok, that's be good [03:19] axw: --series and --force if needed [03:19] axw: it just means we have two different ways of specifying the same thing... which is confusing and in this case, causing a bug [03:19] thumper: it's migrations related anyway [03:19] eg if a charn declares it supports trusty and we want to install on xenial [03:19] menn0: it is [03:19] juju deploy precise/ubuntu will deploy ubuntu on xenial [03:20] menn0: how many changes to you have in cmd/juju/commands/scp.go? I'm looking at moving off JujuConnSuite, and using a mock API [03:20] menn0: don't want to make your life difficult tho [03:20] the expectation is those series specific urls are not going to be necessary, but in the interim, that charm should go to precise [03:21] axw: i've made extensive changes to the tests so it would be good if you waited [03:21] menn0: okey dokey [03:21] axw: I'm hoping to be done with it today [03:21] I can fix that, of course, but then we still have the case of juju deploy precise/ubuntu --series xenial.... I guess at that point I just have to error out, since I don't actually know what the user wants [03:21] menn0: can you please test them in isolation, because I found TestSCPCommand fails atm if you run it with others [03:21] menn0: actually I can fix that later if need be [03:21] never mind [03:21] natefinch: no, in that case you require --force [03:22] and yeah, error if --force is not provided [03:22] wallyworld: well, asking the charmstore for precise/ubuntu returns you the multi-series ubuntu charm [03:22] it does yes [03:22] wallyworld: which can deploy to xenial just fine [03:23] those series/charm urls are for backwards compatibility [03:23] ...so right now, it does [03:23] natefinch: but the user has specified precise in the url - it they want --series xenial we need --force [03:23] axw: by "in isolation" do you mean just run the individual suites? [03:24] if they specify the charm without series in url, that's different [03:24] menn0: actually I had arse about, so forget I said anything :) I'm finding that the scp tests fail because the output includes identity files from the fake juju home, and that's not expected in the output. running TestSCPCommand passes if I run it by itself [03:24] menn0: so it seems to not be getting a clean fake home [03:25] axw: hmmm... I haven't noticed that [03:25] menn0: I'll fix that and forget about changing scp for now [03:25] menn0: well, cmd/juju/commands doesn't run all the tests atm. have you changed that in your branch? [03:25] menn0: i.e. because of the bug I sent to the list [03:25] axw: no I haven't changed that, just the ssh, scp and debug-hooks tests and implementations [03:26] ok [03:26] axw: yeah I saw that [03:26] axw: but i've been running the individual tests/suites using -gocheck.f [03:26] axw: did you fix that problem already? [03:26] menn0: nope, still looking into it [03:27] menn0: I'll fix that and come back to removing JujuConnSuite after you land your changes [03:27] axw: ok thanks [03:36] axw: one wrinkle, I can't land this stuff until master is unblocked [03:36] menn0: it's cool, no hurry [05:14] axw: if someone is use juju scp/ssh to an arbitrary hostname or address, do you think the users personal known_hosts should be used, or just /dev/null ? [05:14] axw: e.g. "juju ssh 10.1.2.3", as opposed to "juju ssh 3" [09:04] fwereade: o/ [09:05] fwereade: lts PR was backport to 1.25... should we forward sugestions to master once the PR is ready? [09:16] dimitern, http://reviews.vapour.ws/r/4772/diff/1/?file=346652#file346652line93 [09:17] anastasiamac, ooh, yes please, that would be great [09:17] anastasiamac, sorry I missed that [09:18] fwereade: thank you. I'll add it to the comment so that Reed keeps track of it :D [10:55] fwereade: would you kindly take a look at http://reviews.vapour.ws/r/4776/? fixes one of the critical blockers [10:59] axw, ack [11:00] axw, LGTM [11:00] fwereade: cheers === dooferlad_ is now known as dooferlad [12:58] dimitern, http://reviews.vapour.ws/r/4734/ looks good but undertested [12:59] * fwereade bbiab [14:11] Bug #1577798 opened: Juju gives unhelpful error when azure out of resource groups

[14:33] http://paste.ubuntu.com/16239197/ [14:33] any reason it's looking for lxdbr0 on make install? [14:47] aisrael: ping [14:47] rick_h_: pong [14:48] aisrael: got a sec for hangout please? [14:48] rick_h_: absolutely [14:51] tych0: see pr #5300 - sinzui make the makefile work on a fresh install. yeah, you get kipple in your case, but the install still works, no? [14:59] mgz: it does, it's just weird [15:03] tych0: suggestions on making it less weird welcome [15:03] mgz: yep :) [15:05] tych0: l104 of Makefile - using ifconfig lxdbr0 to find out if the networking is setup, is the cause of the stderr output [15:06] I guess just a 2>&1 would do but maybe there's something smarter [15:07] oh, right [15:07] because make executes the if statements when parsing the file [15:08] mgz: yeah, that seems reasonable to me, do you want to send a patch or should I? [15:08] tych0: go for it [15:09] mgz: ok, will do, thanks [15:10] mgz: https://github.com/juju/juju/pull/5349 [15:13] tych0: lgtm [15:13] tested the change locally as well [15:13] mgz: cool, thanks [15:17] mgz: does your LGTM mean that i can $$merge$$? id on't know much about the process here still [15:18] tych0: yes, you can [15:18] and yeah, it's not super clear :) (I didn stamp on the review site) [15:18] hm, though, might be blocking bugs at present [15:18] lets see [15:19] tych0: yeah, like a million [15:20] mgz: ha, ok :0 [15:20] :) [15:59] Bug #1578337 changed: no command to remove controllers [16:02] Bug #1578337 opened: no command to remove controllers [16:05] fwereade: thanks for the review on http://reviews.vapour.ws/r/4734/ btw! [16:06] fwereade: if you're still about, I'm pushing some updates, including the missing tests and will also tackle your suggestions [16:09] dimitern, cool, thanks [16:09] fwereade: I'll ping you in the next 30m or so for a final look, while I finish a few more live tests [16:11] Bug #1578337 changed: no command to remove controllers [16:16] fwereade: do you have thoughts on what should happen if someone does juju deploy precise/ubuntu --series xenial? Should it depend on whether or not ubuntu is a multiseries charm or not? If it's not a multiseries charm, it's pretty clear that this should fail without --force, but if it is a multiseries charm, precise/ubuntu really is the same charm as xenial/ubuntu, so should we let it deploy to xenial without --force, or enforce regularity in [16:16] the CLI even though --force is not technically needed? [16:17] also welcome anyone else's thoughts on this. I'm not really sure I know what the right answer is. I feel like, either way, we're going to annoy someone [16:18] I guess, if we're going to annoy people either way, we might as well make it consistent, and require --force. [16:19] * natefinch rubber ducks with the channel as a whole. [16:19] natefinch, ha -- it feels to me like the user is explicitly specifying a charm, and explicitly specifying a series; and expecting us to resolve the charm, discover that it's multiseries and xenial is supported, and do what they told us to [16:19] natefinch, if it's not multiseries, --force for sure, but I don't think we should need it if they're doing something sane in an unorthodox fashion [16:20] fwereade: I just have a feeling that it would feel weird that juju deploy precise/ubuntu --series xenial would work, but juju deploy precise/mysql --series xenial would not [16:21] natefinch, I think of "precise/ubuntu" as a charm selector [16:22] fwereade: to the user, it's different behavior based on invisible information [16:22] natefinch, that's always been the underlying intent: what the user types is input to a specific component that resolves an *actual* charm, and we then proceed purely on the basis of the charm we found: it feels odd to me to attach additional weight to the selector, just to make something fail [16:24] natefinch, deploying "precise/ubuntu" to machines with two different series is, I think, a clear way of specifying that you want the exact charm in both places [16:24] natefinch, it's not an unreasonable request [16:24] natefinch, it will succeed or fail based on the charm in either case [16:24] fwereade: right, but, to an end user, sometimes it'll magically work, and sometimes it'll magically require --force [16:25] fwereade: I guess that's ok, since working indicates that it's supposed to be ok there, and not working indicates it may well explode [16:26] natefinch, I think so, yeah [16:26] natefinch, and if they *really* want to try it they can always --force [16:26] fwereade: I think that makes sense... it does give the user extra information that "hey this might break" whereas with a multjseries charm we can say "hey, this should work" [16:27] natefinch, exactly, yeah [16:28] fwereade: cool. thanks for helping me talk it out :) [16:28] natefinch, always a pleasure :) === freyes_ is now known as freyes__ === freyes__ is now known as freyes [17:23] alexisb, ping [17:25] niedbalski, ping [17:25] ericsnow, https://bugs.launchpad.net/juju-core/+bug/1514874 I am seeing this now with 1.25.5, juju is uninstalling after rebooting the units/state. [17:25] Bug #1514874: Invalid entity name or password error, causes Juju to uninstall [17:29] ericsnow, I think that even if 'returned during API open: invalid entity name or password' is a valid cause, throwing a ErrTerminateAgent exception is an over-reaction, instead of putting the connect-try in a loop and log a warn/fatal error. [17:30] niedbalski: OTP [17:32] niedbalski: I thought we had taken care of that [17:47] perrito666, I thought the same, but that's probably only on 2.0 [17:48] niedbalski: I am pretty sure we fixed that around 1.21 [17:48] the last time that bit someone was in 1.18, for reference se PS4 [17:48] niedbalski: taking a look [17:49] perrito666, which specific bug? [17:49] * perrito666 clicks what niedbalskilinked to see what exactly are we talking about [17:53] fwereade: still around? [17:53] perrito666, well, with 1.25.5 it's quite easy to reproduce; edit the agent.conf of the unit, change the apipassword, and restart. Now it seems that some other condition can be causing this same behavior. [17:54] alexisb: what command you working on flattening currently? block? [17:54] niedbalski: that smells strongly like a regression [17:54] redir, yep [17:54] the others are all yours [17:54] and i am happy to meet and discuss if you like [17:54] I should know, I have broken agent.conf in very creative ways with restore and juju never uninstalled [17:54] katco, ping [17:54] alexisb: pong [17:54] perrito666, I just did it, wiped. [17:55] alexisb: sorry was eating lunch earlier. responded to you email [17:55] * perrito666 scratches chin [17:55] niedbalski: is this behavior also present in 2.0? [17:55] katco, np, I see the response now thank you [17:55] katco, we are going to want to jump on that bug right away [17:55] alexisb: ah, that was 13:00 today? [17:55] alexisb: I'm looking through https://github.com/juju/juju/pull/5240/files to see how you tackled it. [17:56] perrito666, I can check. [17:56] niedbalski: if you say yes I am very much about to ring a hughe alarm [17:56] alexisb: kk [17:57] redir, once I am done with my upcoming call we should probably chat, I probably can save you some time [17:57] natefinch, briefly [17:58] fwereade: along the same lines as before juju deploy precise/ubuntu currently deploys to xenial, since the selected charm says xenial is best [17:58] fwereade: bug or feature? [17:58] anyone who's around, I don't quite have time to look at dimitern's branch but the only thing blocking an LGTM was a lack of unit testing -- I am happy with the code [17:58] natefinch, ha [17:59] natefinch, that *does* rather seem to break the law of least surprise, doesn't it :-/ [17:59] fwereade: I actually kind of wish precise/ubuntu wouldn't resolve anymore if ubuntu is a multiseries charm [17:59] yeah [17:59] fwereade: thanks! I'm doing a final live test after adding concrete errors as discussed (it was surprisingly hard to do outside of the errors package and still get the same effect) [18:00] natefinch, the most DWIMmy thing I can think of is to use features of the selector as tie-breakers when the user hasn't otherwise specified [18:01] fwereade: that seems fair [18:01] natefinch, cool [18:01] fwereade: cool, thanks [18:02] dimitern, hard to do as single error values? [18:02] core team meeting anyone? [18:02] natefinch, ...dammit, I can't really :( need to get supper [18:02] fwereade: well, that would've been a lot simpler, but I wanted to preserve the error stack and the usual way of tracing/annotating [18:03] fwereade: totally understood :) [18:03] dimitern, fair enough, but I think once you've understood the situation well enough to pick a specific error the rest of the context is less interesting and can probably be dropped [18:03] regardless :) [18:04] * fwereade gtg [18:08] so anybody coming to the team meeting? [18:13] alexisb: OK. [18:13] on the team meeting [18:18] alexisb, fwereade, also OCRs, etc: http://reviews.vapour.ws/r/4734/ is ready and tested well enough to get approval and land I think, which will fix bug 1321442 [18:18] Bug #1321442: Juju does not support EC2 with no default VPC

[18:29] redir: btw - http://juju.fail/ will give you the state blocked release branches [18:34] redir, I am available when you are [18:36] Bug #1501398 changed: Test suite failures with WSARecv timeout

[18:36] Bug #1570883 changed: imageSuite.TestEnsureImageExistsCallbackIncludesSourceURL fails on centos go 1.6

[18:36] Bug #1578254 changed: Race in apiserver/common and apiserver/proxyupdater

[18:41] natefinch, starving his family [18:55] redir, I am going to step out for a bit for lunch, I will ping you when I am back [18:55] alexisb: me too and I'll be back. [18:57] sinzui: should bug 1571914 and so on actually be blockers? [18:57] Bug #1571914: github.com/juju/juju/cmd/jujud unit tests fail if xenial is the LTS

[18:57] we hacked around the failures, but holding up the branch from landing seems perverse [18:58] mgz: I will make a exception for the LTS fixes. We are running our of time to land those before my hack fails [18:59] sinzui: is it really an exception? [18:59] without the hack, it would be failing tests, which would block [18:59] so, I think redir should land, and we should remove the hack [19:00] mgz: yes, that is what I mean. [19:00] $$fixes-1571914$$ [19:02] ericsnow, any idea? [19:03] niedbalski: just about to add a lengthy comment to the bug [19:03] ericsnow, thanks. [19:10] niedbalski: done; hope that helps [19:21] mgz that didn't work against master [19:21] redir: let me double check [19:22] redir: I see, only marked as 'high' against master, fixing now [19:22] redir: go again [19:33] alexisb, http://reviews.vapour.ws/r/4734/ LGTM, none of my issues should block landing [19:33] * fwereade disappears again [20:15] ericsnow: natefinch: we need to chat rq [20:15] katco: kk [20:15] natefinch: moonstone [20:33] fwereade, awesome thank you [20:33] redir, I am back and ready when you are [20:38] k [20:38] alexisb: gimme 5 [21:11] sinzui: the s390x /tmp issue is all sorted yes? [21:11] redir: yes it is [21:11] tx [21:13] alexisb: there's no cards in leankit for these command updates are there? [21:14] alexisb: what about launchpad? [21:14] redir, no [21:14] and no [21:14] k [21:14] redir, probably worth adding a card to tanzinite board for this [21:14] gx [21:14] tx [21:14] OK will do alexisb [21:21] mgz: can you pass me that link for maas images again? [21:24] perrito666: wiki.cloudbase.it/maas [21:25] tx [21:35] * perrito666 kicks his maas until it works [21:45] bogdanteleaga: ping? [21:51] Bug #1578834 opened: update-alternatives fails to switch between juju-1 and juju-2 [21:54] curiosity, cannot run qemu and vbox at the same time [21:56] wallyworld: is 1:1 going to happen? [21:56] perrito666: yeah, finishing a qa meeting, and also just need to ensure another clash won't happen, will ping in a sec [21:57] k [22:52] menn0: sorry for piking last night, I hope my notes were at least helpful. did you talk about remote lxd / untrusted users vs. profiles at all? [22:52] axw: np. your notes were very helpful. [22:53] axw: we didn't talk about the lxd profiles item much, but the one pager for it is on my plate now. [22:53] axw: can we perhaps talk about it on monday? [22:53] menn0: yep, no worries [22:53] axw: i'm a bit pushed for time today [22:54] menn0: np, just wondering if it came up that's all. we can talk later [22:54] (it only occurred to me while I was writing notes :)) [22:54] axw: to be honest, before I saw your notes about it I thought it was only about the lxd provider. I wasn't think about remote lxd containers. [22:55] axw: one thing which was mentioned last night is the Will was pretty sure placement directives were the right way to go. [22:55] menn0: it may be, but I meant lxd provider targeting a remote host, not lxd containers [22:55]