[00:00] i removed the tabular text bit as all user commands like that are tabular [00:00] no need to mention it every time imho [00:01] wallyworld: LGTM. just needs a line wrapping fix. [00:01] ta [00:01] damn, i meant to delete that bit [00:04] alrigty all I am off for the day [00:07] thumper or wallyworld: https://github.com/juju/juju/pull/6398 [00:13] looking [00:15] menn0: Ugh - I can't get my watcher to see a model I create in my test. [00:16] babbageclunk: stink [00:16] babbageclunk: do you want me to look at the code? [00:17] menn0: Yes please! just pushing it now. [00:19] menn0: After I create a new model here: https://github.com/juju/juju/commit/94f48e609342c26c494c36155fb0df21608f3624#diff-6734d4932d3aead490d5ec768a7df6b7R519 [00:20] menn0: I never see it logged in the changes from here: https://github.com/juju/juju/commit/94f48e609342c26c494c36155fb0df21608f3624#diff-19f910c28876da8a8d94937e102b2ebeR686 [00:20] menn0: More importantly, I never see it die after the model.Destroy. [00:22] menn0: your pr looks really nice [00:23] wallyworld: cheers... I got a bit obsessive :) [00:23] that is a good thing :-) [00:30] babbageclunk: i've been digging for a bit [00:30] babbageclunk: what you've got looks reasonable [00:30] still loooking [00:30] also looking [00:30] :) [00:31] Thanks! [00:32] I think I need to go to bed - maybe it'll be obvious (later) in the morning. [00:32] menn0: ^ [00:32] babbageclunk: ok, i'll email if I see anything [00:32] babbageclunk: good night [00:33] night! [00:33] * babbageclunk craches [00:33] ugh [00:33] dumb fingers [01:09] wallyworld or axw: are the status values shown under machine-status in the yaml status output provider specific? [01:10] wallyworld/axw: never mind I figured it out. they're not. [01:20] menn0: we map provider specific codes onto those generic status values [01:24] wallyworld: yep thanks. I figured out immediately after asking [01:46] wallyworld: needs more tests, but PTAL and I'll follow up tomorrow: https://github.com/juju/juju/pull/6399 [01:46] or axw ^ [01:46] ok [01:48] wallyworld: expect typos... Just got things changed and the currect tests updates. Haven't made a pass for spelling or grammar [01:48] ok, np [01:56] axw: you around? I have questions on login/logout tests [01:57] natefinch: yes, but about to go into a meeting [01:57] axw: ok, let me know when you're out [02:23] natefinch: finished [02:24] axw: want to do a hangout? Might be easier [02:24] natefinch: sure [02:25] natefinch: https://plus.google.com/hangouts/_/canonical.com/andrew-nate&authuser=1 [02:25] eek, that doesn't work [02:25] heh [02:25] https://hangouts.google.com/hangouts/_/canonical.com/core?pli=1&authuser=2 [02:49] wallyworld: follow on from my earlier PR: https://github.com/juju/juju/pull/6400 [02:49] menn0: ok, just eating will look real soon [02:49] wallyworld: no rush [03:10] menn0: swap you https://github.com/juju/juju/pull/6401, an easy one [03:10] wallyworld: ok [03:11] wallyworld: but Brokener is such a great name :) [03:11] * wallyworld gets the sick bag [03:12] Breakable :p [03:12] much better [03:12] CanHazBroken [03:12] even betta!!! [03:12] love that one [03:12] why was that not a convention [03:13] CanHazAddress is much better than Addresser [03:16] wallyworld: I'll come up with something else [03:16] wallyworld: I don't understand your PR :-/ [03:16] :-( [03:16] wallyworld: well what came before it [03:16] menn0: i like Breakable :-) [03:16] wallyworld: i'll probably go with that actually [03:17] is it the --show-secrets behaviour? [03:18] wallyworld: well yes [03:18] so, by default list-credentials will not prints passwords etc [03:18] it needs to query the provider to get the schema to know what attrs are secret [03:18] to query the provider, it needs to look up the cloud details [03:19] so if the cloud name is invalid, it can't get the credential schema [03:19] so it errs not to print anything other than a message [03:20] wallyworld: but why show creds for a removed cloud at all? [03:20] because that entry is in the file [03:20] and list-credentials needs to display the contents of the file IMHO [03:21] maybe the user wants to add that cloud back later [03:21] wallyworld: ok [03:21] wallyworld: I'll suggest a simpler wording on the PR [03:21] ok [03:21] wallyworld: I think that's what threw me [03:22] i think what's there gives the necessary info, so if it's just a wording tweak [03:22] i wouldn't want to not convey that info [03:24] how about: [03:24] The following clouds no longer exists but credentials for them still exist. [03:24] Use --show-secrets to display credentials these credentials. [03:24] ... [03:24] wallyworld: ^ [03:24] ignoring the doubled up word :-/ [03:24] sgtm [03:25] ok [03:25] wallyworld: done [03:25] ta [03:25] now to land this Brokener change.... [03:25] :-p [03:26] Who wouldn't want a Brokener? [03:27] wallyworld: I can't believe you don't like that name [03:27] call me fussy :-) [03:27] i really hate how Go appends "er" to everything [03:27] sounds horrible most of the time [03:28] Yeah - I think it should have used "inator" instead [03:28] or "CanHaz...." [03:29] A Brokeinator would totally pwn a Brokener or a CanHazBroken [03:37] wallyworld, menn0, axw: https://github.com/juju/juju/pull/6402 [03:37] someone [03:37] looking [03:37] anyone [03:38] :P [03:41] thumper: done [03:45] * thumper off to jitz [03:45] will land when I'm back [03:45] after tweaking year === thumper is now known as thumper-afk [03:58] wallyworld: another look at https://github.com/juju/juju/pull/6400 pls [03:58] ok [03:58] now with Breakable [03:58] and I caught some tests that needed updating [03:58] thank goodness [04:00] menn0: still looks good, ta [04:21] Bug #1190985 changed: Confusing upgrade-charm and deploy -u behavior

