[00:37] wallyworld: PTAL http://reviews.vapour.ws/r/5548 and make sure I understood you. [00:37] ok [00:40] redir: you sure you oushed the changes? i can't see a new diff [00:41] shit I need to rbt it [00:41] RB ate my original PR [00:42] wallyworld: ^^ rbt post -u run... [00:42] ok [01:12] axw: looking at the cloud facade - the credential apis take / return tags. but i thought our general principal was that tags are not to be exposed outside of the apis (wire format only). we pass in names etc and these are converted to tags inside api/* [01:21] wallyworld: feel free to change it. I like the type safety and documentation it brings [01:21] axw: yeah, i get that too. i'll leave for now, but we should agree on a consistent approach [01:22] axw: should raise as a tb topic [01:27] axw: damn, and we also leak params structs for results where we return a slice of {*Value, *Error} [01:28] wallyworld: where? [01:28] everywhere, eg [01:28] func (c *Client) StorageDetails(tags []names.StorageTag) ([]params.StorageDetailsResult, error) [01:28] wallyworld: oh, yeah we do that in many places. I thought you meant in Cloud [01:29] sigh, i'll just stick to current convention for now [03:22] wallyworld, menn0: can you see this ? http://imgur.com/a/zmSPH [03:23] yes [03:23] good? [03:23] nice [03:23] ecept for colour blind people [03:24] looks good to me... the red could have better contrast IMO but that comes down to your terminal color settings [03:24] I can't help them... [03:25] thumper: I'm not sure that "unknown" should be highlighted. it's not that unusual for a charm to not set workload status [03:25] right, but if we mark it yellow, people will want to set it green, right? [03:26] thumper: we can help them by choosing better colours, like jenkins does [03:27] but red and green are nice i admit === natefinch-afk is now known as natefinch [03:56] use red for bad, blue for good. add symbols to make it more clear - ✘ error ✔ success [03:57] ❓ unknown [03:57] no symbols with this change [04:00] red / blue then [04:31] huh... [04:31] interesting [04:31] tried bright blue for the good color [04:31] but watch -c doesn't show that [04:32] weird [04:32] less -R does [04:32] I'm tempted to stay with green for now and see what response we get [04:35] 10% of men are color blind. That's probably 9% of our target market... I personally know several color blind people. It's just a bad idea, and sort of inexcusable in this day and age. It sucks the default linux tools don't cooperate, but that doesn't mean we shouldn't do the right thing anyway. [04:37] sounds like we might be hitting something like this: https://github.com/cloudfoundry/cli/issues/840 [04:37] do we always output color, or do we do some terminal detection? [04:39] axw: if you get bored of looking at juju heap dumps, no rush or anything, http://reviews.vapour.ws/r/5554/ [04:40] wallyworld: will take a look after lunch [04:40] sure, no hurry [04:54] thumper: phew... source prechecks done. just 2 more target prechecks to go. [04:54] doing some manual QA now [04:56] veebers: the migration prechecks around juju versions, upgrades in progress and machine health have all landed [04:56] veebers: and there's a bunch more on their way [04:57] menn0: sweet. Tomorrow morning I might take some of your time to flesh out any remaining CI tests for the migration parts [04:57] veebers: sounds good [04:58] review up: http://reviews.vapour.ws/r/5555/ [05:00] natit was just the blue, watch showed red/green/yellow, thinking it is the high 8 [05:03] wallyworld, menn0: here is what blue for good looks like http://imgur.com/a/4kMVu [05:03] thumper: ah, so you looked at what jenkins does :-) [05:03] no [05:03] nate suggested it [05:03] wallyworld: review is ready [05:04] thumper: that's what i suggested too, sigh [05:04] it is a one line change to go from green -> blue [05:04] ok, you too [05:04] looking [05:04] * thumper heading off to bjj, will check on review later === thumper is now known as thumper-afk [05:09] thumper-afk: I prefer green (but only slightly) [05:34] wallyworld: how will the ListCredentials API be used? [05:34] wallyworld: just wondering what's the use if you can't see all of the attributes [05:35] axw: the GUI will use it to load credential data to be displayed and to allow to user to paste in new secrets if they want to update their credentials. it still needs to be fleshed out [05:36] so for openstack say, you can see you domain and tenant and username etc [05:36] but not the secret [05:36] i'm thinking we can always add in secrets if needed [05:37] wallyworld: yeah ok, I guess that's fine. maybe we could set the value to "" for those attributes at least, so you can tell that they're redacted rather than missing [05:37] that's a fair point [05:37] i'll do that [05:37] wallyworld: or a separate field with names of refacted attrs [05:38] redacted* [05:38] le shrug [05:38] separate field might be ok too [06:31] axw: so there's just the revoked issue to consider now - as explained in the rb comment, the api just sets the revoked flag; we need to decide how to best handle that in subsequent prs [06:33] wallyworld: ok, will look again in a moment [06:33] no rush [06:48] wallyworld: I'm having second thoughts about delaying removal of revoked creds now, but we can change it in a follow up if needed [06:48] wallyworld: just thinking, in terms of security you probably want that gone from the db ASAP [06:48] rather than waiting around for something to stop referring to them [07:09] axw: i was kinda thinking the same think, and that goes along with not shipping secrets by default. the reason for a new type is that I wanted to keep cloud.Credential nice and clean, but i guess adding a redacted slice is ok [07:11] axw: with remiving them straight away, the idea is that a followup would implement the listener to immediately notify everything that those credentials are gone; that also allows them to be replaced immediately with the same name [07:11] so i'm happy to revert to what was there originally [07:12] axw: you +1 with s/Revoke/Remove in state ? === frankban|afk is now known as frankban [07:29] wallyworld: you don't need to add Redacted to cloud.Credential yet [07:30] axw: yeah, came to the same conclusion [07:30] have removed the new type === TheRealMue is now known as TheMue [07:47] morning === thumper-afk is now known as thumper [09:38] Hi, lads. How do I get older version of a charm source? charm-pull-source seems to download only the most recent version. Or: where do I ask questions like this? :) [10:58] morning [11:05] perrito666: morning [11:18] ah, two old colleagues. already wondered where the European ones are. [11:21] fwereade: Thanks for the review - have you got a moment to talk about the Undertaker tests? [11:37] TheMue: I am not in europe :p [11:38] babbageclunk, let's [11:38] mgz: just went back to this after a while and found that it had failed, but it's not clear why. any idea? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8952 [11:38] perrito666: no, but at least voidspace should be [11:38] fwereade: Wanna hangout? [11:38] perrito666: has been so quiet in the channel this morning [11:39] babbageclunk, sgtm [11:39] TheMue: well its like 8:30 for me :p [11:39] fwereade: https://hangouts.google.com/hangouts/_/canonical.com/core?hl=en&authuser=1 [11:40] rogpeppe: I'll take a look [11:41] mgz: ta [11:41] mgz: not that important, but it's useful to know how/why these things fail [11:41] I agree [11:42] mgz: i sometimes wonder if we should auto-retry when an intermittent error happens that's not to do with the code being tested [11:43] I'd like to surface those to github better at least [11:43] mgz: yeah [11:44] mgz: the main one is that if a merge has been blocked because of critical bugs, it would be good to retry when unblocked [11:44] mgz: i've actually thought of doing a little daemon that would do that for me [11:51] * babbageclunk goes for a run. [12:07] TheMue: I'm still in Europe, yes [12:07] TheMue: morning o/ [12:08] voidspace: o/ but it seems dimitern and frobware are on vacation [12:17] TheMue: ah, maybe. I don't see that in the calendar. [12:18] voidspace: I've only interpreted the silence that way *lol* [12:19] * TheMue currently plays a bit with crypto packages for token signatures [12:20] TheMue: you might be right, I know frobware was going on holiday but I can't remember if he is due back yet or not. [12:20] voidspace: I'm here... [12:21] frobware: hello o/ [12:21] o/ [12:24] ah, hey frobware o/ [12:25] TheMue: hello [12:45] * frobware runs for some lunch before standup [13:20] dimitern: Did you get everything sorted in the bug you guys were working on? [13:21] babbageclunk: more or less - I'm working on good, well tested fix now - will start proposing PRs soon :) [13:21] dimitern: nice one [13:23] Yay, thanks whoever added the build-parameters info for queued builds in Jenkins! [13:23] Now I can see how far back mine is. :( [13:30] tiny review: this fixes a couple of unreliable tests: https://github.com/juju/juju/pull/6119 [13:32] rogpeppe: LGTM! Failing less often sounds nice. [13:33] rogpeppe: your mp from earlier failed to merge again, in case you didn't see [13:34] rogpeppe: not the same issue [13:34] ah, you resent [14:01] Bbl doctors appointment [14:01] natefinch: dimitern: standup time [14:02] fwereade: standup time === rmcall_ is now known as rmcall [14:09] mgz: now i wanna put my "fix unreliable tests" PR near the top of the queue so that the other PRs have more hope of landing... [14:10] : [14:10] D [14:10] ow face cut in half [14:10] we can cancel things above it in the queue that haven't started yet, if there are lots [14:19] mgz: Is build 8976 stuck? It's been running since 12:32. [14:20] lets have a look [14:21] hm, harder to see what's up with the new multi task thing [14:22] katco, oops, sorry, I was packing [14:22] fwereade: no worries; any updates on refcounting stuff? === alexisb-afk is now known as alexisb [14:23] katco, I may or may not land the cleanup change after the flight [14:24] katco, ...but I have no excuse not to land that one that was already reviewed [14:24] not *land* the cleanup change, but push it for review [14:24] * fwereade fail english? that's unpossible [14:24] fwereade: haha [14:25] probably ought to be off now to avoid panic later [14:25] o/ [14:25] fwereade: cool; yeah, figured the cleanup is the more important of the 2? the one you can land just sets the stage? [14:25] k tc fwereade [14:25] katco, yeah exactly [14:25] later all [14:25] fwereade: ta [14:26] babbageclunk: I unstuck it [14:26] mgz \o/ [14:26] mattyw: your run failed - the hang was not your fault, but also looks like to have a map-order dependent test failure [14:26] mgz ok now cancel all the other ones except for mine. [14:27] babbageclunk: :P [14:27] mgz, yeah - that was fixed an hour ago but I'm waiting for this die so I can propose the fix [14:28] ec2 wasn't giving us a machine and the script doesn't have a shorter timeout at the right point for that [14:33] dimitern: ok, back in the standup hangout? [14:34] natefinch: omw [15:07] dimitern: ssh ubuntu@104.196.124.147 [15:17] dimitern: Assuming I've turned on security.nesting, I should be able to bootstrap to lxd inside a lxd container, right? [15:19] frobware: ^^ [15:19] babbageclunk: yes, been a while since I tried though [15:20] babbageclunk: my profile: http://pastebin.ubuntu.com/23112208/ [15:20] frobware: Someone over in #juju is getting an error with beta16 bootstrapping to lxd - I tried it and get the same error, with both lxd 2.1 and 2.0.4 [15:22] frobware: They say it wasn't happening in beta15. Does it sound like that packaging problem you guys were talking about? [15:22] babbageclunk: :( [15:22] frobware: I don't see it if I use my built-from-source juju, only in a container with a juju from ppa [15:23] frobware: Anyway, I'll log a bug about it. [15:23] babbageclunk: ack. sidetracked atm :\ [15:24] frobware: No worries, just wanted confirmation that it should work. Thanks! [15:24] babbageclunk: I haven't tried recently [15:24] I know we set security.nesting by default [15:27] dimitern: ok, thanks. [16:01] babbageclunk: I just started a container OK [16:02] babbageclunk: but I just built from tip of master [16:02] frobware: yeah, I get that as well - try with juju beta16 from the ppa [16:03] babbageclunk: perhaps. I _need_ this bootstrap. :) [16:04] frobware: Tsk! They're cattle not pets! ;) [16:05] babbageclunk: diff between tip and 16: 140 files changed, 4769 insertions(+), 1405 deletions [16:05] frobware: I'm just checking it's a beta16 thing by trying with beta15. [16:07] frobware: yeah, it works with beta15. [16:08] morning juju [16:09] juju-dev even [16:10] babbageclunk: you have your bisect point [16:10] frobware: gah, sounds like fun! [16:17] frobware, babbageclunk, voidspace: I'd appreciate a review on this: http://reviews.vapour.ws/r/5559/, I tried to keep the changes straightforward - mostly added tests [17:09] rogpeppe: urk your unreliable test fix branch didn't go through [17:10] feature tests failed [17:10] it was unreliable [17:10] :p [17:10] sorry could not resist [17:11] I'll requeue it later, as my branch before failed due to the one that branch fixes :) [17:11] I think we have a bug for the feature tests already? [17:12] sinzui: do you know? unit test failure of featuretests due to api connection refused [17:13] mgz: I definitely saw one recently, but I was also reviewing 18 months of data. I will look [17:13] sinzui: thank you [17:26] mgz: http://reports.vapour.ws/releases/issue/578f7bf1749a567c7344833e is increasing in frequency === frankban is now known as frankban|afk [17:28] mgz: cmdStorageSuite.TestStorageAddToUnitSuccess has never failed in CI testing [17:30] hm, I wonder if it's something new on juju-core-slave then [17:34] mgz: i know [17:34] mgz: i've reported a bunch of unreliable test bugs today [17:34] rogpeppe: <3 [17:35] mgz: including most recently this: https://bugs.launchpad.net/juju/+bug/1618560 [17:35] Bug #1618560: worker/txnpruner: sporadic test failure [17:35] mgz: took me a little while to figure out how that could fail (i've added a comment) [17:35] mgz: a lot seem to be failing because they can't contact the API server. not sure what's going on there. [17:36] mgz: feel free to discard any dupes. [19:09] * redir lunches [19:25] * redir lunches in a minute after reboot [20:56] wallyworld, I will miss the sts call [20:56] ok === natefinch is now known as natefinch-afk [21:02] niedbalski: google hates me, be there as soon as hangouts starts working [21:03] wallyworld, sure, np! [21:06] oh FFS [21:06] this test: BootstrapSuite.TestBootstrapProviderDetectRegions has blocked two landings [21:06] intermittent failure due to ordering [21:06] anyone fixing this yet? [21:07] https://bugs.launchpad.net/juju/+bug/1618582 [21:07] Bug #1618582: BootstrapSuite.TestBootstrapProviderDetect(No)Regions fails the expected auth type due to misordering

