[00:13] wallyworld: are you looking at the pinger issue? [00:13] 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] ack [00:14] 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] wallyworld: I'm not convinced that it isn't in 2.2 [00:15] it fits the behaviour we see with status taking longer over time [00:15] could be, i was just going by what's been commented on te bug [00:15] yeah [00:15] I've read it too [00:15] more poking needed [00:15] yup [02:53] wallyworld: I'm going to also start looking at the pinger bug [02:53] thumper: righto, i'm just about to start as well, finished other things [03:13] wallyworld: let me know if you want to talk things through [03:13] I'm making some progress, but it is slow, and experimental based [03:13] thumper: just poking around atm to grok the code - about to add some debugging etc [03:13] wallyworld: same [03:14] I have found that we can trigger it with no charms [03:14] just enable-ha [03:14] i thought i'd try and undertand it before adding debugging but it's messy so i think debugging it is [03:14] so... weird [03:21] 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] so if an agent bounces say, we just keep on creating new pingers [03:21] possibly [03:22] just a thought, i'll try and prove it etc [03:22] although I'm seeing pingers being created without connections bouncing [03:22] although now you mention it, I should make sure they aren't bouncing [03:22] right, that would be for any login [03:22] i think any connection may create a ne wpinger [03:34] wallyworld: HO? [03:34] I have some ideas I want to talk through [03:34] ok [03:34] 1:1 [05:44] axw: small PR for when you get a moment https://github.com/juju/juju/pull/8054 [05:46] wallyworld: LGTM [05:47] ty [06:11] 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] http://ci.jujucharms.com/job/github-merge-juju/494/console [06:24] jam: yeah, that's just the forward port to develop - will come back to it when I've got a spare minute [06:24] 1.25 has landed [06:24] 1.25 change* [06:25] right [06:54] jam: I remembered why we had two api connections for the apiservers [06:54] hmm... [06:54] nope that doesn't work [06:54] nm [07:04] wallyworld: https://github.com/juju/juju/pull/8055 [07:05] looking [07:07] thumper: lgtm, one bug down or 3 to go [07:07] *2 [07:24] ah fark [07:24] we do register the pinger as a worker on the resources [07:24] just on the wrong thing [07:24] * thumper digs [07:24] at least I *think* it is [07:26] maybe not... === frankban|afk is now known as frankban [09:10] 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] 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] kjackal: no dramas, can you make it tomorrow? [09:14] Yes, I will be there axw [09:14] cool [09:24] axw: no worries, i'll take a look [09:49] axw: reviewed [09:49] wallyworld: thanks [09:51] wallyworld: when are we planning to go to rc1? [10:00] axw: end of this week [10:00] if bugs are fixed [10:00] okey dokey [10:00] ta [16:02] wpk: FYI i just noticed this PR in passing and made a comment: https://github.com/juju/names/pull/86 [16:08] 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] rogpeppe1: (and it's still quite easy to get a 4 byte collision using sha256) [16:08] wpk: i'd use 16 bytes not 4 [16:09] rogpeppe1: then we loose the name [16:09] wpk: and i wouldn't rule out the possibility of someone deliberately trying to get a collision [16:09] rogpeppe1: if an user wants to shoot himself in the foot it's his choice and his right [16:10] wpk: why so? 16 bytes of hash still leaves 32 bytes for the name [16:10] wpk: i mean, why would we lose the name? [16:10] rogpeppe1: and 2. we reserve 4 chars for unit id, so 'longlonglongname/0'.ShortenedString() has the same 'name' as 'longlonglongname/1000' [16:11] wpk: ah, so that's the source of the extra truncation? [16:12] rogpeppe1: 17 bytes for the name (juju-unit-{name}{32charsofhash}-{4charsforid}) [16:12] rogpeppe1: yes [16:13] wpk: ok, so 17 bytes for the name is still a reasonable amount [16:14] 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] wpk: the problem might come if unit names might be created based on user-provided data [16:15] wpk: which isn't impossible [16:17] in shared model? [16:18] wpk: or a model-as-a-service in some way [16:20] it'd have to be single machine in a single model shared between users, do we support that? [16:26] 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] 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] wpk: BTW i just tried with four digits of id, and it "shortens" a 19 byte unit tag to 26 bytes. [16:29] wpk: i think we can probably avoid shortening when the name doesn't actual reach the limit [16:30] 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] 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) === frankban is now known as frankban|afk [17:57] 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] Bug #1732004 opened: arm64 shows 1 vs. 96 cores via Juju GUI version 2.10.2 === TikTok is now known as michealb === rick_h_ is now known as rick_h === icey_ is now known as icey === arosales_ is now known as arosales === wpk_ is now known as wpk [22:14] anastasiamac, babbageclunk: I have a couple of PRs up that are in dire need of a review. [22:15] thumper: I guess jam should take another look at #8057 - I'll look at #8058 [22:17] thumper: was there another one? [22:27] thumper: #8058 approved. [22:45] ta [22:47] babbageclunk: long time no see [22:47] wallyworld: hey [22:48] wallyworld: wanna have a quick chat? [22:48] suppose so [22:48] if i must [22:48] :-P [22:48] * babbageclunk looks sad [22:48] in 1:1? [22:48] sure [23:07] It must be great to have such a supportive and friendly manager. [23:08] blahdeblah: true