[03:53] <wallyworld> hpidcock: i'll have a new PR ready soonish but need to land that other one first, just sayin' :-)
[03:54] <hpidcock> wallyworld: sorry I'll have a look. Didn't you want tlm to also have a look at it?
[03:54] <wallyworld> yeah, for educational purposes
[03:54] <wallyworld> so see how lots of different key patterns are implemented
[03:55] <wallyworld> i have a meeting and won't be quite ready for maybe 45 minutes or something so no great rush
[03:55] <hpidcock> wallyworld: all good. I'm gonna grab some lunch anyway brb
[05:51] <hpidcock> wallyworld: getting close
[05:51] <hpidcock> almost done, got a bunch of comments
[05:52] <wallyworld> ok, ta
[05:55] <hpidcock> wallyworld: added my comments
[05:55] <hpidcock> some are probs not valid
[05:55] <hpidcock> but it looks good otherwise
[05:56] <wallyworld> ty, looking
[05:58] <wallyworld> hpidcock: my eyes hate looking at "ID" for some reason. i'll have to squint as i make the change
[06:03] <hpidcock> wallyworld: hah nice, we can discuss this all day
[06:04] <hpidcock> but we probs both don't have time
[06:04] <wallyworld> we use docId all over but i ain't touching that
[06:04] <hpidcock> I meant because it's new
[06:04] <wallyworld> yeah i know
[06:08] <hpidcock> also from my understanding id is a Latin word we use in English (id est or i.e.), so I think that's why ID is generally the accepted abbreviation (also to keep consistency across projects)
[06:10] <hpidcock> I mostly don't care, just all the linters crying at me
[06:15] <wallyworld> me either, just a personal visual thing
[06:16] <hpidcock> but I think I care more than you haha
[06:23] <wallyworld> hpidcock: fixes pushed
[06:23] <wallyworld> thanks for review
[06:24] <wallyworld> i answered a couple of comments
[06:24] <hpidcock> approved
[06:25] <wallyworld> awesome
[06:25] <wallyworld> ty
[06:25] <tlm> +1
[06:25] <wallyworld> tlm: anything unclear?
[06:25] <tlm> no just missing a little context for the whole package
[06:25] <wallyworld> yeah, there's a lot of contex in working on juju
[06:26] <tlm> i'll get my hands dirty in there next time something comes up
[06:26] <wallyworld> hopefully what you saw will trigger some meories
[06:26] <wallyworld> when you go to do it for reals
[06:26] <tlm> PTSD
[06:26] <wallyworld> yup
[06:26] <wallyworld> one this one lands i'll push up another
[06:26] <wallyworld> to handle the CLI changes that use the new stuff
[06:27] <wallyworld> for the run action bits, still got to do list-tasks, list-operations rework
[07:18] <wallyworld> hpidcock: we have a problem with juju-run - it can stop working for reasons yet to be determined
[07:19] <wallyworld>  mkubectl -n test exec -ti mariadb-k8s-0 bash
[07:19] <wallyworld> root@mariadb-k8s-0:/# /usr/bin/juju-run ls
[07:19] <wallyworld> ERROR r.runner.RunCommands: no runner is registered for unit mariadb-k8s/0
[07:19] <wallyworld> and unit shows as failed in status
[07:20] <wallyworld> happens after running a status-set
[07:20] <wallyworld> using juju-run
[07:20] <hpidcock> interesting
[09:23] <stickupkid> manadart, ping
[09:24] <manadart> stickupkid: Pong.
[09:24] <stickupkid> quick jump in daily
[11:12] <nammn_de> manadart: regarding the race condition I mentioned yesterday in daily. Did you have a suggestion in mind yesterday? I don't have any great idea in mind for this.  https://github.com/juju/juju/blob/ff32067866004a0a04d5dba8e281dea7857f33ea/cmd/juju/status/status_internal_test.go#L6096
[11:13] <manadart> nammn_de: I haven't delved into that one yet.
[11:14] <stickupkid> nammn_de, manadart would be happy to have a look at that later
[11:15] <nammn_de> stickupkid: cool thanks! Nothing simple as useful came into my mind
[11:20] <nammn_de> manadart: how can I understand the life concept of spaces? Do I need to take them into consideration for removing?
[11:24] <manadart> nammn_de: It is currently not used. The pattern for responding to space changes (were it required) would be as for machines - a worker that watched for space changes and acted based on topology/life/etc changes. But we don't require such a thing at this point.
[11:24] <manadart> So ignore it for now. We can think about it and discuss if required later.
[11:25] <nammn_de> manadart: ta
[11:29] <stickupkid> manadart, can you see if I'm way off base with the last commit (need to rebase once my other PR lands) https://github.com/juju/juju/pull/11188
[11:38] <achilleasa> while applying the Open/Close port changes from the Ports model to the Unit, it turns out that we can effectively replace the Open/ClosePort(s) methods on Unit with a single OpenClosePortsOnSubnet method. In the future we can update this method to work with endpoints instead of subnet IDs. Any objections to refactoring this all the way to the uniter facade?
[11:39] <achilleasa> (there are a few TODOs in the uniter model for fixing the Open/Close port variants)
[11:46] <manadart> stickupkid: Looks the goods. Looks like you need to populate the network ID on the opts: https://github.com/go-goose/goose/blob/v2/nova/nova.go#L318
[11:46] <stickupkid> manadart, wicked, thanks
[11:47] <stickupkid> I'm just messing around thinking how to test this atm
[11:47] <stickupkid> manadart, I'm sure we could extract this piece of logic, it's almost identical to ec2
[11:48]  * manadart nods.
[11:49] <stickupkid> let me think (brain gears start whirring)
[12:25] <rick_h> morning party folks
[14:24] <nammn_de> manadart: first patch for apiserver is ready for cr https://github.com/juju/juju/pull/11186/files some things I werent sure and thus added them as comments in the PR
[14:24] <manadart> nammn_de: OK, will look in a bit.
[15:00] <stickupkid> manadart, if we can't find a networkId, then what? skip em?
[15:00] <stickupkid> manadart, it's not like I can magically make one up i guess
[15:01] <manadart> stickupkid: hml previously mentioned O7k deployments where the network(s) is not exposed. For these I don't think we can do anything, so yeah, skip for now.
[15:02] <stickupkid> sick, integration tests at the unit level
[15:26] <hml> rick_h:  if you approved the JUJU_HOOK_NAME pr, we can get the conflicts resolved and land it.  :-). you’ve requested changes currently
[15:31] <manadart> stickupkid: https://github.com/juju/juju/pull/11185
[15:32] <rick_h> hml:  oh sorry, which one?
[15:32] <hml> rick_h: https://github.com/juju/juju/pull/10969
[15:32] <rick_h> ty
[15:32] <rick_h> hml:  done
[15:57] <stickupkid> manadart, https://github.com/juju/juju/pull/11188
[15:57] <manadart> stickupkid: Yep. Factored your feedback in too.
[15:57] <stickupkid> nice
[16:17] <manadart> stickupkid: Reviewed yours. I think we need a bit more. Going AFK to sort out kids. Will check back later this eve; no hurry if you're done for the day.
[16:18] <stickupkid> manadart, I would suspect so, let's meetup...
[23:23] <babbageclunk> hpidcock: quick q about go.mod?
[23:24] <hpidcock> fire
[23:25] <babbageclunk> I'm trying to use gopkg.in/mgo.v2 but replace it with github.com/juju/mgo, but I'm getting the following error:
[23:25] <babbageclunk> go: finding github.com/juju/mgo v0.0.0
[23:25] <babbageclunk> go: github.com/juju/mgo@v0.0.0: unknown revision v0.0.0
[23:25] <tlm> does that git repo have a v0.0.0 tag ?
[23:25] <babbageclunk> It's true that there's no v0.0.0 tag on juju/mgo, but there aren't any on other juju repos I'm using
[23:25] <babbageclunk> eg juju/errors
[23:26] <babbageclunk> but this is the only one I'm using replace on
[23:26] <tlm> you would have to use a git sha instead if that tag is missing
[23:26] <babbageclunk> Do I need to add a v0.0.0 tag to juju/mgo? Or is there something I can do locally
[23:26] <tlm> sorry stole from hpidcock
[23:26] <babbageclunk> ooh, ok - I'll try that, thanks tlm
[23:27] <babbageclunk> (thanks for nothing hpidcock! ;)
[23:27] <tlm> I could be very wrong also babbageclunk
[23:27] <hpidcock> https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
[23:27] <babbageclunk> if you are I'll take the thanks back
[23:28] <babbageclunk> hpidcock: oh - because I'm replacing a .v2 package?
[23:30] <babbageclunk> tlm: seemed happy with that (well, it built anyway)
[23:30] <babbageclunk> consider those thanks banked
[23:31]  * tlm counts he's interest
[23:32] <hpidcock> I'm guessing you went go mod init and it imported godep dependencies?
[23:41] <hpidcock> I think the import tried to use v0.0.0 as the version. The Gopkg.toml file specifies mgo from github.com/juju/mgo and uses the master branch. So I think it is trying to use v0/v1 semantics. We should create a v2 branch or create a v2.0.0 tag off master. Then change the url to be github.com/juju/mgo/v2
[23:42] <hpidcock> But the sha way is fine for now
[23:43] <hpidcock> Things are just going to get weird when we add go.mod to subpackages and all we depend on is sha. Go.mod will be unable to resolve shas then.
[23:44] <hpidcock> But with the semantic versioning, if a dependency needs a higher version, go mod can bump the projects dep to that minor version.