[01:41] <wallyworld> kelvinliu: we already have a really old version of a python juju client in the stable juju packages archive https://launchpad.net/~juju/+archive/ubuntu/stable/+packages
[01:42] <wallyworld> we should be able to publish a newer "python-libjuju" ppa
[01:42] <wallyworld> to that juju stable archive
[01:42] <kelvinliu> they were pushed 5yrs ago
[01:43] <wallyworld> yeah, realy old
[01:43] <wallyworld> so we just need to push our new "python-libjuju" ppa
[01:43] <kelvinliu> yeah
[01:43] <wallyworld> to that juju stable archive
[01:44] <wallyworld> can do that and update the release process doc for libjuju
[01:44] <kelvinliu> that one was manually pushed
[01:44] <wallyworld> yeah, so updating process doc after doing it manually is all we need for now
[01:45] <kelvinliu> yep
[02:05] <kelvinliu> wallyworld: got a question about the quoteStrings in config process, free to have a quick HO?
[02:05] <wallyworld> sure
[02:40] <thumper> wow it is raining hard here today
[02:40] <thumper> makes me pleased that the stadium has a roof
[02:42] <wallyworld> elton had to abandon a concert here in OZ due to gale for rain, wrecked all the sound gear etc
[02:43] <tlm> now we have gail force wind
[02:54] <hpidcock> Best day of February so far, nice and cool
[04:08] <kelvinliu> wallyworld: should I just continue to change to the spec in the doc?
[04:09] <wallyworld> what was the final outcome of the discussion? i didn't hear it due to sound issues
[04:09] <wallyworld> i disagree with splitting it as it sucks for the user
[04:09] <kelvinliu> wallyworld: stdup?
[04:09] <wallyworld> ok
[09:27] <nammn_de> manadart: around to talk about rename-space? 2 review comments I am not sure
[09:27] <nammn_de> https://github.com/juju/juju/pull/11143#discussion_r373477221 (missing information) and https://github.com/juju/juju/pull/11143#discussion_r373573802 (I tried to solve, not sure if thats what you meant)
[09:41] <manadart> nammn_de: I am in Daily.
[09:42] <nammn_de> manadart: 2 min, cannot find phone for 2fa
[10:16] <achilleasa> jam: manadart regarding our chat on side-effects yesterday, if my open/close ports operation uses the same Ports model and I stack an [open, close] operation, the ports slice of the model will end up in an inconsistent state (open appends an entry, close replaces the port list with a filtered version)
[10:17] <achilleasa> I could tweak the done logic for close to make it work but not sure if it's worth the effort given that the Ports model will be thrown away
[10:18] <achilleasa> (e.g. have close track the entries to be removed instead of the remaining entries and filter the port list in Done)
[10:27] <manadart> achilleasa: Seems reasonable. We discussed how the object curation for consistency with state post-DML execution is kind of a waste when we they are so short-lived.
[10:28] <manadart> manadart: And probably less relevant than ever if the particular entities live in the model cache.
[10:28]  * manadart tags himself like an idiot.
[10:29] <achilleasa> manadart: actually, now that I look at it again, it's a bit more complicated. open ports issues an updatePortsDocOps whereas close ports issues a setPortsDocOps
[10:30] <achilleasa> my guess is that the first txn.Op block will succeed but the later will not due to the revnos and cause the txn to fail
[10:30] <achilleasa> manadart: quick ho?
[10:30] <manadart> achilleasa: Yeah, give me a mo'
[10:30] <achilleasa> perhaps I need an "opencloseports operation"
[10:49] <stickupkid> manadart, got a sec?
[10:49] <stickupkid> i'm either being stupid or stupid
[10:51] <manadart> stickupkid: In Daily with achilleasa.
[10:51] <stickupkid> i'll gate crash
[10:54] <stickupkid> https://jenkins.juju.canonical.com/job/nw-deploy-focal-amd64-lxd/24/console
[11:22] <nammn_de> manadart: incorporated your feedback + updated qa and should now be ready . https://github.com/juju/juju/pull/11143
[12:06] <manadart> nammn_de: Will look soon.
[12:17] <jam> achilleasa: sounds like we want to have a $pullAll instead of a $set
[12:20] <achilleasa> jam: turns out you cannot compose the two individual ops together without jumping through hoops. As a workaround, I made them into a single op that calculates the final port range list and either does insert or $set. Original tests pass and I am adding some extra ones for composed open/close
[13:14] <nammn_de> manadart rick_h: do we allow the deletion of provider provided spaces?  (Maas)
[13:14] <manadart> nammn_de: No.
[13:21] <rick_h> +1, nope the world is the world we have to live in it
[14:14] <achilleasa> can anyone explain to me why this test works? https://github.com/juju/juju/blob/develop/state/unit_test.go#L1594 I don't see any unit-is-alive (there is one for model-is-alive though) assertions in the open/close txn code https://github.com/juju/juju/blob/develop/state/ports.go#L199
[14:20] <stickupkid> rick_h, fyi: https://github.com/lxc/lxd/issues/6833
[14:20] <rick_h> stickupkid:  <3
[14:42] <manadart> Small mechanical change: https://github.com/juju/juju/pull/11181
[14:42] <stickupkid> manadart, me look
[14:48] <stickupkid> manadart, I looked, also saw you may have fixed a runtime panic?
[14:48] <manadart> stickupkid: We've never hit it AFAIK.
[14:48] <stickupkid> good piece of code then
[14:49] <stickupkid> kill it?
[15:02] <manadart> stickupkid: Volume attachment plans are used by the OCI (Oracle) provider for attaching volumes to instances where the local machine needs to take some actions, I believe.
[15:02] <stickupkid> manadart, but we know that would never have worked, so isn't exercised
[15:04] <stickupkid> manadart, whilst we're at CR sharing https://github.com/juju/juju/pull/11182
[15:10] <manadart> stickupkid: Yep. Can you look at the commit I just pushed to mine?
[15:29] <rick_h> jam:  got it updated and pushed together a bundle with the bits in it https://discourse.jujucharms.com/t/monitoring-juju-controllers/430
[15:32] <stickupkid> manadart, I think we should add a comment and it's done :)
[15:37] <manadart> stickupkid: OK.
[15:38] <stickupkid> something of the lines, "we have no idea what we're doing, but this should fix it"
[15:38] <stickupkid> haha
[15:40] <manadart> nammn_de: I am going over your patch again. I was thinking that given the number of files touched for these, we should break future ones up.
[15:40] <manadart> We can add the API server, client and cmd parts in separate patches.
[15:44] <nammn_de> manadart: agree, should makes everything easier to review
[15:47] <nammn_de> manadart: while running through it. Should we be able to rename-space `alpha`? I did not catch the case if someone wants to rename. i just did, because I thought that we hold by the spaceID and not spaceName
[15:49] <hml> manadart:  it looks like there may have been work done on the duplicate subnets already, but some of it is a work around.  background in https://bugs.launchpad.net/juju/+bug/1733266
[15:49] <mup> Bug #1733266: Autodetection of subnets prevents bootstrap when there are duplicate subnet ranges <cpe-onsite> <network> <openstack-provider> <juju:Fix Released by jameinel> <juju 2.3:Fix Released by jameinel> <https://launchpad.net/bugs/1733266>
[15:50] <manadart> nammn_de: We should prevent it. There are some conditions interrogating the name. It can be done in the cmd.
[15:50] <nammn_de> manadart: oh, I need to add this then.
[15:51] <nammn_de> manadart: I will let you finish review first and add the alpha case in the cmd
[15:51] <manadart> hml: Thanks, I'll take a look. I still need to work out why I am not seeing subnets from another network in the same tenant.
[16:09] <achilleasa> manadart: does it work with dev branch?
[16:10] <manadart> nammn_de: Actually, we need to check at the API server, in case someone is using say, pylibjuju.
[16:11] <manadart> nammn_de: QA is looking OK here. Go ahead and add that change.
[16:11] <nammn_de> manadart: will do.
[16:11] <manadart> achilleasa: The network thing? I am using develop HEAD.
[16:12] <nammn_de> manadart: I promise my next pr is gonna be puny :D
[16:12] <manadart> Well, HEAD-ish.
[16:20] <nammn_de> manadart: added
[16:38] <achilleasa> manadart: I am thinking of modifying SettingsGroup in state/settings.go to implement ModelOperation instead of having a Write() method (func equiv to buildTxn+apply). I added this type when I introduced the UpdateNetworkInfo call in uniter. IIRC you recently added a settings op type.
[16:38] <achilleasa> I can probably switch the code to use that and remove SettingsGroup. Thoughts?
[16:39] <achilleasa> nammn_de: I think you used the ^^ type in one of your recent PRs
[16:45] <stickupkid> I wonder why we never used middleware for auth of facades
[16:46] <stickupkid> used composition rather than logic checks
[16:46]  * stickupkid thought of the day
[16:51] <nammn_de> achilleasa:  So I used ModelOperation for the PRs
[16:53] <nammn_de> so no real throughts on the settingsgroup refactor. Their write would comply with applyoperation.  Modeloperation I think
[16:53] <nammn_de> but it does make sense. As they comply both
[16:53] <achilleasa> nammn_de: can you point me to that PR?
[16:54] <nammn_de> achilleasa: https://github.com/juju/juju/pull/11143/files#diff-c2f3a22eae3088d2abd0727df01272e4R2
[16:54] <nammn_de> opfactory.go and rename.go
[16:55] <achilleasa> thanks!
[16:55] <nammn_de> stickupkid: yeah, would be really cool.
[17:19] <achilleasa> manadart: nammn_de actually the SettingsGroup is still required because my use-case requires persisting multiple *Settings in a single txn. I will make it into an operation for consistency
[17:26] <roadmr> rick_h: hey there :)
[17:26]  * roadmr about to pester Rick again heh
[17:26] <rick_h> roadmr:  howdy
[17:26] <rick_h> pester away
[17:27] <roadmr> rick_h: so the list of urls that juju hits, that you obtained from logs
[17:27] <roadmr> rick_h: it has method, url, query string basically. right?
[17:27] <rick_h> roadmr:  right
[17:28] <roadmr> rick_h: would it be possible to get user-agent as well?
[17:29] <roadmr> rick_h: with that we can first weed out non-juju clients and have a better idea of what juju itself needs
[17:29] <rick_h> roadmr:  all those are a generic "go client" user agent
[17:30] <roadmr> rick_h: also lets us see how the api access patterns differ between our targeted juju versions (1.25 and 2.x IIRC)
[17:30] <rick_h> roadmr:  and juju and the charm command are the only ones I am aware of
[17:30] <roadmr> rick_h: ahh that's super unfortunate :( whaat
[17:30] <roadmr> rick_h: ah but the charm command is python, right? most likely not a go client string
[17:30] <roadmr> rick_h: I'd settle for being able to weed out non-jujus
[17:30] <rick_h> roadmr:  so the charm command is a mix of go and python.
[17:30] <roadmr> argh :)
[17:31] <rick_h> roadmr:  trying to recall, I thought I weeded out obvious charm commands
[17:31] <roadmr> rick_h: ah yes, you said "exact requests we're getting form go clients (juju)"
[17:31] <rick_h> roadmr:  as far as different Juju's, my first instinct is forget juju 1.2X as the only folks we care about that are internal and they use offline charms with mojo ime
[17:32] <roadmr> rick_h: ok, that sounds good
[17:32] <rick_h> roadmr:  not to say I did it perfect but do recall trying to really focus it in and did a lot of cleaning of that data
[17:33] <roadmr> rick_h: got it... doh I'm dumb, mind if we move this to #snapstore so facu can also be in the loop?
[17:34] <rick_h> roadmr:  yea, or I'd suggest the canonical #juju channel so other folks on the team can see as well
[20:42] <thumper> rick_h: do you know who to chase for https://github.com/juju/charmstore/issues/895#issuecomment-576562396
[20:44] <rick_h> thumper:  mhilton was working with rt's to folks around these when they happened. I thought this one got corrected
[20:44] <rick_h> maybe the bug didn't get closed?
[20:44]  * rick_h checks rt email history
[20:44] <thumper> maybe
[20:45] <rick_h> thumper:  yea, marked as resolved
[22:04] <wallyworld> rick_h: thumper: test passed this time no problem
[22:05] <wallyworld> we have seen issues if the slaves are busy
[22:06] <wallyworld> thumper: btw, https://github.com/juju/juju/pull/11172 is ready for looking at