[00:07] thumper: easy one: http://reviews.vapour.ws/r/5482/ [00:08] axw: when you're around can we talk about bug 1569632 please? [00:08] Bug #1569632: status: decide on statuses for migration [01:00] thumper: well that is awkwards, menn0 gave you a nice ship it and I just added a bunch of issues [01:03] menn0: I'm around now [01:04] wallyworld: I think I'm ready for a consult [01:04] if you're available [01:04] ok [01:04] standup ho? [01:06] wallyworld: that is an awful thing to call redir [01:06] perrito666: you funny [01:06] btw [01:06] i am having acl issues [01:06] there's some code left in the admin_root which checks for read only calls [01:06] and the list of read only calls in incorrect [01:07] and we don't even need that check anymore [01:07] wallyworld: well we can nuke that [01:07] yep, doing it [01:07] I decided to nuke it post-implement acls [01:07] just as a failsafe [01:07] sure, i need to remove it for my branch to work [01:07] users can't list models [01:07] admins can, but not others [01:07] brt [01:08] wallyworld:mm, after reading the list models method I assumed it would show to each user their own models [01:08] therefore it was safe to make it RO [01:08] since RO users will just not get results [01:08] it is, but that hard coded list omitted the ListModels call [01:08] ahh I see [01:08] RO users need to be able to see their own models [01:09] anyways, all fixed now [01:09] i just wanted to check that you agreed we should remove that code [01:21] katco: no [01:24] perrito666: hmm... we often don't check the error returns of fmt.Fprintf as well [01:25] perrito666: given the number of places we call flush without checking, I think this is ok [01:26] thumper: I assumed so, It tickled me because we where checking it in just one place and you removed it, but I believe its ok too [01:27] thumper: the other ones are valid though :p [01:27] you expect me to file bugs for dfc's old comment? [01:27] that's a bit rough [01:28] perrito666: and changing other fmt.errorf calls... [01:28] thumper: you are the one that said that we should .... meh forgot the words but something about leaving stuff neater than we found, also you passed by that code and dfc was your teammate :p at least re-own it [01:28] :P [01:30] anyway, eod, cheers all [01:31] thumper: running a minute late [01:31] thumper: yay [02:16] thumper: with colour, axw had a good point - you need to keep the * still, for the current controller etc even when it is a terminal and colour is used [02:16] wallyworld: let me show you something [02:16] (for colour blind people; unless the contrast between green and white is enough?) [02:16] ah... [02:16] good point [02:16] it was so good though :) [02:17] having an extra * is not big deal, it's still green [02:20] wallyworld: intermittent failure :( [02:20] faaaaaaaarrrrkkkk [02:21] * thumper needs foot [02:21] * thumper needs food [02:22] * thumper has two feet [02:46] wallyworld: RB bot is asleep, can you please review https://github.com/juju/juju/pull/6034 [02:46] sure [02:46] wallyworld: I decided not to make the change to the machiner worker after all, if you force destroy a machine you shouldn't expect it to uninstall cleanly [02:46] wallyworld: and there's another scenario where it could happen, with a note that we explicitly don't handle it because state could just be borked [02:47] that's the change to react to not found? [02:47] wallyworld: and uninstalling because of a bug would be bad [02:47] wallyworld: yes. so I just changed the cleanup to not force destroy on destroy-model [02:47] ok [02:49] axw: lgtm, thanks [02:49] ta [03:02] wallyworld: landed!!!! [03:02] \o/ [03:02] awesome [03:02] thumper: grats [03:02] will propose my branch now [03:06] thumper: http://reviews.vapour.ws/r/5483/ [03:07] wallyworld: why have you removed read only calls? [03:07] 1. out of date, 2. did you read horatio's email? [03:07] no... [03:07] also [03:07] no longer needed since permission checks are on each moethod now [03:08] what would the mechanism be to block all modifying calls for things like migration? [03:08] the methods do permission checks [03:08] sigh, so many issues this week with people not reading their emails [03:08] well, been a bit busy [03:08] all facade methods are expected to have a permission check now [03:09] as a code review checklist step, that must be enforced [03:09] sometimes the check is done for the entire facade at construction time [03:09] if all methods require write for example [03:11] that hard coded list was also out of date - it omitted legitimate read only methods [03:11] so people were not maintaining it [03:14] wallyworld: great idea ^^ could u plz add it to our review checklist? https://github.com/juju/juju/wiki/Code-Review-Checklists [03:16] i thought it had been, i'll need to double check it [03:19] it's there :D "Do facades and methods have the required authorization checks? " [03:39] thumper: I'm late to the game but the colour output is pretty damn sweet [03:39] :) [03:39] ta [03:39] Bug #1614809 opened: api-caller remains post migration [03:50] thumper: thanks for review, i was also wondering about MODEL UUID [03:51] i started with CONTROLLER but thought it looked a bit wrong tbh [03:51] i can go with that and we'll get feedback i'm sure [03:53] i went with Controller because it's not a table header [03:54] wallyworld: axw: menn0:thumper: can u get to RB? === natefinch-afk is now known as natefinch [03:54] is reviews.vapour.ws broken for anyone else? [03:54] anastasiamac: nope [03:54] AccessDenied [03:54] just broke right now [03:54] ffs [03:54] yep. the same :( [03:54] broken for me [03:55] this test has defeated me. /EOD [03:56] katco: wow, you're on late [03:57] axw: wallyworld: I've cleaned up PR, PTAL https://github.com/juju/juju/pull/6023 [03:57] real soon [04:11] axw: my cunning plan to use the poolmanager has been poleaxed by an import cycle [04:12] stateenvirons [04:12] thumper: what about stateenvirons? [04:13] axw: I was trying to use it in migration_import and export [04:13] which are in state [04:13] thumper: yeah, you can't/shouldn't use stateenvirons from state. you also shouldn't need it [04:13] to get a NewStorageProviderRegistry [04:13] un moment [04:14] thumper: func (st *State) storageProviderRegistry() (storage.ProviderRegistry, error) [04:14] ah ha [04:18] axw: think I figured out a way to not expose the pool global key malarky [04:18] thumper: move the poolmanager code into state? :) [04:18] thumper: how? [04:18] you'll see [04:19] * thumper does more fixes [04:19] okey dokey [04:20] * thumper crosses fingers while tests run [04:21] axw: I think this last attempt will may you much happier [04:21] w00t, tests pass [04:21] now a bit of cleanup [04:24] axw: https://github.com/juju/juju/pull/6024 [04:26] thumper: yes, much nicer :) [04:40] wallyworld, axw, menn0: https://github.com/juju/juju/pull/6036 [04:40] not sure about the green for current actually [04:40] I was thinking something that "pops" a bit more [04:40] thumper: light blue? [04:41] * wallyworld is looking at another pr [04:42] menn0: not sure [04:42] thumper: LGTM to me anyway [04:43] gah... [04:43] * menn0 is tired [04:44] perhaps we land and bikeshed over color? [04:44] or make the color definable with an env var? [04:44] heh [04:44] * thumper out [04:44] so we're bikeshedding on what to bikeshed on now? === thumper is now known as thumper-afk [04:45] every time I look at gojsonschema it looks worse [04:45] wallyworld: pretty sure the ssh issue is another latent bug, woohoo [04:46] yay [04:47] wallyworld: the instance poller backs off when it sees a machine that isn't provisioned, doesn't start querying again immediately when it is provisioned === natefinch is now known as natefinch-afk [04:48] wallyworld: so it takes a while for it to kick back in, since the machines are taking around a minute to come up [04:48] i can beliebe that - the poller is independent of the provisioner [04:48] if only we had pubsub [04:49] wallyworld: nah it's just crappy implementation, it *can* react to the machine change [04:49] and I will fix it to do that now [04:49] ok [04:51] thumper-afk: I probably shouldn't tell you this but "less -R" will let you use less with colors ... could be interesting to integrate into debug-log [05:12] anastasiamac: latest pr is much smaller change set from the first one which is good; for some reason i find it easier to review on rb compared to github [06:06] Bug #1614835 opened: Unittest guiVersionSuite.TearDownSuite fails

