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