[21:07] ^^^ ian earned a regression [21:07] but you are welcome ot fix it [21:08] thumper, ^^ [21:08] k [21:10] alexisb: I'll grab it [21:10] it is blocking me [21:11] is there a card for it on the board? [21:11] thumper, nope === BradCrittenden is now known as bac [21:18] found it [21:23] quick review for someone: https://bugs.launchpad.net/juju/+bug/1618582 [21:23] Bug #1618582: BootstrapSuite.TestBootstrapProviderDetect(No)Regions fails the expected auth type due to misordering

[21:23] * thumper sighs [21:23] this one http://reviews.vapour.ws/r/5561/diff/# [21:25] alexisb: want to review it? [21:25] or menn0 [21:25] http://reviews.vapour.ws/r/5561/diff/# [21:26] menn0: morning btw [21:26] thumper: howdy [21:26] alexisb, thumper: I'll review it. I'm OCR. [21:26] menn0: review is a trivial fix for a test that is failing half the time [21:26] this database is a poorly writen joke [21:26] heh [21:28] our latest foe https://jira.mongodb.org/browse/SERVER-20729 [21:31] thumper: ship it [21:31] ta [21:34] perrito666: i'm not apologising for the db, but that ticket is closed and seems to refer to something dodgy the user was doing [21:34] menn0: we are being biten by the error, but the cause is not the same [21:34] perrito666: ah ok [21:35] apparently that can happen for a number of reason included but not limited to, the db shut down abnormally [21:36] menn0: when can we have the external migration flag? [21:36] prechecks seems to be taking longer than we thought [21:36] thumper: it has... I ran into a lot of problems yesterday [21:37] thumper: the latest changes are ready but I noticed a possible issue while QAing yesterday [21:37] thumper: around unit status [21:37] thumper: I can pause prechecks after my current PR is done (although there's only 2 checks left to implement after that actually, but they involve minor API work) [21:38] I've pushed the external flag to beta 18 [21:38] so keep with prechecks [21:38] ok [21:40] menn0: thoughts? https://bugs.launchpad.net/juju/+bug/1606991 [21:40] Bug #1606991: TestWaitMinionNeverBecomeMinion wrong minion

