> On Mar 22, 2021, at 13:28, Andrew Gallagher <andr...@andrewg.com> wrote: > > I happened to check the pool just now, and there are only three nodes in it: > > 1 pgpkeys.uk[@] > 2 sks.pod01.fleetstreetops.com[@] > 3 sks.pod02.fleetstreetops.com[@] > > Looking at the cached metadata it appears that when the spider ran, > pod02.fleetstreetops nodes was unavailable, as was pgpkeys.co.uk (the domain > registration has expired).
I can’t speak for pgpkeys.co.uk <http://pgpkeys.co.uk/>, but I have not seen any issues with sks.pod02.fleetstreetops.com <http://sks.pod02.fleetstreetops.com/> (nor hkps.pool.sks-keyservers.net <http://hkps.pool.sks-keyservers.net/>, which it powers) today. > pod01.fleetstreetops does not advertise any peers, This happens intermittently when the non-recon node services the status request, but it is a multi-node pool so rest assured there is external reconciliation configured. > This demonstrates that connectivity is a serious issue with the pool right > now. A few key nodes going down can orphan all other nodes, no matter how > well-behaved. While the core idea behind this take is valid, I do not believe the current state of affairs is as dire as it is being portrayed. > It should probably also be noted that pod02.fleetstreetops has been the only > node in the HKPS pool now for some time. This certainly can't be good for its > load. Yes, this has been the case since last summer. This is completely reliant on Kristian’s continued signing of CSRs for member nodes. -T
signature.asc
Description: Message signed with OpenPGP
