[00:37] <alexisb> anastasiamac, ping
[00:37] <alexisb> if you are around we can hope on the release standup
[00:38] <anastasiamac> alexisb: tyvm! see u there
[01:15] <veebers> axw: to clarify for myself, you want to get this landed for the coming release right? https://github.com/juju/juju/pull/5877
[01:18] <wallyworld> veebers: technically, we are down to critical fixes only. if we get a good CI run, maybe this could land then and we could use it if CI passes, but have the fallback of a good run with all criticals fixed
[01:21] <veebers> wallyworld: right, I'm checking so I know the timeline expectations for getting this in. i.e. if I ping about it tomorrow mornings standup it'll probably be to late to be included in the release. But sounds like that's ok?
[01:21] <wallyworld> veebers: yeah, i think they want to start the release their thursday, so too late
[01:21] <wallyworld> we have stuff queued up to land post beta
[01:22] <veebers> wallyworld: cool. I'll get it sorted today/tomorrow
[01:22] <wallyworld> sounds good, ty
[01:23] <axw> veebers wallyworld: yeah it doesn't have to go into this release, it's just been dragging on for a while now, and needs to get sorted
[01:24] <axw> veebers wallyworld: sooner we address the better, because it's a change for users to adapt to. we may need to iterate on syntax based on feedback
[01:24] <wallyworld> yep
[01:24] <veebers> ack
[01:24] <wallyworld> axw: we can do a snap :-)
[01:25] <axw> wallyworld: true :)
[01:25] <wallyworld> well, as soon as I get a bit more sorted out
[01:25] <veebers> axw: re: http://bazaar.launchpad.net/~axwalk/juju-ci-tools/cli-model-owner/revision/1523/utility.py can you give an example of what model_name being passed in would look like and what the expected return output would be. I'll branch that and get unit tests written and propose it etc.
[01:26] <axw> veebers: e.g., "admin@local/default"
[01:26] <axw> or just "admin/default"
[01:27] <axw> veebers: and thanks
[01:27] <veebers> nw
[01:32] <axw> anastasiamac: can http://reviews.vapour.ws/r/5341/ be closed?
[01:33] <anastasiamac> axw: yes. let's :) I'll re-PR when ready :)
[01:33] <axw> thanks
[01:33] <anastasiamac> axw: done
[01:40] <wallyworld> axw: does the diff for "environs: update API for hosted models" include the work from the dependent PR. I think it does? So easiest to review once that other PR lands and it can be rebased?
[01:40] <axw> wallyworld: it does, but the RB diff should just show the delta
[01:41] <wallyworld> really? even if proposed against master? ok
[01:41] <axw> wallyworld: yeah, you can do that with "rbt post -r <RB review ID> --parent <parent git branch>"
[01:41] <perrito666> mm, what was the way to tell mongo to ve Trace level verbose?
[01:42] <perrito666> s/mongo/juju
[01:43] <wallyworld> axw: nice. where does RB review ID come from? that implies you propose via github PR, and the issue that post with the newly created id?
[01:43] <axw> wallyworld: yes that's I do. create the PR, the bot creates the RB review (ID is just the number in the URL), then you pass that to the tool
[01:44] <wallyworld> axw: and the initial step is to branch off the upstream branch right? instead of branching off master
[01:45] <anastasiamac> axw: i do not want to continue crossing swords on this review. Could u plz double-check outstanding issues so that we can progress its landing? http://reviews.vapour.ws/r/5360/
[01:51] <perrito666> is the all team meeting happening? I somehow presume that its the exact same group of people than the standup
[01:52] <anastasiamac> perrito666: m all for team meeting. there are some updates around bug and release mgmt that can b communicated better. there is criteria stuff that i'd love to talk about :)
[01:52] <anastasiamac> perrito666: and there is always nice dueling to witness
[01:52] <anastasiamac> perrito666: also would love to touch base re: review process
[01:53] <anastasiamac> perrito666: oc, i might b dreaming and noone will join me again.. in which case, I'll just tlak to myself ;)
[01:59] <axw> anastasiamac: I don't really think splitting that test is worthwhile. it's one of the cases where I think a table-driven test would be fine
[01:59] <anastasiamac> axw: as an OCR, m happy to go with ur opinion
[02:02] <anastasiamac> axw: thumper: menn0:perrito666: team meeting
[02:02] <anastasiamac> natefinch: ^^
[02:36] <axw> wallyworld: I think we should stop showing bootstrap-config in "show-controller" by default (maybe not at all?)   what do you think?
[02:36] <axw> wallyworld: now that bootstrap config contains all the defaults, it's taking up a lot of screen space
[02:37] <wallyworld> axw: yeah, not much point. what we *should* show is controller config
[02:38] <axw> wallyworld: hmm is that going to be dynamic? will we have commnads to update it?
[02:40] <wallyworld> axw: so far, it is mongo port, api port which are static, plus numa setting, which i guess could be dynamic. and there is already a bespoke get-controller-config command. so yeah, just remove bootstrap config i reckon
[02:40] <axw> wallyworld: ah I thought you meant inherited config. okey dokey
[02:40] <wallyworld> s/remove/not show
[02:40] <wallyworld> axw: there's a juju model-defaults to show inherited config
[02:41] <axw> wallyworld: think it's worth having a flag to show? I'm not sure it was even asked for, I think I just added it there
[02:41] <wallyworld> i wouldn't add to the complexity by even having a flag - just not show IMO. people don't really need to see it and it's only there for kill-controller and restore -b
[02:41] <axw> wallyworld: cool, SGMT
[02:41] <axw> SGTM*
[02:42] <axw> wallyworld: btw I've just bootstrapped AWS with region, access-key and secret-key removed from model config
[02:42] <axw> finally got there
[02:42] <wallyworld> \o/ ^ 100
[02:42] <wallyworld> awesome sauce
[02:43] <wallyworld> that deserves a beer or two
[02:43] <axw> wallyworld: should be able to drop region from restricted config and add a model in another region now too, I'll try that at the same time
[02:43] <wallyworld> whohoo
[02:44] <wallyworld> assuming networking is set up so the model can talk to the controller
[02:44] <wallyworld> not sure what's involved there
[02:44] <wallyworld> may need to specify a vpc id?
[02:44] <axw> wallyworld: it works because it goes over the internet
[02:44] <axw> public IPs
[02:44]  * axw tests
[02:45] <wallyworld> ah right. we should look to fix it so it doesn't have to, or document how to at least
[02:45] <axw> wallyworld: why?
[02:46] <axw> wallyworld: traffic cost?
[02:46] <wallyworld> yep, plus efficency
[02:46] <wallyworld> maybe port exposing / security groups would prevent it also if it is external traffic?
[02:46] <axw> wallyworld: I'd like to think that AWS knows how to route those addresses efficiently. don't know about the cost side
[02:47] <wallyworld> not sure that AWS does that sort of short circuiting
[02:47] <wallyworld> could be wrong
[02:47] <axw> wallyworld: anyway, I now have a controller in AWS with machines in two regions :)
[02:47] <wallyworld> awesome :-)
[02:47]  * axw goes to make a cup of tea to celebrate
[02:47] <wallyworld> but IMO we need clear guidelines on how to set up
[02:48] <wallyworld> add some rum to the tea
[02:48] <axw> wallyworld: what do you mean? there's no setup. just bootstrap, then add-model --region=foo
[02:48] <wallyworld> networking
[02:48] <wallyworld> how to avoid external traffic etc
[02:48] <wallyworld> will be provider specific
[02:49] <axw> wallyworld: ok. yes, if/when we change that to not go over hte internet
[02:49] <wallyworld> maybe we guide them to a suitable space set up etc
[03:33] <veebers> wallyworld: re: log forwarding, just adding a model wouldn't be enough to get that models logs forwarded to the controller right? It'll need to do some <action> for that to trigger a forward?
[03:34] <veebers> (this is in response to an email from you from a wee while ago)
[03:35] <wallyworld> veebers: i think log forwarding needs to be enabled on the controller model, and then yeah the hosted model needs to log somethong
[03:36] <veebers> wallyworld: I have the basic forwarding stuff (i.e. controller forwards it's logs). What action would generate a log from the model that would be forwarded?
[03:37] <wallyworld> veebers: just the act of adding the model - it will log worker startup etc
[03:38] <veebers> wallyworld: interesting. I'm not seeing that forwarded but I might be doing something wrong. I'll continue digging
[03:38] <wallyworld> you see the controller model logs ok though?
[03:38] <wallyworld> just not hosted model logs
[03:39] <veebers> wallyworld: correct
[03:39] <wallyworld> hmmm, it may be that it's only enabled for the controller, i'd need to check
[03:39] <wallyworld> give me a few minutes
[03:39] <veebers> wallyworld: awesome, cheers
[03:46] <thumper> menn0: http://reviews.vapour.ws/r/5369/
[03:55] <wallyworld> axw: doing a rb post, what username/password did you use?
[03:56] <wallyworld> since i normally sign into rb using github sso
[03:57] <menn0> wallyworld: you use oauth with rbt too
[03:57] <menn0> wallyworld: see the bottom of reviewboard.md in docs/contributing
[03:58] <menn0> docs/contributions
[03:58] <wallyworld> menn0: ta
[03:58] <menn0> thumper: looking
[04:09] <menn0> thumper: review done
[04:09] <thumper> menn0: ta
[04:09] <menn0> thumper: did you try reproducing using enable-ha?
[04:09] <thumper> menn0: I did, wasn't able to reproduce
[04:10] <thumper> menn0: btw, are you taking the piss?
[04:10] <menn0> thumper: I guess it's somewhat timing dependent
[04:10] <thumper> "errorCoder" ?
[04:10] <menn0> thumper: slightly :)
[04:10] <menn0> thumper: only because I knew it would annoy you :)
[04:10]  * thumper slaps menn0
[04:11] <menn0> thumper: you can drop it :)
[04:11] <thumper> I did :)
[04:12] <thumper> menn0: can't really have the server tell the client to retry without parsing the error types...
[04:12]  * thumper thinks
[04:12] <thumper> let me look a bit more
[04:27] <wallyworld> veebers: the log forwarder will get it's logs to send what whatever we record in state for debug log
[04:27] <wallyworld> menn0: does debug log include logs for hosted models?
[04:28] <menn0> wallyworld: yes, but only for the machines and units in the model
[04:28] <wallyworld> menn0: so not controller actions like starting workers etc
[04:28] <menn0> wallyworld: any controller level activity (API requests and workers specific to the model in the controller) is still logged against the controller model
[04:28] <menn0> wallyworld: I have a plan to fix this.
[04:29] <menn0> wallyworld: thumper's recent work on loggo is part of that
[04:29] <wallyworld> menn0: no worries, veebers was testing log forwarder and wanted to know what to expect
[04:29] <menn0> kk
[04:29] <wallyworld> for hosted models
[04:29] <wallyworld> veebers: so you'll need to deploy something to see activity
[04:31] <veebers> wallyworld: ok makes sense. Thank you
[04:31] <wallyworld> np, hope it tests ok
[04:34] <veebers> wallyworld: ah, I did try deploying something while poking around but maybe looks like it gets logged once the deloy is done? at any rate that helps, should be easy enough to test
[04:34] <wallyworld> ok, let me know
[04:35] <veebers> will do
[05:35] <mup> Bug #1609643 opened: provider/...: make use of Environ.Create to create environ-wide resources like security groups <juju-core:Triaged> <https://launchpad.net/bugs/1609643>
[08:58] <rogpeppe> fwereade_: you around?
[09:00] <rogpeppe> fwereade_: just wondering if there's a good reason why the mock clock interface doesn't define the NewTimer method
[09:07] <dimitern> rick_h_: ping
[09:09] <dimitern> rick_h_: I was thinking to JFDI https://github.com/juju/juju/pull/5922, since there are only 2 blockers, both Fix Committed - any concerns?
[09:17] <fwereade_> rogpeppe, I think I did it that way to begin with but was unbothered by a PR that made things slightly cleaner by separating them, but memory is a little fuzzy
[09:18] <rogpeppe> fwereade_: it's just awkward if you need to use it with something that actually wants to use Reset
[09:19] <rogpeppe> fwereade_: for example, we're implementing an apiserver pinger and it would be nice to use the mock clock stuff
[09:19] <rogpeppe> fwereade_: but it's awkward if you can't have Reset
[09:20] <rogpeppe> fwereade_: i wondered if there was some "that's gonna be hard to do" reason for the omission or just that it was more convenient at the time.
[09:21] <rogpeppe> fwereade_: one other thing: testing.Timer is exported, as is testing.Timer.Id. any particular reason for that?
[09:24] <fwereade_> rogpeppe, I'm pretty sure, thinking further, that the only reason we don't have NewTimer is because we didn't need it yet
[09:24] <rogpeppe> fwereade_: ah, ok
[09:24] <fwereade_> rogpeppe, sorry, I was confused with the AfterFunc stuff, which was the reason Timer was added
[09:27] <fwereade_> rogpeppe, (for whatever reason I've never found Timer very helpful myself, but I have no real objections to it, please go ahead and add it if it would be useful to you)
[09:28] <rogpeppe> fwereade_: ok, cool. it means that normal idiomatic timer code can be easily changed to use mock clocks.
[09:29] <rogpeppe> fwereade_: i'm going to unexport testing.Timer too, if that sgty
[09:30]  * dimitern decides to use JFDI
[09:31] <babbageclunk> dimitern: It's pretty early in the morning for rick_h_, I think.
[09:32] <dimitern> babbageclunk: true, thought I wasn't sure if he's back home..
[09:32] <dimitern> babbageclunk: btw which version of emacs are you on?
[09:32] <babbageclunk> dimitern: oh, good point.
[09:32] <babbageclunk> dimitern: 24.5.1 apparently
[09:33] <dimitern> babbageclunk: from the archive or ppa?
[09:33] <babbageclunk> dimitern: archive.
[09:34] <dimitern> babbageclunk: ok, thanks - I'm on 25.1.50.3 built from tip a while ago
[09:34] <dimitern> /me, inspired by ivoks-vim snap is snapping emacs ;)
[09:35] <rogpeppe> fwereade_: BTW i think the AfterFunc implementation is subtly wrong - i don't think it would work correctly in this scenario: https://play.golang.org/p/X82i5TjzYD
[09:35] <babbageclunk> dimitern: nice.
[09:37] <ejat> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1609707
[09:38] <mup> Bug #1609707: lxc in Power8 System <lxc (Ubuntu):New> <https://launchpad.net/bugs/1609707>
[09:39] <babbageclunk> ejat: Hi, did you mean to post that in juju-dev?
[09:39] <ejat> babbageclunk: sorry mistakenly
[09:39] <dimitern> ejat: https://linuxcontainers.org/lxd/getting-started-cli/ - have you tried enabling trusty-backports and installing from there?
[09:42] <ejat> thanks dimitern ... its help
[09:42] <dimitern> ejat: if it worked, please comment on the bug ;)
[09:43] <ejat> yeah .. might be closing the bugs as well
[09:43] <babbageclunk> fwereade_, fwereade__, dimitern: can we do a hangout to talk about axw's comments on http://reviews.vapour.ws/r/5365/?
[09:43] <dimitern> babbageclunk: sure, let me have a look first though..
[09:43] <babbageclunk> actually, axw, are you around too?
[09:44]  * babbageclunk keeps forgetting Perth's in a very different timezone from NZ.
[09:44] <fwereade__> babbageclunk, they're all basically the same place, right? ;p
[09:44] <dimitern> babbageclunk: are you now in NZ?
[09:44] <fwereade__> babbageclunk, (yes, ofc)
[09:45] <fwereade__> babbageclunk, where?
[09:45] <ejat> dimitern: in 14.04 lts cant use juju .. but if im trying to use all-in-one installer gets error
[09:46] <ejat> s/juju/conjure
[09:48] <dimitern> ejat: I'd suggest asking in #ubuntu-server for conjure-up, folks here are not that familiar with it; also have you checked http://conjure-up.io/ ?
[09:50] <dimitern> babbageclunk, fwereade__: ok, I can do a HO now if it works for you as well
[10:00] <babbageclunk> dimitern: No, I'm still in the uk, but I kind of lump axw and other Aussies into the NZ timezone in my head.
[10:00] <dimitern> babbageclunk: ah :)
[10:00] <dimitern> babbageclunk: you have a review btw
[10:00] <babbageclunk> Sorry, was afk - shall we meet in standup?
[10:00] <dimitern> babbageclunk: let's do it
[11:06] <anastasiamac> babbageclunk: omg! how could u?  Just kidding :) Brisbane (Ian and I) are 2 hrs behind NZ and Andrew is 2hrs behind us... and it's 7pm for axw :) but who really looks at time here? :D
[11:09] <babbageclunk> anastasiamac: I mean, I realise that thinking of a huge continent all being in the same timezone as a couple of islands three hours flight away is wrong, I just can't convince my brain of it. ;)
[11:16] <anastasiamac> babbageclunk: yeah :) time zones are great \o/ for eg, russia has fun fluctuating between having 9 and 11 time zones https://en.wikipedia.org/wiki/Time_in_Russia
[11:59] <rogpeppe> fwereade__: WIP (I want some tests) but this is my suggestion for updates to the Clock implementation: https://github.com/juju/testing/pull/108
[11:59] <fwereade__> rogpeppe, thanks
[12:00] <rogpeppe> fwereade__: ah, just remembered that it needs to fire notifyAlarm on reset.
[12:08] <fwereade__> rogpeppe, very nice, but I can't help but think it needs tests
[12:08] <fwereade__> probably did from the beginning really
[12:08]  * fwereade__ hangs head in shame
[12:08] <rogpeppe> fwereade__: i totally agree
[12:08] <rogpeppe> fwereade__: that's why i labelled it as WIP in the PR descr
[12:09] <rogpeppe> fwereade__: just thought you might want to look initially
[12:09] <rogpeppe> fwereade__: i think this fixes a few bugs too
[12:09] <fwereade__> rogpeppe, yeah, much appreciated
[12:09] <fwereade__> rogpeppe, indeed
[12:09] <fwereade__> rogpeppe, the urge to LGTM without looking further was strong
[12:10] <rogpeppe> fwereade__: unfortunately we also need to change juju-core to use the testing.Clock rather than juju/testing.Clock too
[12:11] <fwereade__> rogpeppe, dammit
[12:11] <rogpeppe> fwereade__: and juju/clock itself needs updating to change the interface
[12:12]  * fwereade__ envies google's single-giant-repo more every day
[12:36] <rick_h_> dimitern: looks like you're all set
[12:37] <dimitern> rick_h_: yep
[12:37] <dimitern> rick_h_: it was a low risk change anyway I guess :)
[12:38] <rick_h_> dimitern: if you get a sec can you peek at https://askubuntu.com/questions/808011/how-to-specify-what-maas-interface-juju-should-use
[12:38] <rick_h_> dimitern: if you know of a way in 1.25 to do that?
[12:38] <dimitern> rick_h_: I've looked at it, and almost answered but got distracted
[12:38] <rick_h_> dimitern: ah cool ty
[12:48] <fwereade__> oh poo
[12:49] <fwereade__> babbageclunk, I have a migrations problem and could use an interlocutor, do you have a moment?
[12:51] <mup> Bug #1609407 changed: remoteFunctionalSuite.TestUsingTCP no such network interface <blocker> <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1609407>
[12:59]  * fwereade__ will soliloquize; anyone interested should chime in
[13:00] <fwereade__> I'm adding refcounts to charms; they're contributed by units and applications
[13:00] <fwereade__> we already have a very similar mechanism: *settings* refcounts, which are similarly contributed by apps and units
[13:02] <fwereade__> and the underlying mechanism will work just fine if we use the charm globalKey for those refcounts directly, rather than appname#charm
[13:03] <fwereade__> but (1) we migrate settingsrefcounts, which is suspicious, because it's an implementation detail entirely derived from other app and unit state
[13:05] <fwereade__> (heh,  (2) is not really important, assuming we check that unit charm urls match their apps', will check whether we do)
[13:10] <fwereade__> ...ok, I cannot convince myself that it is definitely correct
[13:11] <fwereade__> so, (2), the settingsrefs migration has potential problems
[13:12] <fwereade__> and in combination I am reasonably sure that we should simply *not* be representing the refcounts directly in the serialized model, but should be reconstructing them on import
[13:17] <mbruzek> Do we have any documentation on how the charm store and charm commands work with macaroons and the ubuntu sso? I have a partner of ours having trouble with the commands and I wanted to point them at some documentation about the process.
[13:37] <rick_h_> natefinch: I'm getting https://pastebin.canonical.com/162328/ trying to use my own build of juju, anything there look familiar e.g. "you did X wrong clearly"?
[13:37] <rick_h_> natefinch: tried it on two different providers and 4 bootstraps all fail with some # of "after # attempts"
[13:45] <dimitern> sinzui: hey, I've noticed you changed the milestone on bug 1609343 to beta15, but I forgot to set it to fix committed earlier today, and put the milestone back to beta14
[13:45] <mup> Bug #1609343: [aws; beta13] Juju can pick subnets from the wrong VPC with spaces constraints specified <ec2-provider> <usability> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1609343>
[13:45] <dimitern> since we don't have beta14 out
[13:46] <sinzui> dimitern: put it back to beta15. your commit is too new
[13:47] <dimitern> sinzui: ok then
[13:47] <babbageclunk> fwereade__: back, sorry - I think I follow. What you're saying makes sense to me, and is simpler than having a system where the refcounts are set manually separately on import.
[13:48] <dimitern> sinzui: done - I thought you're preparing to release b14 and pushing unfinished bugs forward
[13:48] <sinzui> dimitern: I am the best revision to release is from yesterday. your change is still being tested and has new kinds of failures
[13:49] <babbageclunk> fwereade__: you could have them still be serialised in the export and then check the serialised ones against the final ones after import?
[13:49] <fwereade__> babbageclunk, well, we *do* have to set them manually on import, one way or another
[13:50] <dimitern> sinzui: I've checked the reports but nothing seemed remotely relevant to the fix itself
[13:50] <sinzui> dimitern: I am not saying your change made the failures. we are seeing new kinds of failures from many possible sources http://reports.vapour.ws/releases/4207
[13:50] <fwereade__> babbageclunk, we have to write the code either way
[13:50] <fwereade__> babbageclunk, I'm not really sure which will be easier to get wrong
[13:50] <babbageclunk> fwereade__: Right, but ordinarily they'll be maintained as units and apps refer to them.
[13:51] <fwereade__> babbageclunk, (incidentally, is there some code I'm missing that prevents us from trying to export if any charm upgrade is in progress? I feel like it should exist but couldn't find it in a quick scan)
[13:51] <fwereade__> babbageclunk, indeed
[13:51] <babbageclunk> fwereade__: Don't know, sorry.
[13:52] <fwereade__> babbageclunk, hm, I might actually be able to push it all below the layer that migration happens at
[13:52] <babbageclunk> fwereade__: Right, so then the refcounts are maintained as you restore apps and units?
[13:52] <fwereade__> babbageclunk, yeah
[13:55] <babbageclunk> fwereade__: So the serialised refcount could be treated as a check after import.
[13:56] <babbageclunk> fwereade__: (That could cause problems if the point of the dummp and restore was to upgrade to a version that counted refs differently.)
[13:56] <fwereade__> babbageclunk, I think I'd still rather it be a calculated property rather than an independent variable
[13:56] <fwereade__> babbageclunk, and, yeah, it really *does* feel like an implementation detail
[13:56] <fwereade__> babbageclunk, the only reason we're refcounting is because it's the only technique we've found applicable at this level
[13:57] <babbageclunk> fwereade__: presumably this is just a performance optimisation? Can you always recalculate it from the apps and units?
[13:59] <babbageclunk> fwereade__: Or is there some kind of cross-model consideration?
[14:01] <rick_h_> fwereade__: natefinch dimitern ping for standup
[14:02] <perrito666> rogpeppe: ping?
[14:06] <fwereade__> babbageclunk, the refcounting is basically just for integrity
[14:07] <fwereade__> babbageclunk, am I misunderstanding?
[14:09] <babbageclunk> fwereade__: The refcount prevents you from deleting something because there are other things referring to it - you could instead go and count all of the things that refer to it, right? I might be misunderstanding also.
[14:12] <natefinch> fwereade__: github.com/juju/schema.Checker has a "path" argument to Coerce that isn't documented at all.  What is that for? https://godoc.org/github.com/juju/schema#Checker
[14:13] <fwereade__> babbageclunk, yeah, exactly -- they're relevant only for the txn level
[14:13] <fwereade__> natefinch, constructing useful descriptions of where you are in a nested structure
[14:13] <fwereade__> natefinch, coerce failed at config.foo.bar[baz]: not an int
[14:13] <fwereade__> natefinch, can't remember anything about how it actually works
[14:14] <natefinch> fwereade__: k
[14:15] <natefinch> fwereade__: related - Coerce for a FieldMap expects an interface that is a map of <something> to interface... where something can be a string or something with a String() method (possible due to reflection).  Does anyone actually use the stringer form? Do we need to keep that code around?  It makes the implementation a lot messier.
[14:16] <fwereade__> natefinch, I don't know, I'm afraid
[14:17] <fwereade__> natefinch, I am having difficulty imagining how that would work without stabbing you in the back on the regular
[14:19] <natefinch> fwereade__: indeed
[14:19] <natefinch> fwereade__: I sorta need to make a new version of the library anyway, maybe that's the best way to "fix" it.
[14:20] <fwereade__> natefinch, if we're having to go that far, should we be dropping coerce and building something up with gojsonschema?
[14:21] <mup> Bug # changed: 1457575, 1552948, 1566801, 1568845, 1570096, 1575676, 1579010, 1588095, 1599503, 1600054, 1602034, 1602054, 1602716, 1604644, 1604931, 1605050, 1607557
[14:22] <natefinch> fwereade__: the change to schema is actually backwards compatible... it's adding a notion of dependencies between attributes... here's the PR: http://reviews.vapour.ws/r/5364/
[14:23] <natefinch> fwereade__: so.. I don't know.  Personally, I'd prefer to use a standard, but I'm afraid that switching to gojsonschema might be a bigger change than we really want to make right now
[14:24] <fwereade__> natefinch, is there a strong benefit to dependencies vs subdocs? is {foo-bar: x, foo-baz: y} is really a win over {foo: {bar: x, baz: y}}?
[14:24] <natefinch> fwereade__: No.  I hadn't thought about using a subdoc for it
[14:25] <fwereade__> natefinch, worth considering
[14:25] <fwereade__> natefinch, that said we have no shortage of things in the first form already
[14:26] <fwereade__> natefinch, however, if we *are* making changes, that might stremline things a bit
[14:27] <natefinch> fwereade__: not sure if that cleans things up or not.  The main use case right now is openstack authentication.  Either you have SSO or username/password, in the latter case, you need to specify username and password, in the former, you don't.
[14:28] <fwereade__> natefinch, yeah, I see, even if there's an "auth" subdoc you still need the switch
[14:29] <fwereade__> natefinch, or, hold on
[14:30] <fwereade__> natefinch, wouldn't you do that with, uh, `schema.Any(ssoChecker{}, userpassChecker{})` or something?
[14:31] <fwereade__> natefinch, but *that* only works on a subdoc
[14:32] <fwereade__> natefinch, even so, {auth: {sso: blah}} and {auth: {user: foo, pass: bar}} is nicer than having auth-sso/auth-user/auth-pass all at the top level
[14:35] <fwereade__> natefinch, and it feels more in tune with the schema package
[14:35] <fwereade__> natefinch, even if that is a bit tautological
[14:36] <natefinch> fwereade__: this library is soooo confusing... yes, that would work
[14:37] <natefinch> fwereade__: though I don't know how to translate that to something you can define with environschema
[14:41] <fwereade__> natefinch, can an Attr just have an optional Checker field?
[14:43] <natefinch> fwereade__: not really.. Attr is just a serialization schema... you can't really put an arbitrary piece of code in there
[14:45] <fwereade__> natefinch, ...then the path of least resistance maybe starts to look like a Schema field with some jsonschema in there?
[14:45] <mup> Bug #1609818 opened: WorkerSuite.TestDelayedUpdateError timeout no more updates for you <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609818>
[14:45] <natefinch> fwereade__: the path of least resistance is to use the code that I've already written :)
[14:47] <fwereade__> natefinch, might be a local maximum... it feels like schema is a fairly significant source of friction here
[14:50] <natefinch> fwereade__: that may be fair
[16:39] <mup> Bug #1609879 opened: juju2 says to destroy-model --force when using --keep-broken <juju-core:New> <https://launchpad.net/bugs/1609879>
[16:41] <babbageclunk> fwereade__: a state.LinkLayerDevice has (potentially) multiple addresses associated with it, but params.NetworkConfig (and network.InterfaceInfo) have only one address...
[16:41] <babbageclunk> fwereade__: Should I pick an address or have multiple interface infos coming back?
[16:42] <babbageclunk> fwereade__: (Might be more for dimitern but he's not around.)
[16:45]  * babbageclunk will re-ask tomorrow.
[16:51] <mup> Bug #1609893 opened: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893>
[16:57] <mup> Bug #1609893 changed: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893>
[17:00] <rick_h_> natefinch: katco or all other people smarter than me, trying to use my juju build I get a failed bootstrap, but damn if everything doesn't seem to work out per logs/etc. https://pastebin.canonical.com/162345/plain/
[17:00] <rick_h_> I'm really open to ideas from folks that know more.
[17:01] <natefinch> rick_h_: looking
[17:01] <tvansteenburgh> hey core folks, i have a websocket client connected to a juju api server, but i don't know which version of juju i'm connected to. what's the easiest way to determine that?
[17:01] <katco> rick_h_: try turning on tracing and --debug while bootstrapping?
[17:02] <rick_h_> katco: that is with --debug
[17:02] <katco> rick_h_: i see: "/home/rharding/src/juju/bin/juju bootstrap --upload-tools --keep-broken test" ?
[17:03] <rick_h_> katco: ah sorry, I pasted from a previous run
[17:03] <katco> rick_h_: ah
[17:03] <katco> rick_h_: is it possible to set the log level to trace at bootstrap time?
[17:03] <rick_h_> katco: will look for my next run
[17:05] <natefinch> tvansteenburgh: hmm.. AFAIK we don't have a dedicated "version" endpoint (which is a shame).  I think the GUI has some heinous hacks to figure it out, but not entirely sure.
[17:05] <tvansteenburgh> natefinch: i was afraid that was the answer :/
[17:09] <mup> Bug #1609893 opened: juju status returns ERROR not logged in <juju-core:New> <https://launchpad.net/bugs/1609893>
[17:18] <mup> Bug #1609896 opened: Race in github.com/juju/juju/rpc/server <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609896>
[17:49] <mup> Bug #1609910 opened: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910>
[17:52] <mup> Bug #1609910 changed: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910>
[17:53] <natefinch> rick_h_: got some time to talk?  I got some feedback from william on my pr that needs discussion
[17:53] <natefinch> fwereade__: I presume you're long gone?
[17:54] <rick_h_> natefinch: I've got a call in 7 if we can do it in there
[17:54] <rick_h_> natefinch: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1
[17:54] <natefinch> sure
[17:58] <mup> Bug #1609910 opened: Juju API lacks version endpoint <juju-core:New> <https://launchpad.net/bugs/1609910>
[18:42] <natefinch> gah... gojsonschema has almost zero documentation.
[19:46] <katco> any juju architecture guru types around? fwereade__?
[20:55] <niedbalski> We are trying out beta14 and found this serious problem: http://pastebin.ubuntu.com/22225558/
[20:55] <niedbalski> sinzui, alexisb ^^ is this expected?
[20:55] <sinzui> niedbalski: officiall we don't support that
[20:56] <sinzui> niedbalski: We don't even test uprades since juju is breaking behavious
[20:57] <niedbalski> sinzui, ok. So it might be a required to bootstrap this env again?
[20:57] <sinzui> niedbalski: yes :/
[20:57] <niedbalski> sinzui, ok
[20:57] <mgz> niedbalski: yup, 'fraid so, we don't do upgrades between betas
[21:03] <thumper> snow day here, kids all at home
[21:03] <thumper> barely 2cm of snow and the city shuts down
[21:06] <niedbalski> mgz, sinzui thanks guys.
[21:07] <mup> Bug #1609980 opened: Juju does not give a clear error when unable to create a loop device on lxd <lxd> <storage> <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1609980>
[21:43] <mup> Bug #1609994 opened: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609994>
[21:49] <mup> Bug #1609994 changed: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1609994>
[22:01] <perrito666> now, this is new: /home/hduran/Develop/golang/go1.6.2/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
[22:01] <mup> Bug #1609994 opened: Race in github.com/juju/loggo global <blocker> <ci> <race-condition> <regression> <unit-tests> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1609994>
[22:05] <thumper> menn0: http://reviews.vapour.ws/r/5376/
[22:05] <menn0> thumper: looking
[22:07] <thumper> menn0: 1:1 ?
[22:07] <menn0> thumper: ok
[22:26] <thumper> wallyworld, menn0: http://reviews.vapour.ws/r/5377/
[22:27] <wallyworld> thumper: +1
[22:28] <thumper> landing
[22:36] <thumper> seems we have no on call reviewer today
[22:36] <thumper> http://reviews.vapour.ws/r/5345/diff/#
[22:37] <thumper> menn0: http://reviews.vapour.ws/r/5369/diff/# updated to use 1500ms max dealy as discussed
[22:40] <menn0> thumper: looking
[22:43] <menn0> thumper: it just occurred to me that the tests could be simpler if instead of injecting a Clock, retry.Call was injected
[22:43] <menn0> thumper: that way you just need to check that retry.Call is given the right args
[22:43] <menn0> thumper: and the tests aren't checking retry.Call's behaviour
[22:44] <menn0> thumper: not saying you need to change it, but just an idea for future work like this
[22:44]  * thumper nods
[22:44] <thumper> that's a thought
[22:44] <menn0> thumper: ship it
[22:45] <menn0> thumper: does that loggo race really need to be a blocker?
[22:46] <menn0> master was open when I submitted a PR but by the time it ran it was blocked again
[22:49] <mgz> now that's what I call a race
[22:58] <menn0> mgz: haha
[22:59] <menn0> thumper: I just realised that MM ids have an nice (unintentional) property: they're globally unique across all controllers (because of the was sequences are migrated)
[23:10] <wallyworld> menn0: when the PR lands. we'll remove the blocker tag. a race in a 3rd party lib should not stop 15 people from landing work
[23:10] <menn0> wallyworld: +1
[23:11] <wallyworld> menn0: the PR to update deps just got an intermittent error, i resubmitted, hopefully will land this time
[23:19] <mup> Bug #1610007 opened: Juju 2.0-beta14: AllWatcher deltas on unclean model do not  report proper application state <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1610007>
[23:52] <mup> Bug #1610012 opened: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012>
[23:55] <thumper> um...
[23:55] <thumper> I don't think that is a bug
[23:56] <thumper> ok, the heading is confusing
[23:58] <mup> Bug #1610012 changed: can't migrate a model off a controller twice <migration> <juju-core:New for menno.smits> <https://launchpad.net/bugs/1610012>