[00:13] <thumper> wallyworld: are you looking at the pinger issue?
[00:13] <wallyworld> thumper: i had a brief look and will look again a bit later after standup, but need to get some other stuff done first
[00:14] <thumper> ack
[00:14] <wallyworld> thumper: ostensibly our logic should not have changed between .2 and 2.3 so hopefully it's just a simple bug or something
[00:14] <thumper> wallyworld: I'm not convinced that it isn't in 2.2
[00:15] <thumper> it fits the behaviour we see with status taking longer over time
[00:15] <wallyworld> could be, i was just going by what's been commented on te bug
[00:15] <thumper> yeah
[00:15] <thumper> I've read it too
[00:15] <thumper> more poking needed
[00:15] <wallyworld> yup
[02:53] <thumper> wallyworld: I'm going to also start looking at the pinger bug
[02:53] <wallyworld> thumper: righto, i'm just about to start as well, finished other things
[03:13] <thumper> wallyworld: let me know if you want to talk things through
[03:13] <thumper> I'm making some progress, but it is slow, and experimental based
[03:13] <wallyworld> thumper: just poking around atm to grok the code - about to add some debugging etc
[03:13] <thumper> wallyworld: same
[03:14] <thumper> I have found that we can trigger it with no charms
[03:14] <thumper> just enable-ha
[03:14] <wallyworld> i thought i'd try and undertand it before adding debugging but it's messy so i think debugging it is
[03:14] <thumper> so... weird
[03:21] <wallyworld> thumper: one initial thought OTTOMH, could be wrong. regardless of the controller vs agent connection, it seems we start a pinger each time an agent logs in, regardless of whether we have previously done so; it seems when we do, we never stop any previously created ones
[03:21] <wallyworld> so if an agent bounces say, we just keep on creating new pingers
[03:21] <thumper> possibly
[03:22] <wallyworld> just a thought, i'll try and prove it etc
[03:22] <thumper> although I'm seeing pingers being created without connections bouncing
[03:22] <thumper> although now you mention it, I should make sure they aren't bouncing
[03:22] <wallyworld> right, that would be for any login
[03:22] <wallyworld> i think any connection may create a ne wpinger
[03:34] <thumper> wallyworld: HO?
[03:34] <thumper> I have some ideas I want to talk through
[03:34] <wallyworld> ok
[03:34] <thumper> 1:1
[05:44] <wallyworld> axw: small PR for when you get a moment https://github.com/juju/juju/pull/8054
[05:46] <axw> wallyworld: LGTM
[05:47] <wallyworld> ty
[06:11] <jam> axw: looks like your Log at TRACE got hung up on a test that was testing that we created a DEBUG message for Wrench
[06:11] <jam> http://ci.jujucharms.com/job/github-merge-juju/494/console
[06:24] <axw> jam: yeah, that's just the forward port to develop - will come back to it when I've got a spare minute
[06:24] <axw> 1.25 has landed
[06:24] <axw> 1.25 change*
[06:25] <jam> right
[06:54] <thumper> jam: I remembered why we had two api connections for the apiservers
[06:54] <thumper> hmm...
[06:54] <thumper> nope that doesn't work
[06:54] <thumper> nm
[07:04] <thumper> wallyworld: https://github.com/juju/juju/pull/8055
[07:05] <wallyworld> looking
[07:07] <wallyworld> thumper: lgtm, one bug down  or 3 to go
[07:07] <wallyworld> *2
[07:24] <thumper> ah fark
[07:24] <thumper> we do register the pinger as a worker on the resources
[07:24] <thumper> just on the wrong thing
[07:24]  * thumper digs
[07:24] <thumper> at least I *think* it is
[07:26] <thumper> maybe not...
[09:10] <axw> wallyworld: for tomorrow, if you can: https://github.com/juju/juju/pull/8056. back to enable-ha (it's *possible* merging this manifold rejigging into develop will help, but I'll avoid that if possible)
[09:13] <kjackal> axw: wallyworld: Truely sorry for today. Never saw I had to start earlier today. The weekly calendar view does not help much. Appologies
[09:14] <axw> kjackal: no dramas, can you make it tomorrow?
[09:14] <kjackal> Yes, I will be there axw
[09:14] <axw> cool
[09:24] <wallyworld> axw: no worries, i'll take a look
[09:49] <wallyworld> axw: reviewed
[09:49] <axw> wallyworld: thanks
[09:51] <axw> wallyworld: when are we planning to go to rc1?
[10:00] <wallyworld> axw: end of this week
[10:00] <wallyworld> if bugs are fixed
[10:00] <axw> okey dokey
[10:00] <axw> ta
[16:02] <rogpeppe1> wpk: FYI i just noticed this PR in passing and made a comment: https://github.com/juju/names/pull/86
[16:08] <wpk> rogpeppe1: 1. it doesn't have to be 'crypto' safe, and if you're not trying to deliberately get a collision 4 bytes from SHA256 are as good as 4 bytes from CRC32
[16:08] <wpk> rogpeppe1: (and it's still quite easy to get a 4 byte collision using sha256)
[16:08] <rogpeppe1> wpk: i'd use 16 bytes not 4
[16:09] <wpk> rogpeppe1: then we loose the name
[16:09] <rogpeppe1> wpk: and i wouldn't rule out the possibility of someone deliberately trying to get a collision
[16:09] <wpk> rogpeppe1: if an user wants to shoot himself in the foot it's his choice and his right
[16:10] <rogpeppe1> wpk: why so? 16 bytes of hash still leaves 32 bytes for the name
[16:10] <rogpeppe1> wpk: i mean, why would we lose the name?
[16:10] <wpk> rogpeppe1: and 2. we reserve 4 chars for unit id, so 'longlonglongname/0'.ShortenedString() has the same 'name' as 'longlonglongname/1000'
[16:11] <rogpeppe1> wpk: ah, so that's the source of the extra truncation?
[16:12] <wpk> rogpeppe1: 17 bytes for the name (juju-unit-{name}{32charsofhash}-{4charsforid})
[16:12] <wpk> rogpeppe1: yes
[16:13] <rogpeppe1> wpk: ok, so 17 bytes for the name is still a reasonable amount
[16:14] <wpk> rogpeppe1: I still can't imagine a situation in which user would deliberately try to shoot himself in the foot (and only himself, that's important)
[16:14] <rogpeppe1> wpk: the problem might come if unit names might be created based on user-provided data
[16:15] <rogpeppe1> wpk: which isn't impossible
[16:17] <wpk> in shared model?
[16:18] <rogpeppe1> wpk: or a model-as-a-service in some way
[16:20] <wpk> it'd have to be single machine in a single model shared between users, do we support that?
[16:26] <rogpeppe1> wpk: well, the model doesn't have to be directly accessible - just that the names that some user chooses are used for an application name somehow
[16:27] <rogpeppe1> wpk: i know of at least one client where juju is used as an intermediate layer between a high level abstraction and the actual job
[16:28] <rogpeppe1> wpk: BTW i just tried with four digits of id, and it "shortens" a 19 byte unit tag to 26 bytes.
[16:29] <rogpeppe1> wpk: i think we can probably avoid shortening when the name doesn't actual reach the limit
[16:30] <rogpeppe1> wpk: also, i think it might be worth separating the name part from the hash part, otherwise it's not easy to tell which bit is which
[16:30] <rogpeppe1> wpk: (i'd probably use a separator char that's not part of a valid unit tag, so there's less danger of mixing them up)
[17:57] <hml> is ci for pr-merge okay?  i’m getting a message that it’s scheduled to run later? when i click on the link, nothing has run for 3 hours?
[19:11] <mup> Bug #1732004 opened: arm64 shows 1 vs. 96 cores via Juju GUI version 2.10.2 <juju-core:New> <https://launchpad.net/bugs/1732004>
[22:14] <thumper> anastasiamac, babbageclunk: I have a couple of PRs up that are in dire need of a review.
[22:15] <babbageclunk> thumper: I guess jam should take another look at #8057 - I'll look at #8058
[22:17] <babbageclunk> thumper: was there another one?
[22:27] <babbageclunk> thumper: #8058 approved.
[22:45] <thumper> ta
[22:47] <wallyworld> babbageclunk: long time no see
[22:47] <babbageclunk> wallyworld: hey
[22:48] <babbageclunk> wallyworld: wanna have a quick chat?
[22:48] <wallyworld> suppose so
[22:48] <wallyworld> if i must
[22:48] <wallyworld> :-P
[22:48]  * babbageclunk looks sad
[22:48] <babbageclunk> in 1:1?
[22:48] <wallyworld> sure
[23:07] <blahdeblah> It must be great to have such a supportive and friendly manager.
[23:08] <thumper> blahdeblah: true