[21:41] thumper: nothing to do with migrations if that's what you're thinking [21:41] thumper: will just happened to use the word minion for this leadership test [21:42] thumper: I have almost no clue about how leadership works [21:42] thumper: but I can dig into it if you need me to [22:03] menn0: txn pruner clock branch: http://reviews.vapour.ws/r/5562/ [22:04] menn0: ok, re bug abovev [22:05] wallyworld: https://bugs.launchpad.net/juju/+bug/1603176 thoughts on this? [22:05] Bug #1603176: juju debug-log returns not logged-in error [22:06] thumper: ok, just reviewing perrito666's PR atm, will do yours next [22:06] I wonder if it is how we are passing creds through to the streaming apis [22:06] hmmm [22:07] off hand i am not sure, but it does seem suspicious that it's not for a normal rpc call [22:21] perrito666: the diff on RB for PR 6104 doesn't match what's actually in the PR on Github [22:21] perrito666: in the review UserAccessSpec has ObjectID, but the PR doesn't have that [22:22] perrito666: sorry ObjectUUID, not ObjectID [22:25] hmm... enable-ha on to two manual machines seem to not work [22:30] can anyone else see the problem here? http://pastebin.ubuntu.com/23113867/ [22:30] both amusing and not at the same time [22:31] thumper: it should be using a non localhost IP otherwise the other nodes can't connect? [22:31] :) [22:32] well.. it complains a few lines lower that it has multiple entries with the same _id [22:32] I'm poking more [22:32] thumper: regarding the txnpruner fix, it looks great but I don't think you need the started channel do you? [22:33] menn0: kinda, otherwise the test doesn't know when to start advancing the clock [22:33] unless you have other ideas [22:34] I think I do... [22:34] * menn0 checks the test clock [22:34] I think the test clock has a feature to let the test know when After has been called [22:36] thumper: yep, that's it. The testing clock can return a channel via the Alarms method which lets you know when After has been called [22:36] thumper: you can just wait for that in the test [22:36] it's exactly for this use case [22:36] ah, cool [22:36] please leave a note :) [22:36] will do [22:36] that was the only bit I was not happy with [22:37] hmm... [22:37] * thumper wonders how this works with ha lxd [22:38] * thumper fires one up [22:38] has anyone else got tab completion woes with juju? [22:38] juju _juju_complete_2_0: command not found [22:39] that was juju [22:39] thumper: ship it [22:45] thumper: it looks like the juju-2.0 package isn't installing /etc/bash_completion.d/juju-2.0 [22:46] I haven't installed the package [22:46] I'm running from source [22:46] thumper: you don't have the official juju-2.0 installed as well? [22:47] nope [22:47] don't think so [22:47] if you installed from source how could bash know where to find the completion? [22:47] probably should yes? [22:48] I do have that installed [22:48] hmmm, it actually works for me [22:48] and I am missing /etc/bash_completion.d/juju-2.0 [22:49] I have juju-2.0-beta17 installed [22:49] hmm... I must be missing the ppa [22:49] I have beta 15 [22:50] thumper: I actually just have /etc/bash_completion.d/juju-core and that seems to work [22:50] and beta 15 doesn't install anything in /etc/bash_completion.d [22:50] there's more stuff in /usr/share/bash-completion/juju* [22:50] that's probably the problem then [22:50] * menn0 checks where his juju package came from [22:51] thumper: yeah, I have the stable PPA [22:51] cd [22:52] menn0: just the stable? [22:52] thumper: yep [22:52] stable doesn't ahve juju in it [22:52] menn0: as in ppa:juju/stable [23:00] interesting [23:00] when using lxd in ha mode [23:00] the same input generates a different result [23:00] curious [23:16] menn0: sorry was at the market, what happened with gh and rb? [23:17] perrito666: the diff on Github is not the same as the one on RB [23:18] meh, that sucks (that being rb) [23:18] menn0: so your review does not apply? [23:19] perrito666: well most of it will still apply [23:19] menn0: tx for the heads up btw, ill take a look to see if I can make them be the same [23:20] perrito666: the main thing I noticed is that state.UserAccessSpec doesn't have ObjectUUID in the pull request on Github [23:20] perrito666: did you manually update the diff on RB? [23:21] menn0: nope [23:21] weird [23:21] menn0: I dont even have the tools for that on my system [23:42] axw: the maximum log buffer size would be around 100MB [23:42] so not ridiculous [23:46] menn0: ah that's probably not it then, thanks [23:49] rogpeppe: I fixed that bootstrap test already [23:49] rogpeppe: you didn't mark in the bug that you were fixing it [23:49] so I did [23:55] menn0: love your doorbell