[00:43] <anastasiamac> a super easy one, plz \o/ https://github.com/juju/juju/pull/7693
[01:01] <hml> anastasiamac: looking
[01:04] <hml> anastasiamac: just a tiny nit; looks okay to me
[01:08] <anastasiamac> hml: awesome \o/ ta... (i've ignored the comment since the alias still stayed but sure :D updated just for u...)
[01:09] <anastasiamac> ignored initially, i mean :D
[01:09] <hml> anastasiamac: ty!
[02:27] <babbageclunk> axw: Hey, any reason not to put go generate into the makefile install target for 1.25 upgrades?
[02:28] <babbageclunk> axw: I guess there wasn't any need for you since you weren't changing the underlying script?
[02:29] <axw> babbageclunk: no particular reason for or against doing that, I just went with the go native approach
[02:29] <axw> babbageclunk: unlikely to have to change it
[02:31] <babbageclunk> axw: ok, I'm going to add it for mine. Otherwise I'm probably going to forget a generate and then get really confused about why it's not working.
[02:31] <axw> babbageclunk: fair enough. feel free to change that one too if it's easy enough
[02:32] <babbageclunk> axw: oh hang on - I don't understand what you're saying.
[02:32] <axw> babbageclunk: I took what you said to mean you're going to add a makefile target for your thing
[02:34] <babbageclunk> axw: no, I meant I was going to run go generate ./commands from the install target (so I wouldn't forget to run it after changing the upgrade script).
[02:34] <axw> babbageclunk: oh ok, that sounds fine too
[02:34] <babbageclunk> cool
[02:35] <axw> unconditional make targets make me sad, but it's just a little project ;)
[04:00] <wallyworld> babbageclunk: if you get time before your eod, would love a review. but don't interrupt your 1.25 upgrade work if you're in the middle of something https://github.com/juju/juju/pull/7694
[04:11] <babbageclunk> wallyworld: sure - looking now
[04:11] <wallyworld> yay, ty
[05:02] <babbageclunk> wallyworld: reviewed
[05:02] <wallyworld> babbageclunk: awesome, thanks
[05:03] <wallyworld> babbageclunk: it will be used to populate status on the offering side
[05:03] <wallyworld> to show who is connected to each offer and what endpoint they are connected to
[05:04] <wallyworld> also to allow easy removal of remote relations on the offered side
[05:07] <wallyworld> babbageclunk: see if my explanation in the PR makes sense
[05:12] <babbageclunk> wallyworld: How can you use it in status on the offering side? Will the consuming side push the information to the offering controller?
[05:13] <wallyworld> the collection containing the details of who is connected to an offer is set up in the register relation api call
[05:13] <wallyworld> s/set up/populated
[05:14] <wallyworld> and register relation comes from the consumer side
[05:14] <babbageclunk> wallyworld: OHH, I misread it as being stored in the consuming side.
[05:14] <wallyworld> it's messy for sure
[05:15] <babbageclunk> wallyworld: But it's actually in the offering side, in a different facade from where the macaroon is minted. Ok, that makes more sense.
[05:15] <babbageclunk> wallyworld: yeah, ok that makes sense then.
[05:16] <wallyworld> yeah. and the macaroon will gain a Location URL which will be used to discharge the 3rd party caveat that the user has access to the offer
[05:16] <wallyworld> but thta's not done yet
[05:16] <wallyworld> for controller->controller it will be a local url
[05:16] <wallyworld> on the offering controller
[05:17] <babbageclunk> ok
[05:21] <babbageclunk> axw: ping?
[05:22] <axw> babbageclunk: pong, sorry was riding
[05:22] <axw> oh that was a minute ago... not sorry ;p
[05:24] <babbageclunk> ha!
[05:25] <babbageclunk> axw: Actually I think I've answered my own question
[05:25] <axw> yay
[05:26] <babbageclunk> axw: Having some confusion over whether the permission denied I'm getting was because I couldn't read the system identity or create the destination dir, but I think it's the latter.
[05:27] <axw> babbageclunk: okey dokey. everything runs through sudo, so shouldn't be the former
[05:27] <axw> but then... shouldn't be the latter either...
[05:27] <axw> babbageclunk: FYI I have a backup-lxc PR up: https://github.com/juju/1.25-upgrade/pull/8. no rush to review. I'm working on the lxc-to-lxd command now
[05:28] <babbageclunk> well, this is on the hop from the state-server machine to the other machines, so I think it's connecting as ubuntu
[05:28] <babbageclunk> axw: oh, ok - I'll take a look in a bit.
[05:28] <axw> ah ok
[05:28] <babbageclunk> axw: or I might look tomorrow morning if it's no difference to you?
[05:28] <axw> babbageclunk: it can wait till tomorrow if you'd prefer not to context switch
[05:28] <axw> yep
[05:28] <babbageclunk> ok cool
[22:17] <rick_h> axw: morning
[23:01] <wallyworld> rick_h: andrew will be online soon. thanks for the excellent storage feedback
[23:01] <rick_h> wallyworld: all good, I wanted to see what i was missing for the --attach-storage stuff so I can move forward some more and maybe cover it for juju show material tomorrow. I'll chill out and be patient. :)
[23:02] <wallyworld> rick_h: yeah, that should have worked
[23:03] <rick_h> wallyworld: yea, I was wondering if there's a FF or something that was left out of the blog post/docs or something? It's not in the juju deploy --help or anything so it's like it's not there.
[23:03] <wallyworld> rick_h: yeah, weird. just joining a new meeting, so will be distracted
[23:04] <rick_h> wallyworld: all good, I'll be patient. ty