[06:07] wallyworld: \o/ [06:07] wallyworld: also hosted arch is added so that we can validate upload tools.. [06:08] anastasiamac: but it's not an arch supported by the substrate [06:08] if you bootstrap from amd64 and try and run an arm64 controller that should break [06:09] when uploading tools, ther question to ask is - does the cloud and image i will be using to bootstrap on match the arch of my bootstrap client [06:10] adding host arch to the list of supported arches subverts that [06:10] wallyworld: let me clean up this pr and if this is the question to ask then validateuploadallowed is not asking it [06:10] wallyworld: i really need to land it, u can fix as an iteration. this fix fixes my bug [06:11] but introduces a new one [06:13] wallyworld: i dont see how it introduces new one - currnet behavior [06:13] it's not current behavour, that's the issue [06:14] if you try and upload tools from an amd64 client to a ppc64 cloud it will fail [06:14] or more so, from a s390 client to aws for example [06:15] if there is a test, then i will not b able to land my change. at this stage = all tests pass [06:56] wallyworld: PTAL, https://github.com/juju/juju/pull/6037 [06:58] wallyworld: BTW I was confused, we don't get updates on the machine doc in general; only lifecycle changes [06:59] so I've left it as polling for now, but changed it to only back off after it's been provisioned === mup_ is now known as mup === frankban|afk is now known as frankban [07:47] axw: yeah, that's why i was wishing for pubsub - could easily notify of such changes, looking now [07:56] axw: i think i'm reading the test wrong - it seems that prior to m.setInstanceId("inst-ance") we *want* case <-polled and thereafter not, but it seems the test is the other way around? [07:58] wallyworld: before setInstanceId, the test fails if <-polled. after, it fails if it times out waiting for <-polled [07:58] yeah, that's what's confusing me [07:58] before set instace id, machine is not provisioned so we want regular polling [07:59] so we'd expect to see,_polled, no? [08:00] wallyworld: perhaps the var name is throwing you off. <-polled means that it queried the provider for instance info [08:00] i was thinking polled was for querying instance addresses [08:01] which we want to do regularly until provisoned [08:01] wallyworld: and that hasn't changed, the only change is that there's no backoff. that's proven by the clock advancing exactly the "short poll" amount of time [08:01] wallyworld: nope, how would you do that without an instance ID? [08:01] good point [08:01] i haven't context switched in the code properly [08:02] lgtm though, i was was confused [08:02] hey folks, I'm getting an XML AccessDenied from reviewboard, anyone else? [08:03] mattyw: yeah, it's borked [08:04] wallyworld, awesome, hello by the way! [08:04] hey! [09:19] fwereade_: ping [09:20] voidspace, pong [09:21] fwereade_: txn-revno is maintained by the txn layer, so all I need to use it is to declare it in the doc. Right? Like this: http://pastebin.ubuntu.com/23069609/ [09:21] voidspace, so long as you *only* read that doc and don't write it, yes [09:22] voidspace, iirc accidentally writing a txn-revno can mess everything up [09:22] fwereade_: sounds like fun [09:22] fwereade_: http://pastebin.ubuntu.com/23069620/ [09:23] fwereade_: although I think that code should return no-ops if the hostports are equal (it doesn't currently do that either) [09:23] voidspace, +1 to that [09:23] kk [09:23] voidspace, and if you just declare that doc inside that func then you shoudl be safe from anyone accidentally writing it in future [09:24] yep [09:26] fwereade_: I don't think this particular contention problem is possible to test directly - other fixes we've committed didn't have new tests [09:27] fwereade_: so if the existing tests pass (checking that they're good tests of course) I'll call it good [09:27] currently they pass - just trying again with the NoOp path [09:29] voidspace, hm, surely you can test SetAPIHostPorts racing with itself at least? [09:29] fwereade_: I'm hoping there is already a race test :-) [09:29] maybe optimistic [09:31] voidspace, fwiw I can think of two: (1) BeforeHook change to a new value, check 2 txn attempts; (2) BeforeHook change to desired value, check 1 attempt only [09:32] fwereade_: understood [09:32] fwereade_: there's at least one concurrent test already [09:32] voidspace, cool [09:32] two - ConcurrentSame and ConcurrentDifferent [09:32] huh, access denied from reviews.vapour.ws [09:32] fwereade_: reading them [09:32] anyone else [09:32] voidspace, awesome [09:33] voidspace, the test names seem good, anyway ;) [09:33] fwereade_: yep, me too [09:33] mgz, I think of you as the person who effortlessly fixes everything, is that something you can address? ^^ [09:34] All current tests pass, that's a good sign [09:51] how to know if juju is using the default tools or the tools that I specified ? [09:52] this means it's using the deafult? [09:52] https://paste.ubuntu.com/23069672/ [09:53] cmd is juju bootstrap maas maas --debug --show-log --config agent-metadata-url='192.168.122.157/toolsdir/tools/' --bootstrap-series='trusty' [09:53] anyone? [10:15] hoenir: looks a lot like its using the default [10:17] perrito666, how can I use my own tools? [11:43] Bug #1614929 opened: Panic when destroying controller [11:57] voidspace, if you have a moment, https://github.com/juju/juju/pull/6040 [11:57] voidspace, the critical thing is really to QA it, and come to a conclusion re the JustRemoveOp(..., -1); everything else has been reviewed in detail by many people [12:02] fwereade_: about to go on lunch - can look after that [12:04] voidspace, cheers [12:46] Bug #1614929 changed: Panic when destroying controller [12:46] Bug #1614948 opened: cmd/juju: "error" capitalisation is inconsistent

