[00:00] <babbageclunk> wallyworld: Do you mean, set a status in the test, or in newRemoteApplication?
[00:00] <wallyworld> babbageclunk: in the test
[00:00] <wallyworld> for now
[00:00] <babbageclunk> ok cool
[00:00] <wallyworld> when we do the status work in a bit, we can look at what the default should be then
[00:06] <babbageclunk> wallyworld: updated - can you merge that? there's no bot on that repo.
[00:06] <wallyworld> sure
[00:06] <wallyworld> done
[00:07] <babbageclunk> thanks!
[01:33] <axw> hml: standup?
[01:34] <hml> axw: on my way
[01:46] <balloons> wallyworld, axw, et la. PSA, merging is down whilst I swap some things out. Sorry for the noise, I'll let you know when it's all clear
[01:47] <wallyworld> balloons: all good
[01:47] <axw> balloons: np, thanks for letting us know
[02:15] <hml> wallyworld: axw: I updated the bug with a bits I’v found on the error codes: https://bugs.launchpad.net/juju/+bug/1682827
[02:15] <mup> Bug #1682827: Bootstrap on OpenStack Cloud fails <juju:In Progress by hmlanigan> <https://launchpad.net/bugs/1682827>
[02:17] <axw> hml: thanks
[02:17] <axw> hml: so... 413, 429, 503, and 500 for earlier versions of repose
[02:18] <axw> and I believe I saw docs about 403
[02:18] <hml> axw: sounds like it, 403 was a in the mitaka doc i believe
[02:19] <axw> hml: maybe we should just look for Retry-After
[02:19] <hml> axw: i was wondering about that myself
[02:20] <hml> axw: esp as the error code doesn’t matter if we don’t have a Retry-After
[02:20] <hml> axw: and the list is getting crazy
[02:21] <axw> hml: yeah. I'm ok with that, maybe just run it by Ian first
[02:21] <hml> axw: i’m looking more into it - will do
[02:24] <hml> wallyworld: on 1682877 (rate limit one) , perhaps we just look for a Retry-After value - the list of possible error codes is getting long. and seems to change.
[02:25] <wallyworld> hml: yeah i thought about that myself
[02:26] <wallyworld> just wasn't 100% convinced that we shouldn't look at status code, but maybe it;s the right thing to do
[02:26] <wallyworld> maybe if status code is either 4xx or 5xx
[02:27] <wallyworld> but i'm reluctant to retry on things that are obviously not retyable like a 404
[02:28] <wallyworld> hence the hesitation
[02:28] <hml> wallyworld: we do check that “Retry-After” is given
[02:28] <wallyworld> i guess if the server side puts a retry-after with a 404 it's on them not do to that
[02:29] <hml> wallyworld: i’d think so - doing a little investigation on that
[02:42] <hml> good night
[02:44] <balloons> wallyworld, axw, et la, I believe merges should be fine now
[02:45] <axw> thanks
[02:45] <wallyworld> great
[02:53] <babbageclunk> wallyworld or axw: could one of you take a look at https://github.com/juju/juju/pull/7319 please?
[02:53] <wallyworld> ok
[02:53] <babbageclunk> wallyworld: thanks!
[02:54]  * babbageclunk goes for a run
[03:01] <axw> wallyworld: doc looks fine overall, I've left a handful of comments
[03:01] <wallyworld> axw: thanks, ok, will look in a bit
[05:01] <babbageclunk> wallyworld: made the changes you suggested. Do you think I should change the global key prefix to make it easier to work out?
[05:02] <wallyworld> babbageclunk: which global key prefix? i've forgotten the context
[05:03] <wallyworld> babbageclunk: c# isn't the global key for remote apps
[05:04] <babbageclunk> wallyworld: ?
[05:04] <wallyworld> oh wait
[05:04] <wallyworld> it is
[05:04] <wallyworld> hmmmm
[05:04] <wallyworld> i think the megawatcher needs to have single char global keys
[05:04] <babbageclunk> ohh
[05:04] <wallyworld> and 'r' and 'a' are taken
[05:05] <wallyworld> i'll need to check though to be sure
[05:05] <babbageclunk> I could leave a passive-aggressive response comment. ;)
[05:05] <wallyworld> leave comment for now and we can circle back? maybe add card to board to check
[05:05] <babbageclunk> wallyworld: roger wilco
[05:05] <wallyworld> i had forgotten c# when i made the pr comment
[05:05] <wallyworld> i thought it was a typo
[05:07] <babbageclunk> wallyworld: seems like a weird constraint in the allwatcher?
[05:08] <wallyworld> babbageclunk: yeah, i don't know the origin of it - i have been bitten by it. the implementation is such that when it tries to go from global key -> backing entity, it does a key[0]
[05:09] <wallyworld> by origin, i mean reason for doing it that way
[05:09] <wallyworld> seems show sighted
[05:09] <wallyworld> *short
[05:09] <babbageclunk> wallyworld: oh ouch - that sounds like knowledge that was painfully acquired.
[05:09] <wallyworld> yeah it was. i broke shit
[05:09] <wallyworld> at sime stage
[05:18] <babbageclunk> wallyworld: take another look when you have a moment? https://github.com/juju/juju/pull/7319
[05:20] <wallyworld> babbageclunk: yep sure, already looking :-)
[05:20] <babbageclunk> I'm never sure who reads github emails and who doesn't. :)
[05:27] <wallyworld> babbageclunk: looks ok to land, thanks. bring on the next piece....
[05:28] <babbageclunk> wallyworld: cool cool, thanks
=== frankban|afk is now known as frankban
[07:04] <frankban> wallyworld: ping
[07:04] <wallyworld> hey
[07:05] <frankban> wallyworld: can we merge https://github.com/juju/errors/pull/28 ?
[07:05] <frankban> wallyworld: the code looks good to me, and the proposer would prefer not to fork the library
[07:05] <wallyworld> let me look
[07:06] <frankban> thanks
[07:16] <wallyworld> frankban: i think it's ok. seems really hacky. i'd like to check with menno tomorrow just to be sure. if it's all ok, we'll merge then
[07:16] <frankban> wallyworld: thanks!
[07:18] <frankban> wallyworld: should be ok as menno gave it a lgtm at https://github.com/juju/errors/pull/26
[07:19] <wallyworld> frankban: ok, let's do it then, i'll merge
[07:19] <frankban> \o/
[07:24] <frankban> wallyworld: hmm, test failed in a weird way: ../../../gopkg.in/mgo.v2/internal/json/encode.go:253: undefined: sync.Pool
[07:25] <wallyworld> yuk, ok, will have to look. i'm late for soccer so will have to dig in tomorrow
[07:25] <frankban> no problem
[07:49] <rogpeppe> frankban: that's probably because it's being compiled with a version of Go that's too early
[07:49] <frankban> rogpeppe: so we need to update the go used by jenkins?
[07:51] <rogpeppe> frankban: well, it's funny, i thought we were using at least go 1.6, which had sync.Pool
[07:51] <rogpeppe> frankban: do you know what version we're actually using?
[07:51] <frankban> rogpeppe: no
[07:51] <rogpeppe> frankban: (we *should* update the version used by jenkins anyway)
[07:51] <rogpeppe> frankban: (i actually thought i'd already done that)
[07:52] <frankban> rogpeppe: in the juju-core jenkins?
[07:52] <frankban> rogpeppe: this is http://juju-ci.vapour.ws
[07:52] <rogpeppe> frankban: no, in the jimm jenkins
[07:52] <frankban> yeah
[07:53] <frankban> balloons would know the version of go used there
[07:53] <rogpeppe> frankban: i don't seem to be able to ssh to that machine
[07:54] <frankban> rogpeppe: I don't think we have access to that
[07:54] <rogpeppe> frankban: ok
[07:56] <rogpeppe> frankban: looks like it might be running 1.2, which is really old
[07:57] <frankban> woah...
[07:57] <frankban> cgo
[07:58] <frankban> rogpeppe: last landed branch on that repo is Aug 9, 2016
[09:35] <stub> Unrelated Windows test failures with Jenkins. Does it need stabbing, or should I just retry?
[12:54] <wpk> Anyone wants to take a look at this one? It's quite large so it should probably be double-reviewed https://github.com/juju/juju/pull/7314
[12:54] <balloons> go should be 1.8 everywhere
[12:54] <balloons> rogepeppe and frankban ^^
[13:06] <wpk> Is there a way juju CLI can 'signal' a worker in controller?
[13:17] <frankban> balloons: we were looking at the failure at http://juju-ci.vapour.ws:8080/job/github-merge-juju-errors/8/console
[13:40] <balloons> frankban, interesting. Let me look. That's the old machine
[13:41] <balloons> ahh right.. lookey there, not updated
[13:41] <balloons> it's hardcoding go-1.6
[13:42] <balloons> frankban, dropped the hardcode and rebuilding
[13:43] <frankban> balloons: thanks, note that we landed that branch but then rogpeppe provided another review with some requests for changes. so we'd still like to have that build working but without merging the branch
[13:47] <balloons> frankban, ack. thanks for the pointer. Those old merge jobs had go-1.6 hardcoded in them
[14:35] <marcoceppi> wallyworld: you around?
[14:36] <marcoceppi> I need help configuring Juju to talk keystone API
[14:36] <marcoceppi> keystone api v3
[14:36] <marcoceppi> rick_h: ^
[14:39] <rick_h> marcoceppi: thedac beisner_ and hml (who's not here atm) would be my go to if you're hitting issues marcoceppi. Let me see if we've got any notes around it
[14:40] <rick_h> marcoceppi: you go through https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1604#Keystone_v3_API_support ?
[23:41] <babbageclunk> wallyworld: ping?
[23:41] <wallyworld> hey
[23:42] <babbageclunk> wallyworld: It looks like endpoints in remote applications should be filtered (and aliased) by the offer, right?
[23:42] <wallyworld> yep
[23:42] <babbageclunk> wallyworld: but that doesn't seem to be done yet?
[23:42] <wallyworld> should be, but we don't support offering using an alias right now
[23:43] <wallyworld> aliasing is used when consuming
[23:43] <wallyworld> maybe there are bugs, but the code should pretty much be there
[23:43] <babbageclunk> wallyworld: but in the code it looks like it just creates an endpoint on the remote app for each in the offered application
[23:44] <babbageclunk> wallyworld: just added a test to confirm - want me to fix that?
[23:44] <wallyworld> right, sorry, i throught you were talking about offers and applications endpoints
[23:44] <wallyworld> the remote app should have all endpoints from the offer
[23:45] <wallyworld> so that additionall relations can be created as needed
[23:45] <babbageclunk> wallyworld: I mean, in application.API.makeOfferParamsFromApplication
[23:45] <babbageclunk> wallyworld: right, but at the moment it's every endpoint from the application (rather than the offer)
[23:46] <wallyworld> yeah, that doesn't look right
[23:47] <babbageclunk> wallyworld: I'm going to fix that, because I need to do the same kind of filtering on spaces and bindings, I think - we should only include space info for spaces that offered endpoints are bound to.
[23:47] <wallyworld> yep, sounds good
[23:48] <axw> wallyworld: do you have time for reviews today?
[23:48] <wallyworld> yes, it's on my todo list :-)
[23:48] <wallyworld> jut finishing a PR and then will review
[23:48] <axw> wallyworld: cool, I have several :)
[23:48] <wallyworld> \o/
[23:49] <axw> wallyworld: MAAS one is needed for 2.2
[23:49] <babbageclunk> wallyworld: Cool - do you think I should do the aliasing as well (not the UI part, just when creating the remote endpoints)? Will I need to make any changes elsewhere to make that work?
[23:49] <axw> wallyworld: and the other storage one for persistent storage
[23:50] <wallyworld> babbageclunk: there's aliasing support in many parts of the code, but not all yet. maybe leave that for a separate PR and fix it in one go
[23:50] <babbageclunk> ok, thanks