[04:21] Bug #1521610 changed: Upgrade hung when moving from 1.18.4.3 to 1.24.7

[04:21] Bug #1583683 changed: juju thinks it is upgrading after a reboot

[04:30] Bug #1190985 opened: Confusing upgrade-charm and deploy -u behavior

[04:30] Bug #1521610 opened: Upgrade hung when moving from 1.18.4.3 to 1.24.7

[04:30] Bug #1583683 opened: juju thinks it is upgrading after a reboot

[04:33] Bug #1190985 changed: Confusing upgrade-charm and deploy -u behavior

[04:33] Bug #1521610 changed: Upgrade hung when moving from 1.18.4.3 to 1.24.7

[04:33] Bug #1583683 changed: juju thinks it is upgrading after a reboot

=== thumper-afk is now known as thumper [05:46] axw: I have a question about your review [05:46] thumper: yup? [05:47] axw: I didn't change the time that RunHook took at all [05:47] it was already returning cmd.Wait() [05:47] all I do is save the output after the Wait call [05:47] before we were discarding the output [05:47] that's all [05:47] thumper: what I'm saying is that the client won't get to see the stdout/stderr of the hook until after it's finished [05:48] ah [05:48] hmm... [05:48] thumper: oh ... yeah, we weren't setting stdout/stderr [05:48] huh, how do we see the output [05:49] isn't it the tmux session that is started? [05:49] I'm not sure [05:49] thumper: ahhh yes [05:49] thumper: never mind me then [05:49] how can I do QA on this [05:49] I'd like to check before landing [05:49] I don't think I've ever used debug-hooks in anger [05:50] thumper: umm. I guess create a charm with a config-changed hook that generates some stdout. then deploy it, debug-hooks, and force a config-changed [05:50] thumper: we don't actually run the hook at all ... we just trap and then you can run it yourself [05:50] thumper: so my review was garbage [05:50] yeah... [05:50] my problem is now that it is almost 7pm on friday [05:51] and I have run out of fucks [05:51] but I don't want to land something that could potentially screw tings up [05:51] so I need to test it [05:52] axw: if you get a chance, could you look at this for me? after you recover from being hassled by thumper https://github.com/juju/juju/pull/6405 [05:52] heh [05:52] wallyworld: sure [05:52] ta [05:54] thumper: I think it's fine to land as is. a smoke test of debug-hooks would be good, but I think fine to skip in this case [05:54] thumper: I do think it would be a bit neater to pass Stdout/Stderr in as a param, but not fussed [05:54] (just so you don't have to reach in via export_test) [05:55] I thought that RunHook might have been an interface function [05:55] so signature mattered [05:55] thumper: it is. I meant pass in via the HookContext [05:56] ah... [05:56] ok [05:56] yeah, that's better [06:07] axw: reworked how to get the combined output, https://github.com/juju/juju/pull/6402 [06:07] looking [06:07] so no change to the code for non-test [06:09] thumper: looks better, thanks. approved [06:09] axw: ta [06:09] and on that note [06:09] I'm off to start drinking [06:09] later folks [06:10] enjoy [06:29] axw: with error code, you never get a not found from that api - it is always ErrPerm if the model is not there [06:30] wallyworld: yeah I know, I'm just saying using that function would make it clearer why you're looking for that error [06:30] wallyworld: alternatively, please add a comment [06:30] ok [06:31] axw: also, i was trying to avoid having to add an api. ModelInfoResult does contain the number of machines in the model, but not number of applications. I could just print the number of machines [06:32] or I guess I could add to the struct and the applications bit won't be there for rc1 and rc2 [06:33] wallyworld: could we just make a call to FullStatus? [06:34] we could. seems expensive though just to poll for info like that [06:34] wallyworld: on the client facade [06:34] i'd prefer not to tbh [06:34] wallyworld: why? we want to know the model status... [06:35] the thing we really want is for the command to block [06:35] printing the number of machines and apps is a bonus [06:35] imho [06:36] i'm worried about calling full status every 2 seconds [06:36] maybe it's nothing to worry about [06:36] wallyworld: what's your concern? [06:36] I don't think we should be concerned about getting status frequently [06:37] sec [06:39] status is fairly heavy weight last time i looked - it did a bit to gather all the info, and then all we would do is throw most of it away here simply to print a machine/app count [06:39] if we do want to do that, we have a ModelInfo api with machine info [06:40] we'd just need to add application count [06:40] wallyworld: I'm fine with that. and it would be ok if you only showed the machine count for an rc3 server [06:40] on large models, status used to tke minutes and minutes to run [06:40] ok [06:41] wallyworld: that's a problem that we need to fix :) [06:41] if it's still a problem [06:41] right, but for this bug fix, i'd rather use something lightweight. status might be fixed, but it is still heavy weight i think [06:42] yep, fair enough === frankban|afk is now known as frankban [08:12] wallyworld: sorry, but Controller.ModelStatus isn't suitable :( it requires superuser [08:13] so you wouldn't be able to destroy your own models if you're non super user [08:13] really? sigh [08:14] axw: yeah, you're right. but i think we should change the perm on that method [08:14] if you had permissions on the model, you should be able to get its status [08:14] wallyworld: fine by me. superuser || model-owner [08:14] or [08:14] will have to fix after soccer [08:15] model admin or whatever [08:15] at least i didn't need a new api [08:15] wallyworld: yeah. it does mean that rc3 would be brokenish, but I think that's ok [08:15] i think so too [08:15] we can release note it [08:16] right, off to soccer, bbiab [09:43] voidspace / babbageclunk: Small branch for review if you have the time: https://github.com/juju/juju/pull/6406 [09:52] dooferlad: looking [10:04] dooferlad: lgtm [10:05] dooferlad: with a couple of comments [10:11] dooferlad: I guess there is no golang way to get the fs reserved space number, rather than a magic 90%. I won't look too hard if you already have. You might assume 5% in the fs, so 10% isn't a bad one. [10:20] macgreagoir: I am sticking to magic for now because it gets us out of the woods. It would be great to be able to pass in something on the CLI so the user can restrict / expand as wanted or do something based on monitoring the host. [10:21] tune2fs -l :-) but we don't want to assume that. [10:22] Assuming to reserve twice the fs default as reserved is not so bad. [10:23] macgreagoir: I was talking about the Juju CLI [10:24] macgreagoir: I know about the tune2fs thing and leaving some space on the host seems good too. [10:24] Oh, aye, I mean a way to get a non-magic number. [10:42] dooferlad: as part of provisioning a new machine (cloud-init) we reboot, right? [10:44] voidspace: I don't think we reboot at the end of cloud-init [10:44] dooferlad: ah [10:45] voidspace: pretty sure that cloud-init runs on first boot after install. [10:45] dooferlad: we'd like to up the open file limit, but that requires a reboot - unless we get into the image I guess [10:46] voidspace: you can do that on the fly [10:46] voidspace: just looking that up [10:46] dooferlad: not inotify user_watches or max_instances [10:47] voidspace: sysctl -w fs.file-max=100000 [10:47] dooferlad: ah, ok - interesting I'll try it [10:47] dooferlad: we've been looking at setting it in /etc/security/limits.conf which requires a reboot [10:51] voidspace: I don't know which file in /etc/ wins on reboot. http://askubuntu.com/questions/594765/ubuntu-14-04-cant-get-past-4096-max-open-files-for-non-root-user has more info [10:51] dooferlad: thanks [10:51] appreciated [10:53] ooh, agent lost on 11 machines - I think I just hit the limit [10:53] past 20 containers though [10:53] ah no, they're back - just the machine grinding to a halt I think [10:54] I'm at 25 [10:54] Morning [10:56] perrito666: morning! [11:07] at 30 containers I ran out of disk space [11:53] this PR introduces a new field in api.Info, SNIHostName. reviews appreciated, thanks. https://github.com/juju/juju/pull/6407 === rogpeppe1 is now known as rogpeppe [12:05] axw: i updated the api server to allow model admins or owners to make that status call. rc3 servers will not break the destroy as it will just print a message and continue without blocking [12:33] K doctor appointment bbl [13:41] well gotta love when doctors use old houses as practices.... lte wont go through walls [14:01] voidspace: ping for standup [14:01] rick_h_: omw [14:27] could someone review this please? i've got another one backed up behind it. https://github.com/juju/juju/pull/6407 [14:45] perrito666, ping [14:46] katco: can you peek at rogpeppe's link ^ please? [14:46] rick_h_: sure [14:46] voidspace, dooferlad, katco``: anyone feel like a review? https://github.com/juju/juju/pull/6408 [14:46] ty! [14:47] d'oh [14:47] rogpeppe: is this fixing a bug? [14:51] babbageclunk, that is why I was pinging perrito666 :) [15:00] rick_h_: btw, I forgot that updating the featuretests for the logout stuff was actually very easy, so I just did it. landing now [15:00] natefinch: <3 [15:02] katco: no, it's an enhancement to make it easier to deal with controller with public certs [15:17] ahh crap, realized I need to get the change to persistent-cookiejar to land before the juju core stuff will work, oops. [15:23] rogpeppe: I made the suggested changes to persistent cookiejar, in a new PR from a better named branch: https://github.com/juju/persistent-cookiejar/pull/18/files [15:23] natefinch: ok, looking [15:23] natefinch: swap ya! https://github.com/juju/juju/pull/6407 [15:23] rogpeppe: natefinch: i am also looking at this ^^ [15:24] i need two reviews to land it :) [15:24] rogpeppe: deal [15:25] natefinch: i'm also working on getting people on board for general use of my new retry package API... (which I think is actually kinda cool :-]) https://github.com/juju/utils/pull/245 [15:26] rogpeppe: we really need to move juju/utils/clock to a top level repo [15:27] natefinch: LGTM [15:27] rogpeppe: thanks [15:27] natefinch: yeah, probably [15:27] natefinch: although i don't think it's a big issue [15:28] rogpeppe: utils churn has been an issue in the past... backporting stuff in utils often requires one-off ugly branches and godeps. [15:31] rogpeppe: newWebsocketDialer0? [15:36] rogpeppe: are dialwebsocket and dialapi unchanged? They moved, so it's hard to see the diff. [15:36] natefinch: they're pretty similar if not entirely unchanged. sorry about the move, but they really belong together. [15:36] oh, no, I see some diffs [15:37] mostly unchanged though [15:38] natefinch: i thought that "newWebsocketDialer0" vs newWebsocketDialer is better than the arbitrary newWebsocketDialer vs createWebsocketDialer [15:38] natefinch: i often use "0" as a "this is different but essentially the same thing" suffix [15:42] rogpeppe: review up [15:42] katco: ta! [15:43] i really dislike how comments break up the code... makes it really hard to read reviews [15:43] katco: "We need to instead take this in as a dependency to the call-chain." - does that mean every caller to NewServer has to manually wire that dependency up? [15:44] rogpeppe: that bubbles up to Open(...) doesn't it? [15:45] katco: oh yes, sorry, it does... every call to Open then [15:45] rogpeppe: it would fit nicely into DialOpts i think [15:45] rogpeppe: yes, that is what it means [15:45] katco: i really feel like it's very much an internal implementation detail [15:45] rogpeppe: if it were, then the code you're writing against it wouldn't have to patch a global variable [15:46] katco: it's an internal test [15:46] rogpeppe: tests are just code [15:46] katco: it's allowed to depend on internal implementation details [15:46] katco: for me, not exposing it is about encapsulation of implementation detail [15:47] katco: if we expose it, we can't change it any more [15:47] rogpeppe: sure we can, you just pass in something different [15:47] katco: clients become dependent on that particular detail of the implementation [15:47] rogpeppe: if it were an implementation detail, the code you've written wouldn't have to patch out a global variable [15:47] katco: ok, we can't change it without changing the clients [15:48] rogpeppe: yes, but the code you've written shows that different clients have different needs [15:48] rogpeppe: this is fundamental to IoC [15:48] katco: the test in question is a unit test. i think it's legimate for unit tests to depend on internal details that we would not want to expose outside the package. [15:49] rogpeppe: a test is just code, and in this case it's exposing a design flaw [15:49] katco: i don't think all tests should be external tests. that way lies hideously complex APIs [15:50] rogpeppe: i think that decision was already made [15:52] katco: really? *strictly* external tests? [15:52] rogpeppe: yeah [15:53] katco: i mean, i know we define tests as if they were external, but i didn't realise we weren't allowed to test any internal implementation detail directly [15:53] rogpeppe: i went through that pain and came out the other side agreeing with it a little more. i haven't run into a counter-example, but i don't doubt they're out there [15:53] katco: if that's really the case then i give up. i think it's a path to ruin. [15:54] rogpeppe: :( i don't know how to respond to that. i didn't like it either, but i pushed through [15:55] katco: so you really think we should add a field like this to api.DialOpts? [15:55] DialWebsocket func(cfg *websocket.Config, opts DialOpts) func(<-chan struct{}) (io.Closer, error) [15:55] rogpeppe: i am less sure about how it gets passed in, but DialOpts does look like the right spot as a place to specify "options to dial"? [15:56] katco: even though there are >70 instantiations of DialOpts in the code and they'll all need to change and websockets are just an implementation detail of the API that we might want to change in the future? [15:56] rogpeppe: how about this? create a 2nd function that calls the existing one with the correct function passed in? [15:57] katco: ? [15:58] katco: tbh rather than adding that i think it would be preferable to do a more integration-style test with a real server (but that's hard with code that relies on officially signed certs) [15:58] rogpeppe: i.e. rename Open => OpenWithWebsocketDialer(..., func()) and then modify Open to call OpenWithWebsocketDialer with the correct func? [15:58] katco: why would you want to export that function? [15:58] rogpeppe: integration tests can be done in the top level featuretests/ but not anywhere else [15:59] katco: that still exposes an implementation detail that really should be hidden inside the api package [15:59] katco: websockets are not essential to the api abstraction [15:59] rogpeppe: the code you have written shows that it is not an implementation detail [15:59] katco: you're saying that tests aren't allowed to test specific implementation details AFAICS [16:00] katco: and i disagree. tests of specific implementation details are often the ones that give you most confidence in the higher level code. [16:00] rogpeppe: they are certainly free to test the behavior, but if that behavior need be modified by patching out global variables, that's a design smell and proves that it's not an implementation detail [16:01] katco: you're saying they're free to check externally visible behaviour but nothing else. [16:01] rogpeppe: yes, the behavior of the thing you're testing, not how it's implemented [16:02] katco: i think there's room for both approaches. we often write tests knowing about the structure of the code we're testing. [16:02] katco: because otherwise you would never get decent test coverage and you'd write lots of redundant tests. [16:03] katco: i think this is that kind of case. [16:04] katco: patching out global variables is a smell, yes, but so is exposing abstraction-breaking details as part of your public API. [16:04] katco: as usual, there's a trade-off to be made. [16:04] rogpeppe: i've heard this argument a lot -- that it breaks encapsulation -- yes, by design it does. the code you've written has shown that it's a detail that should not be encapsulated [16:05] katco: you're assuming that a package's tests are exactly the same as any other client of the code. [16:06] katco: but as i've tried to say, they really aren't - they are necessarily privy to details of the code structure. [16:06] rogpeppe: not the same, but it is one of the first consumers [16:06] katco: that's very true, and it's great to write tests as much as possible to be strictly external. [16:07] katco: but i don't think that it's necessary to have a hard and fast rule there. [16:07] katco: in the end what really counts is the overally simplicity and maintainability of the code. [16:07] s/overally/overall/ [16:07] rogpeppe: definitely [16:08] katco: and a big part of "simplicity" is simplicity of exported APIs. [16:08] rogpeppe: but, we tried the other way. our tests are extremely brittle, so a decision was made and we must abide by it [16:08] rogpeppe: no, that's "easy". simplicity is a different beast [16:08] katco: no, simple APIs are not "easy" [16:09] katco: FWIW making this an exposed external thing is likely to make code more brittle not less [16:09] rogpeppe: there are valid arguments against ioc, but i don't think lack of simplicity is one of them. lack of ease is i think [16:09] katco: ioc? [16:10] rogpeppe: inversion of control [16:10] rogpeppe: dependency injection [16:11]