[00:01] <wallyworld> babbageclunk: we miss you
[00:01] <babbageclunk> omws!
[00:02] <babbageclunk> hangouts is being weird
[00:35] <hml> wallyworld: it wasn’t me.  ha!  it was a merge error
[00:35] <wallyworld> lol
[00:35] <hml> wallyworld: so sort of me.  :-)
[00:35] <hml> wallyworld: i’ll fix it
[00:36] <wallyworld> ta
[01:22] <wallyworld> thumper: that branch you commented on - it's targetted at a feature branch, not develop
[01:22] <wallyworld> there's a whole bunch of stuff we're holding off on
[01:34] <axw> wallyworld babbageclunk: is the agent version stuff all done? I notice that we're still looking for agent binaries in streams for dev builds, is that expected?
[01:35] <wallyworld> axw: there's still stuff to commit. streams can contain alphas/betas etc. is that what you mean?
[01:36] <axw> wallyworld: I mean if I build juju from source, should it still be looking for packaged binaries?
[01:36] <axw> wallyworld: it adds 10 seconds to bootstrap for me to find out there's nothing packaged
[01:36] <wallyworld> it will unless you use --build-agent
[01:36] <axw> would be nice to shave
[01:36] <axw> ok
[01:36] <wallyworld> otherwise without that flag it doesn't know to use a local version
[01:37] <wallyworld> so it searches for a match
[01:37] <axw> wallyworld: I thought we were using the fact that it's not a released agent (i.e. sha256 doesn't match version file) to skip that
[01:37] <wallyworld> the change from --upload-tools was that without --upload-tools it would fail
[01:37] <wallyworld> yes, that should be part of it
[01:38] <wallyworld> what is being worke don now is just the fallback bit
[01:38] <axw> okey dokey
[02:01] <axw> wallyworld: https://github.com/juju/juju/pull/8078 you were right, it was a small fix :)
[02:01] <wallyworld> looking
[02:01] <wallyworld> lol
[02:02] <hml> axw: cool - don’t see 1 char fixes often
[02:02] <hml> :-)
[02:02] <axw> hml: :)
[02:02] <hml> wallyworld: the test ended up being deceptively simple.  ha  https://github.com/juju/juju/pull/8077
[02:02] <wallyworld> looking
[02:05] <wallyworld> hml: great ty
[02:05] <hml> wallyworld: ty
[02:06] <hml> g’night all
[02:07] <axw> night hml
[02:15] <babbageclunk> axw: sorry, was out looking at a house. what wallyworld said though
[02:16] <thumper> wallyworld: oh, ok, good
[02:16] <axw> babbageclunk: cool
[03:21] <babbageclunk> wallyworld: check out my WIP please? https://github.com/juju/juju/pull/8080
[03:21] <wallyworld> babbageclunk: will do afterr meeting
[03:21] <babbageclunk> wallyworld: working on the multiple results from GetMetadata now.
[03:22] <babbageclunk> wallyworld: cool cool - have a nice meeting!
[03:22] <wallyworld> yay, meeting
[04:22] <wallyworld> babbageclunk: i left a few comments, not sure if they make sense
[04:22] <babbageclunk> wallyworld: thanks, will have a look shortly
[04:22] <wallyworld> righto, ping if yo want to discuss
[04:58] <babbageclunk> wallyworld: do you think that ValueParams needs a func that takes a stream name and returns the mirror content id then?
[04:59] <wallyworld> yeah, maybe, that could work
[04:59] <wallyworld> the flow is once a choice has been made, the actually download needs to come from the mirror
[04:59] <babbageclunk> ok, I'll add that.
[05:00] <wallyworld> i think a mirror has product files and binaries
[05:00] <wallyworld> so the index entry determines the mirror to redirect to
[05:00] <wallyworld> or something like that, it's been a loooong time
[05:01] <babbageclunk> ok, I'll check how MirrorContentId gets used and see if that change makes sense.
[05:02] <babbageclunk> had a couple of other questions, the rest of your suggestions make sense.
[05:07] <wallyworld> babbageclunk: let me know if you want to HO or whatever
[05:13] <babbageclunk> wallyworld: yeah, can we? in 1:1?
[05:14] <wallyworld> ok
[05:54] <axw> jam: are you able (allowed?) to add lp:~axwalk ssh keys to the GUI MAAS box, so I can sshuttle?
[05:55] <jam> axw: added: 2017-11-15 00:54:50,190 INFO Authorized key ['2048', 'SHA256:eVZBwvL1gnylHvyYS2+SAxyCXp1YKNVkZHA1otEtvuc', 'andrew.wilkins@canonical.com', '(RSA)']
[05:55] <jam> and some others
[05:55] <axw> jam: thanks
[06:15] <jam> wallyworld: axw: I just saw "unit-blah-0: juju.worker.uniter.remotestate update status timer triggered" does that have to do with CMR or is the 'remotestate' there just the fact that state is on the controller
[06:15] <jam> I'm trying to figure out what 'remotestate' has to do with a local charm and no CMR involved.
[06:15] <jam> but maybe i'm misreading something
[06:16] <wallyworld> jam: remotestate refers to the other side of the relation
[06:16] <wallyworld> that term existed before cmr
[06:16] <wallyworld> IIANM
[06:19] <axw> jam wallyworld: not quite. remotestate is about what's in the state db
[06:19] <axw> vs. local state, which is what the unit has done to date
[06:19] <axw> the unit reconciles local state with remote
[06:19] <axw> uniter*
[06:20] <wallyworld> ah right, yes
[06:20] <axw> but yeah, nothing to do with CMR
[06:20] <wallyworld> i was thinking of "remote unit"
[06:20] <wallyworld> and remote unit data
[06:24] <jam> axw: has your $ vs \$ been landed?
[06:24] <jam> axw: I was testing anastasiamac's patch on action debug-hooks and thinking that maybe the "failed" values are because that was missing.
[06:24] <axw> jam: yeah it has
[06:24] <axw> jam: what failed values?
[06:25] <jam> axw: you can hook into an action request, but you exit 0 and it reports "failed" as the action result
[06:26] <axw> jam: yeah, if my commit's not in the branch, that would explain it
[06:26] <jam> I'll try rebuilding merging dev and see if that changes
[06:26] <axw> jam: hm, anastasiamac's branch does have it
[06:29] <jam> axw: ok, I think its because you have to actually run the action and have it report back something, vs just the return code
[06:30] <jam> doing ./actions/ping and then exit seemed to give me a completed value
[06:30] <axw> okey dokey
[06:30] <axw> seems a little backwards maybe
[06:31] <axw> jam: https://github.com/juju/juju/pull/8082 fixes the MAAS issue, QA'd on jujugui MAAS
[06:31] <axw> jam: could you please take a look?
[06:31] <axw> I'm taking the kids to martial arts shortly, will be back in a couple of hours
[06:33] <jam> looking
[06:35] <jam> axw: does your patch break "juju deploy --to zone=" ?
[06:35] <jam> or is that being resolved in the value that is passed into StartInstance ?
[06:35] <axw> jam: shouldn't, that's covered by DeriveAvailabilityZones
[06:35] <axw> I'll verify that when I get back
[06:36] <jam> axw: it seems overbroad to turn all provisioning failures into an AZ failure
[08:24] <jam> axw: had a question about leases an 2.2 and "juju models" not sure if you have context, but when I'm done with standup, I'd like to chat a bit
[08:43] <jam> axw: your patch effectively deals with bug #1706462 doesn't it?
[08:43] <mup> Bug #1706462: juju tries to acquire machines in specific zones even when no zone placement directive is specified <cdo-qa> <foundations-engine> <juju:Triaged by ecjones> <MAAS:Invalid> <https://launchpad.net/bugs/1706462>
[10:14] <wpk> externalreality: have you been changing configuration on jujugui maas recently?
[10:15] <externalreality> Yes, I have changed the configuration of 2 machines nuc.8 and nuc.7 I think the machines are called. Generally, I changed them to have 3 partition 1 mounted as root and 2 configured to Raid0 for reproduction of a bug
[10:15] <externalreality> No other node was changed
[10:17] <externalreality> I have also modified tags
[10:17] <externalreality> wpk, have a broken something you were doing?
[10:17] <externalreality> These changes were made a few days ago.
[10:27] <externalreality> wpk, Is everything ok?
[10:32] <wpk> externalreality: I'm getting weird bootstrap error
[10:32] <wpk> 11:15:46 ERROR juju.cmd.juju.commands bootstrap.go:515 failed to bootstrap model: cannot start bootstrap instance: cannot run instances: cannot run instance: No available machine matches constraints: [('zone', ['azone']), ('mem', ['3584']), ('agent_name', ['a5bd9766-22fa-4d81-8748-c719f85fd1cb'])] (resolved to "mem=3584.0 zone=azone")
[10:32] <wpk> and I wonder if that's something I broke
[20:51] <balloons> can I get a review of https://github.com/juju/juju/pull/8086? wallyworld, thumper, this is the second piece, patches
[20:53] <babbageclunk> balloons: won't this monkey with our working copies when we build using the makefile?
[20:54] <balloons> babbageclunk, it will indeed. comments welcome.. I had it as a seperate makefile target at one point. I monkeyed with it a bunch, but figured I'd just toss out the PR and see what people think
[20:57] <babbageclunk> balloons: for one thing, it will mean that mgo and other patched packages are always dirty after a build, so make godeps will fail.
[20:59] <wpk> 1. it won't work if there are no patches
[20:59] <balloons> yes, godeps will fail
[21:00] <wpk> 2. I'd make it a separate target, with 'undo' (-R) option
[21:00] <babbageclunk> balloons: We could mitigate that by having something to unapply the patches? But that seems risky - what if someone was making a change to the package?
[21:00] <wpk> https://github.com/juju/juju/pull/8084 anyone? (for rc1)
[21:01] <balloons> we could have a 'release-build' target. For the idea of rollback is also fine. patch supports reversing
[21:02] <babbageclunk> balloons: I like release-build
[21:03] <babbageclunk> balloons: I guess as we get more patches (I didn't realise there were so many now!) the divergence of behaviour between patched and unpatched juju might be a problem.
[21:08] <babbageclunk> (for devs doing local testing, I mean)
[21:13] <balloons> that's why I fell on the side off being heavy handed with always building them
[21:14] <balloons> and to make you feel the pain a little I guess so we get a better solution :-)
[21:14] <balloons> but honestly it could be annoying to have your sources mucked with
[21:18] <babbageclunk> yeah, I think we really need to carve out some time to implement the fork support in godeps.
[21:19] <babbageclunk> One of the patches is against a package where the last commit was in April 2015
[21:20] <babbageclunk> Or in that case we should maybe just fork it and actually update the imports.
[21:23] <balloons> babbageclunk, well, I was pushing for moving to deps, which I think folks are aligned as a long-term vision to do
[21:24] <babbageclunk> oh, I missed that - presumably it supports forking without changing imports? <reads up on deps>
[21:25] <babbageclunk> ugh, too many go packages with variations on the name dep
[21:25] <babbageclunk> which I guess shows that there's a problem
[21:26] <babbageclunk> balloons: do you mean https://github.com/golang/dep?
[21:27] <balloons> babbageclunk, aye
[21:27] <babbageclunk> cool, thanks
[21:29] <balloons> so it sounds like everyone is in favor of wpk's suggestions then. I'll just propose them
[21:29] <balloons> well your's too babbageclunk.. aka, release-build, and an 'undo'
[21:30] <babbageclunk> balloons: thanks! wpk can have the glory. :)
[22:01] <wallyworld> babbageclunk: how are they hangin' ?
[22:03] <babbageclunk> wallyworld: still making those changes we discussed yesterday.
[22:03] <wallyworld> ok, let me know if you get blocked so we can land today
[22:11] <hml> wallyworld: do you have a few minutes for an HO?
[22:12] <wallyworld> hml: sure
[22:12] <wallyworld> standup one
[22:12] <hml> wallyworld: on my way
[22:15] <balloons> axw, any idea on http://qa.jujucharms.com/releases/5946/job/add-cloud-vsphere/attempt/1298#highlight?
[22:18] <wpk> babbageclunk: https://github.com/juju/juju/pull/8084 ?
[22:18] <babbageclunk> wpk: sure
[22:19] <wpk> tx
[22:33] <babbageclunk> wpk: A couple of comments, but approved
[22:39] <wallyworld> hml: i just re-read that bug in more detail - he makes the point that the dasjboard download is for Ubuntu deployed openstacks, and that the openrc stuff is generic. it probably is worth considering, but i'll move the bug to a 2.3.x milestone
[22:46] <wallyworld> thumper: fyi, i created  2.3.1 milestone for things which miss the 2.3.0 cut
[22:47] <thumper> ta
[22:48] <wallyworld> thumper: moved one bug off the rc1 milestone due to churn in requirements and that it is more a micro feature; no need to rush a fix and regret it later
[22:48] <thumper> ack
[22:49] <babbageclunk> wallyworld: making LookupConstraint.IndexIds return the stream as well...
[22:49] <wallyworld> ok i think :-)
[22:49] <thumper> wallyworld: when did we change the apiserver to connect to itself rather than a random other one>?
[22:49] <babbageclunk> wallyworld: would it make more sense to have the interface have .Streams() and .IndexId(stream string)?
[22:50] <wallyworld> thumper: what's the context of the connection?
[22:50] <wallyworld> babbageclunk: maybe, i'd need to look at the code
[22:50] <thumper> apiservers would get wedged during upgrade as they tried to connect to a different server
[22:50] <thumper> and got told "sodd off, I'm upgrading"
[22:50] <thumper> but it meant that they couldn't upgrade
[22:50] <wallyworld> oh dear
[22:51] <wallyworld> um, i can't recall tbh
[22:51] <wallyworld> i rings a bell though
[22:51] <wallyworld> not sure if 2.1.x or 2.2.x
[22:52] <wpk> babbageclunk: thanks, fixd
[22:53] <wallyworld> babbageclunk: so IndexIds() is called in one spot inside GetProductsPath() - do we need the stream there?
[22:54] <babbageclunk> wpk - you should name the error return so that the if err refers to that one. Otherwise there's a case where the err that the defer sees is nil even though the func is returning an error.
[22:55] <babbageclunk> wpk: that might not be very clear.
[22:56] <babbageclunk> wallyworld: we need it there (or somewhere around there) so we can make the mirror content id depended on the stream.
[22:57] <wallyworld> yeah figured as much, i just didn't see any reference to the mirror data near the call site, but i'm not 100% familiar with the code detail
[23:03] <babbageclunk> wpk: added a (hopefully) clearer explanation on the PR
[23:03] <babbageclunk> wpk: does it make sense?
[23:06] <babbageclunk> wallyworld: I'll do it the way we talked about for now.
[23:07] <wallyworld> babbageclunk: whatever works :-)
[23:24] <wpk> babbageclunk: .. and that's why I wanted to avoid conditional defer :P
[23:24] <babbageclunk> wpk: I mean, you could have said that. :)
[23:25] <wpk> babbageclunk: I won't make it for rc1, but I will have that in mind (it's only cosmetic, as the device will be eventually cleaned when the machine is removed)
[23:26] <babbageclunk> wpk: ah, ok
[23:26] <wpk> the fact that { foo, bar := baz() } shadows outside scope bar is one of the few things I hate
[23:26] <wpk> babbageclunk: nothing will leak
[23:27] <babbageclunk> wpk: yeah, scoping stuff can be pretty subtle and annoying.
[23:41] <hml> wallyworld: agreed, openrc is more generic - though missing important info potentially
[23:41] <wallyworld> hml: yeah, we can prompt for missing if needed
[23:41] <hml> wallyworld: just needs to be thought out. :-)
[23:41] <wallyworld> yup
[23:45] <axw> jam: sorry, I saw your message about chatting yesterday after I got back, but then got distracted. can chat today if you still want to.
[23:45] <axw> jam: my patch does not address https://bugs.launchpad.net/juju/+bug/1706462 AFAICT
[23:45] <mup> Bug #1706462: juju tries to acquire machines in specific zones even when no zone placement directive is specified <cdo-qa> <foundations-engine> <juju:Triaged by ecjones> <MAAS:Invalid> <https://launchpad.net/bugs/1706462>
[23:51] <axw> balloons: no idea. braixen/vcenter seems to intermittently shit itself, and I don't know why