Proposal to elect new release rc--2024-10-11_14-35

Governance NNS proposal discussions
,
5

Thanks for these releases DFINITY

TLDR: I’m voting to adopt both proposals

133396

Build successful and hashes generated on my machine match (CDN and local build), and the GuestOS hash matches the proposal payload.

img
img1506×914 47.8 KB

:partying_face: :tada: no non-deterministic builds

There are 107 commits since the previous release, 39 of which are referenced in this proposal. There are 24 files that have been modified both by commits referenced in this proposal as well as commits that weren’t. I would have expected to see de4876fe2 in the proposal summary change log (as a HostOS change) given the talk from a few weeks ago.

I initially thought another commit may be missing until I released it was organised under a reversion (nice! thanks for sorting this @Luka) :point_down:

Regarding the divergence and cherry pick (so no divergence after all) - I don’t see why merging wasn’t preferred over cherry picking here. I think that would have been a lot clearer (particularly given that the git graph would then illustrate exactly what’s happening). I’ve mentioned this sort of thing in more detail in previous releases (e.g. rc–2024-07-25_21-03, rc–2024-08-29_01-30).

All commits appear to match their commit messages well and seem reasonable - including callback expiration, storage reservation for verified application subnets, addressing a regression in the XNET, introduction of profiling tools, new metrics, dependency updates, refactoring, and some reversions.

I’ve also reviewed the unelection component of this proposal below.

There currently appear to be 9 blessed replica versions registered, 6 of which would be unelected by this proposal. These unelected versions are not running on any subnets, nor any unassigned nodes, so appears safe to unelect. Expand for details.
  • 0441f40, elected 2024-09-23 (proposal 133061), UNELECTION PROPOSED, running on 0 subnets
  • 7f6a81f, elected 2024-09-23 (proposal 133062), UNELECTION PROPOSED, running on 0 subnets
  • c87abf7, elected 2024-09-23 (proposal 133063), UNELECTION PROPOSED, running on 0 subnets
  • 35153c7, elected 2024-09-30 (proposal 133142), UNELECTION PROPOSED, running on 0 subnets
  • d101161, elected 2024-09-30 (proposal 133143), UNELECTION PROPOSED, running on 0 subnets
  • c43a488, elected 2024-09-30 (proposal 133144), UNELECTION PROPOSED, running on 0 subnets
  • d265777, elected 2024-10-08 (proposal 133309), running on 0 subnets
  • 1ff0e70, elected 2024-10-08 (proposal 133310), running on 0 subnets
  • f0c923e, elected 2024-10-09 (proposal 133327), running on 37 subnets and all unassigned nodes (since proposal 133372)

133397

Build successful and GuestOS + HostOS hashes generated on my machine match (CDN and local build), and the GuestOS hash matches the proposal payload. SetupOS is still having reproducibility issues, but it's not the target of the propopsal

img
img1531×916 50 KB

:point_up: This is not strictly the case. The release is actually based on changes since 5b82b0e2. 6fb2fd1 is instead cherry picked. The end result is the same though (this release branch has additional changes not present in the other one).

All commits appear to match their commit messages well and seem reasonable. I’m glad to see monitoring enhancements along with these changes. I’m assuming the impact of increasing the sandbox count and the task spawning changes will be closely monitored.

I hope these changes play well in production.

2 Likes