[00:37] anastasiamac, ping [00:37] if you are around we can hope on the release standup [00:38] alexisb: tyvm! see u there [01:15] 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] 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] 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] veebers: yeah, i think they want to start the release their thursday, so too late [01:21] we have stuff queued up to land post beta [01:22] wallyworld: cool. I'll get it sorted today/tomorrow [01:22] sounds good, ty [01:23] 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] 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] yep [01:24] ack [01:24] axw: we can do a snap :-) [01:25] wallyworld: true :) [01:25] well, as soon as I get a bit more sorted out [01:25] 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] veebers: e.g., "admin@local/default" [01:26] or just "admin/default" [01:27] veebers: and thanks [01:27] nw [01:32] anastasiamac: can http://reviews.vapour.ws/r/5341/ be closed? [01:33] axw: yes. let's :) I'll re-PR when ready :) [01:33] thanks [01:33] axw: done [01:40] 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] wallyworld: it does, but the RB diff should just show the delta [01:41] really? even if proposed against master? ok [01:41] wallyworld: yeah, you can do that with "rbt post -r --parent " [01:41] mm, what was the way to tell mongo to ve Trace level verbose? [01:42] s/mongo/juju [01:43] 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] 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] axw: and the initial step is to branch off the upstream branch right? instead of branching off master [01:45] 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] is the all team meeting happening? I somehow presume that its the exact same group of people than the standup [01:52] 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] perrito666: and there is always nice dueling to witness [01:52] perrito666: also would love to touch base re: review process [01:53] perrito666: oc, i might b dreaming and noone will join me again.. in which case, I'll just tlak to myself ;) [01:59] 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] axw: as an OCR, m happy to go with ur opinion [02:02] axw: thumper: menn0:perrito666: team meeting [02:02] natefinch: ^^ [02:36] wallyworld: I think we should stop showing bootstrap-config in "show-controller" by default (maybe not at all?) what do you think? [02:36] wallyworld: now that bootstrap config contains all the defaults, it's taking up a lot of screen space [02:37] axw: yeah, not much point. what we *should* show is controller config [02:38] wallyworld: hmm is that going to be dynamic? will we have commnads to update it? [02:40] 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] wallyworld: ah I thought you meant inherited config. okey dokey [02:40] s/remove/not show [02:40] axw: there's a juju model-defaults to show inherited config [02:41] 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] 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] wallyworld: cool, SGMT [02:41] SGTM* [02:42] wallyworld: btw I've just bootstrapped AWS with region, access-key and secret-key removed from model config [02:42] finally got there [02:42] \o/ ^ 100 [02:42] awesome sauce [02:43] that deserves a beer or two [02:43] 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] whohoo [02:44] assuming networking is set up so the model can talk to the controller [02:44] not sure what's involved there [02:44] may need to specify a vpc id? [02:44] wallyworld: it works because it goes over the internet [02:44] public IPs [02:44] * axw tests [02:45] ah right. we should look to fix it so it doesn't have to, or document how to at least [02:45] wallyworld: why? [02:46] wallyworld: traffic cost? [02:46] yep, plus efficency [02:46] maybe port exposing / security groups would prevent it also if it is external traffic? [02:46] wallyworld: I'd like to think that AWS knows how to route those addresses efficiently. don't know about the cost side [02:47] not sure that AWS does that sort of short circuiting [02:47] could be wrong [02:47] wallyworld: anyway, I now have a controller in AWS with machines in two regions :) [02:47] awesome :-) [02:47] * axw goes to make a cup of tea to celebrate [02:47] but IMO we need clear guidelines on how to set up [02:48] add some rum to the tea [02:48] wallyworld: what do you mean? there's no setup. just bootstrap, then add-model --region=foo [02:48] networking [02:48] how to avoid external traffic etc [02:48] will be provider specific [02:49] wallyworld: ok. yes, if/when we change that to not go over hte internet [02:49] maybe we guide them to a suitable space set up etc [03:33] 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 for that to trigger a forward? [03:34] (this is in response to an email from you from a wee while ago) [03:35] 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] 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] veebers: just the act of adding the model - it will log worker startup etc [03:38] wallyworld: interesting. I'm not seeing that forwarded but I might be doing something wrong. I'll continue digging [03:38] you see the controller model logs ok though? [03:38] just not hosted model logs [03:39] wallyworld: correct [03:39] hmmm, it may be that it's only enabled for the controller, i'd need to check [03:39] give me a few minutes [03:39] wallyworld: awesome, cheers [03:46] menn0: http://reviews.vapour.ws/r/5369/ [03:55] axw: doing a rb post, what username/password did you use? [03:56] since i normally sign into rb using github sso [03:57] wallyworld: you use oauth with rbt too [03:57] wallyworld: see the bottom of reviewboard.md in docs/contributing [03:58] docs/contributions [03:58] menn0: ta [03:58] thumper: looking [04:09] thumper: review done [04:09] menn0: ta [04:09] thumper: did you try reproducing using enable-ha? [04:09] menn0: I did, wasn't able to reproduce [04:10] menn0: btw, are you taking the piss? [04:10] thumper: I guess it's somewhat timing dependent [04:10] "errorCoder" ? [04:10] thumper: slightly :) [04:10] thumper: only because I knew it would annoy you :) [04:10] * thumper slaps menn0 [04:11] thumper: you can drop it :) [04:11] I did :) [04:12] menn0: can't really have the server tell the client to retry without parsing the error types... [04:12] * thumper thinks [04:12] let me look a bit more [04:27] veebers: the log forwarder will get it's logs to send what whatever we record in state for debug log [04:27] menn0: does debug log include logs for hosted models? [04:28] wallyworld: yes, but only for the machines and units in the model [04:28] menn0: so not controller actions like starting workers etc [04:28] 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] wallyworld: I have a plan to fix this. [04:29] wallyworld: thumper's recent work on loggo is part of that [04:29] menn0: no worries, veebers was testing log forwarder and wanted to know what to expect [04:29] kk [04:29] for hosted models [04:29] veebers: so you'll need to deploy something to see activity [04:31] wallyworld: ok makes sense. Thank you [04:31] np, hope it tests ok [04:34] 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] ok, let me know [04:35] will do [05:35] Bug #1609643 opened: provider/...: make use of Environ.Create to create environ-wide resources like security groups === frankban|afk is now known as frankban [08:58] fwereade_: you around? [09:00] fwereade_: just wondering if there's a good reason why the mock clock interface doesn't define the NewTimer method [09:07] rick_h_: ping [09:09] 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] 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] fwereade_: it's just awkward if you need to use it with something that actually wants to use Reset [09:19] fwereade_: for example, we're implementing an apiserver pinger and it would be nice to use the mock clock stuff [09:19] fwereade_: but it's awkward if you can't have Reset [09:20] 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] fwereade_: one other thing: testing.Timer is exported, as is testing.Timer.Id. any particular reason for that? [09:24] 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] fwereade_: ah, ok [09:24] rogpeppe, sorry, I was confused with the AfterFunc stuff, which was the reason Timer was added [09:27] 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] fwereade_: ok, cool. it means that normal idiomatic timer code can be easily changed to use mock clocks. [09:29] fwereade_: i'm going to unexport testing.Timer too, if that sgty [09:30] * dimitern decides to use JFDI [09:31] dimitern: It's pretty early in the morning for rick_h_, I think. [09:32] babbageclunk: true, thought I wasn't sure if he's back home.. [09:32] babbageclunk: btw which version of emacs are you on? [09:32] dimitern: oh, good point. [09:32] dimitern: 24.5.1 apparently [09:33] babbageclunk: from the archive or ppa? [09:33] dimitern: archive. [09:34] babbageclunk: ok, thanks - I'm on 25.1.50.3 built from tip a while ago [09:34] /me, inspired by ivoks-vim snap is snapping emacs ;) [09:35] 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] dimitern: nice. [09:37] https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1609707 [09:38] Bug #1609707: lxc in Power8 System [09:39] ejat: Hi, did you mean to post that in juju-dev? [09:39] babbageclunk: sorry mistakenly [09:39] ejat: https://linuxcontainers.org/lxd/getting-started-cli/ - have you tried enabling trusty-backports and installing from there? [09:42] thanks dimitern ... its help [09:42] ejat: if it worked, please comment on the bug ;) [09:43] yeah .. might be closing the bugs as well [09:43] fwereade_, fwereade__, dimitern: can we do a hangout to talk about axw's comments on http://reviews.vapour.ws/r/5365/? [09:43] babbageclunk: sure, let me have a look first though.. [09:43] actually, axw, are you around too? [09:44] * babbageclunk keeps forgetting Perth's in a very different timezone from NZ. [09:44] babbageclunk, they're all basically the same place, right? ;p [09:44] babbageclunk: are you now in NZ? [09:44] babbageclunk, (yes, ofc) [09:45] babbageclunk, where? [09:45] dimitern: in 14.04 lts cant use juju .. but if im trying to use all-in-one installer gets error [09:46] s/juju/conjure [09:48] 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] babbageclunk, fwereade__: ok, I can do a HO now if it works for you as well [10:00] 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] babbageclunk: ah :) [10:00] babbageclunk: you have a review btw [10:00] Sorry, was afk - shall we meet in standup? [10:00] babbageclunk: let's do it [11:06] 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] 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] 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] 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] rogpeppe, thanks [12:00] fwereade__: ah, just remembered that it needs to fire notifyAlarm on reset. [12:08] rogpeppe, very nice, but I can't help but think it needs tests [12:08] probably did from the beginning really [12:08] * fwereade__ hangs head in shame [12:08] fwereade__: i totally agree [12:08] fwereade__: that's why i labelled it as WIP in the PR descr [12:09] fwereade__: just thought you might want to look initially [12:09] fwereade__: i think this fixes a few bugs too [12:09] rogpeppe, yeah, much appreciated [12:09] rogpeppe, indeed [12:09] rogpeppe, the urge to LGTM without looking further was strong [12:10] fwereade__: unfortunately we also need to change juju-core to use the testing.Clock rather than juju/testing.Clock too [12:11] rogpeppe, dammit [12:11] 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] dimitern: looks like you're all set [12:37] rick_h_: yep [12:37] rick_h_: it was a low risk change anyway I guess :) [12:38] 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] dimitern: if you know of a way in 1.25 to do that? [12:38] rick_h_: I've looked at it, and almost answered but got distracted [12:38] dimitern: ah cool ty [12:48] oh poo [12:49] babbageclunk, I have a migrations problem and could use an interlocutor, do you have a moment? === redelmann is now known as rudi|wfh === rudi|wfh is now known as rudi_wfh === rudi_wfh is now known as rudi|wfh [12:51] Bug #1609407 changed: remoteFunctionalSuite.TestUsingTCP no such network interface [12:59] * fwereade__ will soliloquize; anyone interested should chime in [13:00] I'm adding refcounts to charms; they're contributed by units and applications [13:00] we already have a very similar mechanism: *settings* refcounts, which are similarly contributed by apps and units [13:02] and the underlying mechanism will work just fine if we use the charm globalKey for those refcounts directly, rather than appname#charm [13:03] but (1) we migrate settingsrefcounts, which is suspicious, because it's an implementation detail entirely derived from other app and unit state [13:05] (heh, (2) is not really important, assuming we check that unit charm urls match their apps', will check whether we do) [13:10] ...ok, I cannot convince myself that it is definitely correct [13:11] so, (2), the settingsrefs migration has potential problems [13:12] 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] 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] 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] natefinch: tried it on two different providers and 4 bootstraps all fail with some # of "after # attempts" === cory_fu-vac is now known as cory_fu [13:45] 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] Bug #1609343: [aws; beta13] Juju can pick subnets from the wrong VPC with spaces constraints specified [13:45] since we don't have beta14 out [13:46] dimitern: put it back to beta15. your commit is too new [13:47] sinzui: ok then [13:47] 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] sinzui: done - I thought you're preparing to release b14 and pushing unfinished bugs forward [13:48] 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] 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] babbageclunk, well, we *do* have to set them manually on import, one way or another [13:50] sinzui: I've checked the reports but nothing seemed remotely relevant to the fix itself [13:50] 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] babbageclunk, we have to write the code either way [13:50] babbageclunk, I'm not really sure which will be easier to get wrong [13:50] fwereade__: Right, but ordinarily they'll be maintained as units and apps refer to them. [13:51] 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] babbageclunk, indeed [13:51] fwereade__: Don't know, sorry. [13:52] babbageclunk, hm, I might actually be able to push it all below the layer that migration happens at [13:52] fwereade__: Right, so then the refcounts are maintained as you restore apps and units? [13:52] babbageclunk, yeah [13:55] fwereade__: So the serialised refcount could be treated as a check after import. [13:56] 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] babbageclunk, I think I'd still rather it be a calculated property rather than an independent variable [13:56] babbageclunk, and, yeah, it really *does* feel like an implementation detail [13:56] babbageclunk, the only reason we're refcounting is because it's the only technique we've found applicable at this level [13:57] fwereade__: presumably this is just a performance optimisation? Can you always recalculate it from the apps and units? [13:59] fwereade__: Or is there some kind of cross-model consideration? [14:01] fwereade__: natefinch dimitern ping for standup [14:02] rogpeppe: ping? [14:06] babbageclunk, the refcounting is basically just for integrity [14:07] babbageclunk, am I misunderstanding? [14:09] 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] 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] babbageclunk, yeah, exactly -- they're relevant only for the txn level [14:13] natefinch, constructing useful descriptions of where you are in a nested structure [14:13] natefinch, coerce failed at config.foo.bar[baz]: not an int [14:13] natefinch, can't remember anything about how it actually works [14:14] fwereade__: k [14:15] fwereade__: related - Coerce for a FieldMap expects an interface that is a map of 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] natefinch, I don't know, I'm afraid [14:17] natefinch, I am having difficulty imagining how that would work without stabbing you in the back on the regular [14:19] fwereade__: indeed [14:19] fwereade__: I sorta need to make a new version of the library anyway, maybe that's the best way to "fix" it. [14:20] natefinch, if we're having to go that far, should we be dropping coerce and building something up with gojsonschema? [14:21] Bug # changed: 1457575, 1552948, 1566801, 1568845, 1570096, 1575676, 1579010, 1588095, 1599503, 1600054, 1602034, 1602054, 1602716, 1604644, 1604931, 1605050, 1607557 [14:22] 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] 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] 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] fwereade__: No. I hadn't thought about using a subdoc for it [14:25] natefinch, worth considering [14:25] natefinch, that said we have no shortage of things in the first form already [14:26] natefinch, however, if we *are* making changes, that might stremline things a bit [14:27] 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] natefinch, yeah, I see, even if there's an "auth" subdoc you still need the switch [14:29] natefinch, or, hold on [14:30] natefinch, wouldn't you do that with, uh, `schema.Any(ssoChecker{}, userpassChecker{})` or something? [14:31] natefinch, but *that* only works on a subdoc [14:32] 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] natefinch, and it feels more in tune with the schema package [14:35] natefinch, even if that is a bit tautological [14:36] fwereade__: this library is soooo confusing... yes, that would work [14:37] fwereade__: though I don't know how to translate that to something you can define with environschema [14:41] natefinch, can an Attr just have an optional Checker field? [14:43] fwereade__: not really.. Attr is just a serialization schema... you can't really put an arbitrary piece of code in there [14:45] natefinch, ...then the path of least resistance maybe starts to look like a Schema field with some jsonschema in there? [14:45] Bug #1609818 opened: WorkerSuite.TestDelayedUpdateError timeout no more updates for you [14:45] fwereade__: the path of least resistance is to use the code that I've already written :) [14:47] natefinch, might be a local maximum... it feels like schema is a fairly significant source of friction here [14:50] fwereade__: that may be fair [16:39] Bug #1609879 opened: juju2 says to destroy-model --force when using --keep-broken [16:41] fwereade__: a state.LinkLayerDevice has (potentially) multiple addresses associated with it, but params.NetworkConfig (and network.InterfaceInfo) have only one address... [16:41] fwereade__: Should I pick an address or have multiple interface infos coming back? [16:42] fwereade__: (Might be more for dimitern but he's not around.) [16:45] * babbageclunk will re-ask tomorrow. [16:51] Bug #1609893 opened: juju status returns ERROR not logged in === frankban is now known as frankban|afk [16:57] Bug #1609893 changed: juju status returns ERROR not logged in [17:00] 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] I'm really open to ideas from folks that know more. [17:01] rick_h_: looking [17:01] 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] rick_h_: try turning on tracing and --debug while bootstrapping? [17:02] katco: that is with --debug [17:02] rick_h_: i see: "/home/rharding/src/juju/bin/juju bootstrap --upload-tools --keep-broken test" ? [17:03] katco: ah sorry, I pasted from a previous run [17:03] rick_h_: ah [17:03] rick_h_: is it possible to set the log level to trace at bootstrap time? [17:03] katco: will look for my next run [17:05] 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] natefinch: i was afraid that was the answer :/ [17:09] Bug #1609893 opened: juju status returns ERROR not logged in [17:18] Bug #1609896 opened: Race in github.com/juju/juju/rpc/server [17:49] Bug #1609910 opened: Juju API lacks version endpoint [17:52] Bug #1609910 changed: Juju API lacks version endpoint [17:53] rick_h_: got some time to talk? I got some feedback from william on my pr that needs discussion [17:53] fwereade__: I presume you're long gone? [17:54] natefinch: I've got a call in 7 if we can do it in there [17:54] natefinch: https://hangouts.google.com/hangouts/_/canonical.com/rick?authuser=1 [17:54] sure [17:58] Bug #1609910 opened: Juju API lacks version endpoint [18:42] gah... gojsonschema has almost zero documentation. [19:46] any juju architecture guru types around? fwereade__? [20:55] We are trying out beta14 and found this serious problem: http://pastebin.ubuntu.com/22225558/ [20:55] sinzui, alexisb ^^ is this expected? [20:55] niedbalski: officiall we don't support that [20:56] niedbalski: We don't even test uprades since juju is breaking behavious [20:57] sinzui, ok. So it might be a required to bootstrap this env again? [20:57] niedbalski: yes :/ [20:57] sinzui, ok [20:57] niedbalski: yup, 'fraid so, we don't do upgrades between betas === natefinch is now known as natefinch-afk [21:03] snow day here, kids all at home [21:03] barely 2cm of snow and the city shuts down [21:06] mgz, sinzui thanks guys. [21:07] Bug #1609980 opened: Juju does not give a clear error when unable to create a loop device on lxd === petevg is now known as petevg_vacation === petevg_vacation is now known as petevg_afk === petevg_afk is now known as petevg_vacation [21:43] Bug #1609994 opened: Race in github.com/juju/loggo global [21:49] Bug #1609994 changed: Race in github.com/juju/loggo global [22:01] 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] Bug #1609994 opened: Race in github.com/juju/loggo global [22:05] menn0: http://reviews.vapour.ws/r/5376/ [22:05] thumper: looking [22:07] menn0: 1:1 ? [22:07] thumper: ok [22:26] wallyworld, menn0: http://reviews.vapour.ws/r/5377/ [22:27] thumper: +1 [22:28] landing [22:36] seems we have no on call reviewer today [22:36] http://reviews.vapour.ws/r/5345/diff/# [22:37] menn0: http://reviews.vapour.ws/r/5369/diff/# updated to use 1500ms max dealy as discussed [22:40] thumper: looking [22:43] thumper: it just occurred to me that the tests could be simpler if instead of injecting a Clock, retry.Call was injected [22:43] thumper: that way you just need to check that retry.Call is given the right args [22:43] thumper: and the tests aren't checking retry.Call's behaviour [22:44] thumper: not saying you need to change it, but just an idea for future work like this [22:44] * thumper nods [22:44] that's a thought [22:44] thumper: ship it [22:45] thumper: does that loggo race really need to be a blocker? [22:46] master was open when I submitted a PR but by the time it ran it was blocked again [22:49] now that's what I call a race [22:58] mgz: haha [22:59] 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] 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] wallyworld: +1 [23:11] menn0: the PR to update deps just got an intermittent error, i resubmitted, hopefully will land this time [23:19] Bug #1610007 opened: Juju 2.0-beta14: AllWatcher deltas on unclean model do not report proper application state [23:52] Bug #1610012 opened: can't migrate a model off a controller twice [23:55] um... [23:55] I don't think that is a bug [23:56] ok, the heading is confusing [23:58] Bug #1610012 changed: can't migrate a model off a controller twice