[00:39] wallyworld: any word on the oracle provider not listed anymore? [00:39] s/provider/cloud [01:52] menn0: any chance of a review on https://github.com/juju/juju/pull/7278? [01:55] axw: looking [02:05] axw: done [02:06] menn0: awesome, thanks [02:35] menn0: I've simplified the SetSSHKeys as suggested, but left the other one alone. can you please see if my reply is reasonable? [02:37] axw: all good, thanks. merge away [02:37] menn0: thanks [02:41] babbageclunk wallyworld: ready whenever you two are [02:41] righto [02:42] * thumper unpicks convoluted code [02:43] axw: i'll see you in HO once babbageclunk pings back [02:43] okely dokely [02:44] Sorry guys, was on the phone, finished now [02:45] axw, wallyworld: ^ [02:57] hmm... [02:57] wallyworld: do you have 5 minutes? [02:57] this code looks and feels wrong [02:57] and I want to double check [02:57] thumper: sure, just otp with andrew and xtian, soon? [02:57] sure, ping when done [03:44] thumper: free now [03:44] wallyworld: 1:1 [04:00] thumper: sorry, cut you off [04:01] nm [04:01] was just going to ask if you were ready for karaoke next week [04:23] wallyworld: axw: do u know if this is something expected? https://bugs.launchpad.net/juju/+bug/1686585 [04:23] Bug #1686585: Juju deploy via UI fails on Azure [04:24] anastasiamac: nope [04:24] axw: :D 'nope' = dunno or 'nope'='not expected'? [04:24] you mean is a failure to dpeloy expectedz? [04:24] anastasiamac: not expected. it's a bug. [04:25] what wallyworld said. it would be pretty odd for a basic deploy of mariadb to be expected to fail [04:25] wallyworld: yes, mayb under some circumstances we know there could b failures.. kind of like under some circumstance we know we have difficulties ;) [04:25] us? never :-) [04:26] axw: wallyworldyes. this was my expectetation too.. just finding way to flag to u - 'failure' :D [04:27] * wallyworld saw the bug [04:28] anastasiamac: I'll have a look into it after I'm done landing ssh things [04:28] also gotta do some azure auth changes [04:29] axw: awesome \o/ [04:54] wallyworld: fyi, there are other tests that make sure you can only use --force with --series [04:54] so ... whatever [04:55] i should have remembered that [04:55] been a while [04:55] so... [04:55] much of that other code is bollocks [04:55] because it is only valid if force is true and series is passed in [04:55] yeah [04:56] oh well [04:56] maybe we intended to allow --force without series at one point [04:56] so... the LTS case will never happen [04:56] yeah... [04:56] maybe [04:56] I'll leave it that way for now... [04:56] but perhaps we should look to fix it later [04:58] yep [04:58] I'll leave a note [05:08] wallyworld: https://github.com/juju/juju/pull/7285 [05:08] looking [05:10] babbageclunk: for tomorrow when you start your day and can't face writing code straight away https://github.com/juju/juju/pull/7286 [05:12] wallyworld: I mean, I guess it's net deletion so should be easy right? [05:12] supposedly [05:13] cut and paste [05:13] 99% of it [05:13] i am still finishing the hand testing [05:14] thumper: lgtm, just a minor niggle [05:15] ta [05:17] axw: you have snap install go? [05:18] anyone cares if i self-approve a typo fix? https://github.com/juju/juju/pull/7287 [05:18] approved [05:21] thumper: \o/ tyvm! [05:22] thumper: yes I have [05:22] axw: what do you do about gofmt? [05:22] I'm still on 1.6, so I'll move to using the snap [05:23] thumper: nothing yet, but you can add /snap/go/current/bin to $PATH. gofmt is in there [05:23] it's just not exposed in /snap/bin [05:23] ah [05:23] right [05:23] or I may just symlink from ~/bin because that's in my path already :) [05:23] did you remove the golang package? [05:24] or did you have go from source? [05:24] wallyworld, menn0: either of you move to the snap from the deb? [05:24] thumper: depends on the machine. I was mostly building from source before [05:24] just took it out of my path [05:24] thumper: same for me [05:24] i'm still using deb [05:25] I'm just thinking since /snap/bin is at the end of my PATH [05:25] I'll probably have to remove the deb [05:25] actually, i've got a symlink to /snap/bin/go [05:26] this is my first snap apart from the live patch [05:26] :) [05:28] heh... [05:28] go 1.8.1 from 'mwhudson' installed [07:26] anastasiamac: actually, that azure bug has been fixed in 2.2. so I guess it is expected after all :) [07:26] * axw goes to find the bug # [07:27] axw: nice :) so it's a dupe? these are the best :) [07:34] anastasiamac: not exactly, just happened to be the same underlying issue [07:34] anastasiamac: I've just linked it a comment and marked Fix Committed [07:41] wallyworld: hiya [07:42] hi [07:42] wallyworld: i just ran across a line of code that does nothing, and was wondering if it is intended to do something... [07:42] wallyworld: just asking before i delete it :) [07:42] sure [07:42] wallyworld: (and your name is on it) [07:43] wallyworld: the line is url.Source = "" [07:43] wallyworld: in cmd/juju/crossmodel/show.go [07:43] wallyworld: around line 66 [07:44] wallyworld: was the intention to remove the source from the string set in c.url ? [07:44] rogpeppe: it doesn't do nothing does it? it sets the Source to empty [07:44] wallyworld: except it sets it in the local url variable which is immediately discarded [07:45] wallyworld: unless ParseApplicationURL returns a reference to some persistent value, i guess [07:45] oh i see, no that's a bug [07:45] but that line will never execute right nw [07:45] I don't think, as source will always be "" from memory [07:45] wallyworld: why not? it's not possible to specify a source? [07:45] it's for when we support cross controller cmr [07:46] the CLI won't let you [07:46] we only support single controller cmr for now [07:46] wallyworld: at a quick glance, it looks like the url parsing code does support returning a source [07:46] the Source attr is there for futyre use [07:46] it does [07:47] but the CLI errors from memory [07:47] wallyworld: so someone *could* type in a url with a source [07:47] if you try and create an offer an a different controller to the current one [07:47] they could but the CLI won't let the get very far [07:47] this is all WIP [07:47] behind a feature flag [07:48] wallyworld: ok. shall i just remove that line then? [07:48] yeah, or i'll fix it as a drive by [07:58] babbageclunk: pong [07:58] babbageclunk: timezones suck.. [07:59] wallyworld: thanks - i've removed it for now [07:59] rogpeppe: no worries, thank you [08:19] wallyworld: did you say something about QA tools and such being moved to git? [08:27] axw: no [08:27] i asked heather to file a bug for a CI change [08:32] wallyworld: ok [08:33] it would be nice if all our things were together [09:09] jam: https://pastebin.canonical.com/186915/ does this look OK to you? Or do we want something more there? === salmankhan1 is now known as salmankhan === frankban|afk is now known as frankban [10:29] wpk: looks like a good start. [10:32] wpk: as we discussed, its probably better to start with a minimal interface that is actually all in use and then grow it as we need to [12:06] wallyworld: axw: ping if you're around [12:14] jam: i am somewhat [12:14] wallyworld: so I'm looking through some of the facade registries, and we're registering the *same* object with multiple versions [12:14] how can that be correct? [12:14] if we had the same object, we didn't need a version [12:15] if we changed the object, then we're violating the old api by exposing it with the new object [12:15] they're not supposed to be the same - new or changed apis are there [12:15] which one? [12:16] all of them that I saw [12:17] oh application [12:17] wallyworld: I just sent an email about Application [12:17] but also SSHClient [12:17] and others, IIRC [12:17] from memory, application facade adds new methods [12:17] MachineManager [12:17] so the version 3 does use the same object as v4 [12:17] wallyworld: but it *shouldn't* [12:17] but v 3 clients don't see the new metjhod [12:17] wallyworld: it means we're exposing the new method on the old version [12:17] and things like libjuju [12:17] will expect it [12:18] wallyworld: they *see* it, they just don't know to ask for it [12:18] but something like libjuju will create code that will *fail* against old versions [12:18] because it expects the api to be there, because 'develop' says that it is [12:18] that is something that wasn't apparent at all at the time [12:18] it all works with juju's versioning mechanism [12:19] but if libjuju imposes other restrictions, we'll meed to change [12:19] wallyworld: if you have (4, NewMethod), with the code written there you will also have (3, NewMethod) [12:19] sure, but v3 juju clients won't see it [12:19] wallyworld: again, if they ask, they see it [12:19] its there [12:19] it can be called [12:19] its exposed [12:19] and nothing breks [12:19] you're just assuming nobody ever inspects the api [12:20] if they inspect it they can use it though [12:20] they use what they see [12:20] wallyworld: but then they write code against a version of Juju and it breaks against the real version [12:20] wallyworld: the point of a versioned API is to *not change* the old version [12:21] that is true. the assumption was that a it worked for juju clients so would have been ok [12:22] I'm also a bit surprised we've managed 4 revisions of Application with only 2.0, 2.1 and 2.2 [12:22] not sure where the extra version comes in [12:22] we reved the facades when we went to 2.0 [12:22] to avoid 1.x clients accidentally calling 2.x facades [12:23] so 2.0 juju started with v2 application facade [12:24] i guess we should fix the facades for 2.2 [12:24] wallyworld, jam: i'm about to move cookie jars into the jujuclient.ClientStore interface so we don't get tests accidentally creating cookie files. does that seem reasonable to you? [12:25] rogpeppe: I don't quite have the context to immediately say yes/no, but I'd really like us to move cookie jars to be less of a 'global' thing [12:25] so steps in that direction sound goo [12:25] good [12:25] jam: yeah, that's what i'm working on currently [12:25] jam: cookie jars will be per-controller [12:25] i guess it will be a new embedded interface [12:26] wallyworld: CookieJar(controllerName) http.CookieJar [12:26] wallyworld: or something like that [12:26] that's the method, a new interface as well [12:26] to follow the pattern already in place [12:27] where ClientStore is composed of other interfaces [12:27] wallyworld: yeah, i guess so [12:27] wallyworld: type CookieStore interface {CookieJar(controllerName string) http.CookieJar} [12:28] sgtm, ty [12:28] wallyworld: actually, the returned jar needs a Save method, but otherwise the same as http.CookieJar [12:29] ok [12:37] rogpeppe: you did the work to allow Runner.Worker() to return the underlying worker? [12:37] jam: yeah [12:38] rogpeppe: bug #1686711 I'm trying to track down our test suite getting a nil panic [12:38] Bug #1686711: panic() during lease manager [12:38] and it *might* be that Worker() is returning nil without returning an error [12:38] jam: you can't reproduce it? [12:39] rogpeppe: its a random test failure [12:39] rogpeppe: my guess is that we happen to call a leadership function at exactly the right time while something else is tearing down [12:40] jam: i'm pretty sure that the Manager instance isn't nil [12:40] jam: if that's what you're thinking [12:41] rogpeppe: well, Secretary pretty much can't be nil and 'config' isn't a pointer [12:41] (all places that create it in our code pass in a Config with a valid Secretary [12:42] if workerInfo.worker was nil it would get returned [12:42] as long as workerInfo was there [12:43] jam: the stack trace shows that the first argument (the receiver) is non-nil [12:44] jam: how often is this happening? [12:44] rogpeppe: not sure, it just rejected a merge request [12:44] but nil panics in code are serious so worth investigating so that we know they aren't production issues [12:44] jam: you've seen it before? [12:45] rogpeppe: I have not, but it certainly isn't my code that is changing this [12:45] rogpeppe: and unless you're going with "bit flips due to cosmic rays" its a latent bug in our code [12:45] jam: indeed [12:47] rogpeppe: so the stack trace, Claim() only takes 3 arguments and is a method, but the stack trace shows 8 parameters to the function [12:47] rogpeppe: is it expanding 'string' objects ? [12:47] jam: yeah, that's right [12:48] rogpeppe: time.duration is only an int64, they're still too many parameters [12:48] jam: args in turn are: receiver, str ptr, str len (9), str ptr, str len (11), duration (60s) [12:48] rogpeppe: there are still 2 more [12:48] jam: i don't think the stack-printing logic knows how many args there are [12:50] jam: given that args 2-6 look plausible, i think the first one is probably correct [12:50] some of them have ... and some don't so it seems it might know something [12:50] rogpeppe: anyway, i'm happy to agree that the receiver is probably not nil [12:53] jam: it looks like another string at the end. [12:53] rogpeppe: indeed, but not sure where that is coming from [12:53] NewManager calls config.Validate() to make sure config.Secretary != nil [12:53] I haven't found any code that changes the Secretary at runtime [12:56] rogpeppe: we *have* seen a different nil pointer panic in one of witold's submissions, wpk, do you remember which? [12:56] Sec [12:56] 10722 [12:56] jam: BTW I'd suggest that you set GOTRACEBACK=all in your CI setup [12:56] I added it to the bug [12:56] http://juju-ci.vapour.ws:8080/job/github-merge-juju/10722/artifact/artifacts/xenial.log this one [12:56] rogpeppe: its the same failure [12:56] jam: then you'd be able to tell which test was running [12:57] rogpeppe: that one has 0x0 0x0 as the last two params [12:57] feels a bit like 'print the stack that might happen to still have stuff on it' [12:57] jam: yeah, i think it probably is [13:00] jam: FWIW http://paste.ubuntu.com/24466503/ [13:01] jam: same thing when it's called through an interface [13:02] jam: i'd suggest setting GOTRACEBACK=all and waiting for it to happen again [13:06] jam: this kind of thing will be better in go1.9 - we're getting column positions on error messages [13:11] jam: i'm certain that Secretary is nil. look at this: http://paste.ubuntu.com/24466590/ [13:12] jam: it faults on exactly the same address (0x30) [13:12] rogpeppe: you're saying that would be the offset of the function we're calling? [13:12] jam: i suspect something is using an uninitialised Manager somewhere [13:12] jam: no, that's the address it's trying to get a value from [13:13] jam: it's probably the offset into the interface value of the CheckLease method [13:13] jam: or of the method table [13:18] jam: ok, i know what's going on [13:18] jam: and it's all my fault :) [13:19] jam: i'm not quite sure what the best fix is though [13:22] jam: actually, not too hard to fix. i'll raise a bug for it. [13:22] wpk, jam: actually, is there an existing bug report for this? [13:28] rogpeppe: https://launchpad.net/bugs/1686711 [13:28] Bug #1686711: panic() during lease manager [13:28] rogpeppe: what is the bug? [13:28] well, what is the underlying issue/ [13:28] ? [13:28] jam: ha! you sent that message at *exactly* the same time i clicked on Submit on https://bugs.launchpad.net/juju/+bug/1686720 [13:28] Bug #1686720: worker/lease: NewDeadManager returns manager that crashes [13:29] jam: i'll leave it up to you to decide which one to go with :) [13:29] jam: i need lunch [13:33] smacznego [13:34] rogpeppe: I'll mark a duplicate [13:35] rogpeppe: I went with yours [13:36] since it explains what is actually wrong === akhavr1 is now known as akhavr [14:30] hi guys, i need a fast help i could not find in the docs. basically is there something like juju resolved for "machines" instead of units? [14:31] i have juju with maas, it tried to deploy some apps on a machine, but, due to wrong tags, juju could not get a machine. now i fixed the tags and i would like to tell juju "try again" or juju add-machine and relocate units to the new machine [14:38] Hetfield: so there's a retry-provisioning command that might help you there [14:39] Hetfield: check out the command reference here: https://jujucharms.com/docs/2.1/commands (basically juju retry-privisioning --help) [14:39] rick_h: thx but it's not working [14:40] machine-status: current: provisioning error message: 'cannot run instances: cannot run instance: No available machine matches [14:52] rick_h: now i manually added a new machine. any way to tell juju to move all units to new machine? because they are 4 lxd so i need to manually add them, so boring [14:53] Hetfield: no, unfortunately there's no migration path/tool there [14:53] ok i'm going to open a bug for this so [15:45] i just opened https://bugs.launchpad.net/bugs/1686767 [15:45] Bug #1686767: juju lacks manual unit relocation on new machines (retry-provisioning not working) [15:46] hope you can give some love :) [15:58] ty Hetfield [21:08] babbageclunk: ping? [21:29] wpk: hey - still around? I was just wondering if you'd had an answer to your API versioning question [21:35] babbageclunk: Yes, around, and yes [21:35] babbageclunk: there was quite a discussion about it today, as e.g. application API presents 4 versions using the same struct [21:35] 4 API versions with the same API [21:35] wpk: oh cool - I figured you probably would have given that it was yesterday [21:36] babbageclunk: timezones sucks... [21:36] wpk: weird! [21:36] everyone should be on CET! [22:00] wallyworld: ping, could you please take a look at https://github.com/juju/juju/pull/7290 . it is a change to the gui handler code that you helped implementing [22:01] frankban: sure, otp but after that [22:01] wallyworld: thanks, and have a good day [22:04] you too [22:05] balloons: oracale call just finished. what's the tl;dr; on the release? === frankban is now known as frankban|afk === mup_ is now known as mup [22:14] wallyworld, seems we can ship 5177 [22:14] awesome [22:16] wallyworld, anastasiamac, axw: now that we require Go 1.8 our install instructions in README.md and CONTRIBUTING.md might give people trouble (as per bug 1662857) [22:16] Bug #1662857: cannot go get the source code [22:17] people are most likely to have Go 1.6 installed and when they do go get -d -v github.com/juju/juju/... it'll fail [22:17] i'm thinking we should change the instructions to tell people how to get Go 1.8 first [22:17] and then direct them to do go get -d -v github.com/juju/juju/... [22:18] I also think the "install-dependencies" make target then shouldn't install Go for people [22:18] thoughts? [22:26] menn0: sounds great - feel free to update ;) [22:26] anastasiamac: I will. just wanted some concensus [22:26] menn0: since we r taking 5177 as per balloons ^^ for beta3, this will end up on beta4 [22:27] menn0: well, u have my +1 - anythign to improve docs and user experieneces [22:27] thumper: repeating in a summarised way for thumper. [22:27] we now require Go 1.8 [22:27] thumper: can we talk now-ish? [22:27] morning [22:27] yeah [22:27] people are likely to have Go 1.6 installed [22:28] this means our instructions of go get github.com/juju/juju/... in the README and CONTRIBUTING docs will fail for them [22:28] thumper: I'd like to change the instructions to tell people how to get Go 1.8 first [22:28] and then get them to pull the code [22:29] also change "install-dependencies" target not to install Go [22:29] thumper: sound ok? [22:32] thumper, anastasiamac : oh man... some of the instructions in the README as Juju 1.x specific [22:32] embarrassing [22:32] heh [22:50] menn0: yeah :( i think noone looked at the full contents of these files in a while... I've lloked at one paragraph recently... but did not have a chance to have a comprehensive scan/update... [22:50] menn0: thank you for doing it ;D [23:25] menn0: (hours later) sounds fine to me [23:26] axw: cheers [23:26] wallyworld: take a look at the tiny PR here? https://github.com/juju/juju/pull/7291 [23:26] sure [23:27] wallyworld: Once we're happy with that I'm tempted to try implementing the API code that will use the methods first. [23:29] axw: oh, you're up! Could you look at ^ as well to check it matches your thinking? [23:29] babbageclunk: okey dokey [23:29] ta! [23:36] babbageclunk: you certainly could implement th api methods which use IsRouteable [23:36] how can daylight savings changes feel so confusing for so long? [23:57] thumper: oh, this one looks to be not-quiet-fixed :( https://bugs.launchpad.net/juju/+bug/1680392 [23:57] Bug #1680392: Model migration fails on large model