[12:56] natefinch-afk: ping if you're around === natefinch-afk is now known as natefinch [13:27] jam: pong [13:28] tha lag [13:29] mgz: could you kick reviewboard server? [13:31] Bug #1614961 opened: juju ssh to azure hosts fails

[13:40] perrito666: I don't think I can [13:40] mgz: I think you do :p [13:40] that is one of CI machines, I am sure of it [13:41] well, I guess I do have ssh access, just not the management creds [13:41] or you can provide me access+sudo and Ill gladly dig into the pile of... code [13:41] so i can poke around at least [13:41] perrito666: you have it [13:41] mgz: oh [13:42] cloud-city and ssh with the staging-juju-rsa key [13:44] hm, proxy error spam [13:44] why is it even trying to access /releases/unknown-outcome [13:46] Bug #1614961 changed: juju ssh to azure hosts fails

[13:48] hmmm... reviewboard is borked again [13:50] yeap, not sure what the fix is [13:51] voidspace: looking into it [13:51] perrito666: thanks [14:00] natefinch voidspace ping for standup [14:00] rick_h_: omw [14:07] perrito666: voidspace I am going to reboot review board. the services are healthy. I think the host or the proxy have thrown a wobbly [14:09] sinzui: much appreciated [14:10] voidspace, frobware: Could you take a look at this please? (github link since there's no RB link) https://github.com/juju/juju/pull/6042 [14:10] babbageclunk: I think my review plate is full until EOD I'm afraid [14:11] voidspace: :( [14:11] babbageclunk: I have two to do and I want to leave and go to mountains, sorry [14:11] voidspace: Well, at least it's not just on my hard drvie now! [14:11] babbageclunk: haha, yeah - ice [14:11] I mean *nie [14:11] *nice dammit [14:11] fat fingers [14:11] voidspace: That's wjat I meant too. [14:11] babbageclunk: new SSD or repaired computer yet? [14:12] ERROR invalid config: lxd version 2.1, juju needs at least 2.0.0 [14:12] anyone seen that - is it fixed on master? [14:12] voidspace: using a loaner that Rodney gave me - it's a beast! 8 cores and 32Gb [14:12] I guess I can check master... [14:12] babbageclunk: wow [14:13] voidspace: test runs are nice and quick. Not much fun biking home with it though. [14:13] babbageclunk: yow [14:13] yeah, I bet [14:23] with juju/errors, how can i retrieve the underlying error if it has been Wrap(..)ed [14:34] * katco crosses fingers and does a full test run of cmd/juju/application [14:37] * rick_h_ looks for a chicken to sacrifice to the test run gods, but finds none [14:37] katco: if you want the original error, you can get Cause(err) ... if there's N wraps, that gives you the first one, if you want the N-1th one, I'm not sure you can [14:37] natefinch: hm, that didn't seem to work [14:38] natefinch: i'll sanity check and try again after this run is done. didn't get much sleep [14:38] katco: oh, wrap, yeah... [14:39] wrap changes the cause to the new error [14:39] you want Underlying() [14:40] hm, i thought i tried that too [14:41] i think it just gave me back the wrapped error or something. i probably screwed it up [14:42] it might that if it's wrapped and then gets annotated, you lose access to the underlying error [14:43] ahhh that is almost definitely what's going on [14:43] in theory you're not supposed to need to know what the underlying error is [14:43] so this was inflicted by my own hand. a very techy error was making it out to the cli, so i wrapped it. mask and annotate still leak the techy error [14:43] katco: can you also look at natefinch's PR please. In the bug is a direct link to the .sh script to QA with and get the security report which should work against a lxd deploy I htink. [14:44] natefinch: actually, no, the full history is still in the error because i can gc.Matches on errors.Details(err) [14:44] natefinch: I'm assuming you've done this as well to make sure it works [14:44] rick_h_: ok [14:45] not bad: OOPS: 204 passed, 1 PANICKED, 1 FIXTURE-PANICKED, 1 MISSED [14:45] that's down from hundred failing/panicing [14:45] katco: <3 [14:46] rick_h_: I haven't, actually. I should do that. [14:46] I'm sure it'll pass, since I hand-wrote the list of ciphers we support, but it would be good to verify with the tool they're using [14:46] natefinch: rgr, it's what the bug is filed with so if we don't pass the tool, the bug reportor will come back at us. [14:53] Bug #1614724 changed: Juju isn't protected from new versions of LXD

[14:53] Bug #1614992 opened: Cannot assign unit: unable to connect

[15:08] lol, I've forgotten how to bootstrap 1.25 [15:09] not sure i've done that myself in awhile [15:10] you have to switch environments first and then juju bootstrap without specifying the environment [15:10] but now it's saying no registered provider for lxd, which is weird [15:10] lxd is a 2.0 thing haha [15:11] believe it or not. it's been that long [15:11] lol [15:11] wow [15:11] have to use local i think? or lxc [15:11] lcoal yeah [15:11] lulz [15:12] and gce panics during bootstrap with a nil pointer [15:13] oy [15:13] wtf? on latest in 1.2x? [15:14] yep. I'm guessing it's this line: [15:14] // The missing credentials will be caught later. [15:14] return nil, nil [15:14] oh, they were caught all right [15:15] sigh... please raise a critical bug. gce flat out not working is a huge deal i imagine. rick_h_ ^^^ [15:15] it's an edge-ish case, I think. my config specifies a credentials file that apparently isn't there [15:15] lemme double check if that's the problem [15:16] ah [15:16] that would make me feel loads better [15:17] no, that's not it. Sorry, let me figure out exactly what's causing it [15:17] i hope it's an edge case [15:19] yeah, my config is all messed up. wrong property names and stuff. Possibly from very very early in gce lifetime [15:20] Let me attempt to fix it and double check gce works, but I'm pretty sure that's it [15:23] Bug #1615008 opened: jujud uses max cpu cores 100% overnight [15:31] ahhh..... this is not a helpful error message: ERROR there was an issue examining the environment: invalid config: key "project_id" not supported [15:31] what environment? what config? where? [15:32] natefinch: like ~/.juju/environments.yaml under "local" [15:32] likely [15:32] yeabut.. that key doesn't exist there [15:32] and I don't have JUJU_HOME set [15:33] * rick_h_ runs to long family lunch today biab [15:33] or any JUJU_* variable, actually [15:33] grep -r project_id ${HOME} [15:34] yeah, just started running that. gonna be a while [15:35] funny seeing it pick up javascript in my browser cache [15:37] Skills: 5+ years of Agile, Scrum [15:38] oh recruiters [15:39] MUST have long projects and long time in US [15:39] ...what does that even mean? [15:39] natefinch: wrong channel? [15:39] nope [15:40] recruiter sent me an email for a .Net job. [15:40] probably means they wont do the h1 for you [15:40] We are looking to fill a contract opportunity with one of our direct customers and like to check if you have any resources available for the same. Please submit the resume with rate, contact details, and availability. Kindly note that each resource submitted must be on your W2 payroll. [15:40] i once had a recruiter attempt to recruit me to my old company [15:41] what's a w2 payroll? [15:41] "must have long projects, must not have long hair" [15:41] W2 is the form a business uses to report your income to the government (and to you) [15:42] it sounds like this was half rewritten from something sent to a contracting company [15:42] Job Title : Superstar .Net Technical Lead/Architect (strong SQL) (Chi)-multi-year contract (long projects) [15:42] yeah, they seem to think you are an owner of resources [15:43] I thought owning such resources was sort of illegal [15:43] for at least a couple of hundred years? [15:43] haha [15:43] you don't own them, you just rent them out [15:46] morning [15:46]