Proposal to elect new release rc--2024-05-22_23-01

Governance
,
4

Hi Dfinity,

I noted that this proposal retires 12 IC-OS versions all in one go. I got curious about the details and scripted some analysis, which raised a couple questions for me. If you’re able to answer either of these when you get a chance that would be much appreciated.

  • Does Dfinity have a well defined policy for when it is and isn’t appropriate to retire a specific IC-OS version? i.e. a means of minimising risks, for example maintaining a sufficient number of versions that can be rolled back to in the event of a latent IC-OS bug.
  • Can I ask why Dfinity moved away from the ‘RetireReplicaVersion’/‘BlessReplicaVersion’ NNS functions in late 2023 (in favour of using a single ‘ReviseElectedGuestosVersions’ function)? I see the motion where RetireReplicaVersion was proposed, but not where it was replaced (presumably because it’s still available, just not being used). If a member of the community wants to object to the unelection of some IC-OS versions (due to rollback risk tolerance), but they have no issue with the election aspect of the proposal, it seems they have no option but the reject the whole proposal (which previously wasn’t an issue when the relevant NNS function actioned by the proposal was decoupled allowing separate proposals).

The current proposal seems like a potentially good example for the points above.

Based on IC-OS election proposal history, there currently appear to be 17 blessed replica versions stored in the registry canister (so that they can be readily deployed), 12 of which would be removed by this proposal. I’ve listed these below, ordered by elected date, and crossed out the versions that would be unelected/removed.

  • 19dbb5c, elected 2024-04-15 (proposal 129081), UNELECTION PROPOSED, running on 0 subnets
  • 02dcaf3, elected 2024-04-15 (proposal 129084), UNELECTION PROPOSED, running on 0 subnets
  • abcea3e, elected 2024-04-22 (proposal 129378), UNELECTION PROPOSED, running on 0 subnets
  • 0a51fd7, elected 2024-04-22 (proposal 129379), UNELECTION PROPOSED, running on 0 subnets
  • 33dd2ef, elected 2024-04-22 (proposal 129408), UNELECTION PROPOSED, running on 0 subnets
  • 4e9b02f, elected 2024-04-23 (proposal 129423), UNELECTION PROPOSED, running on 0 subnets
  • 687de34, elected 2024-04-24 (proposal 129427), UNELECTION PROPOSED, running on 0 subnets
  • 63acf4f, elected 2024-04-24 (proposal 129428), UNELECTION PROPOSED, running on 0 subnets
  • 80e0363, elected 2024-04-29 (proposal 129493), UNELECTION PROPOSED, running on 0 subnets
  • 5e285dc, elected 2024-04-29 (proposal 129494), UNELECTION PROPOSED, running on 0 subnets
  • bb76748, elected 2024-05-06 (proposal 129627), UNELECTION PROPOSED, running on 0 subnets
  • f58424c, elected 2024-05-06 (proposal 129628), UNELECTION PROPOSED, running on 0 subnets
  • 2c4566b, elected 2024-05-13 (proposal 129696), running on 1 subnets
  • 9866a6f, elected 2024-05-13 (proposal 129697), running on 0 subnets
  • 30bf45e, elected 2024-05-16 (proposal 129706), running on 0 subnets
  • 5ba1412, elected 2024-05-20 (proposal 129746), running on 3 subnets
  • b6b2ef4, elected 2024-05-20 (proposal 129747), running on 33 subnets

Relevant Subnet Version History

I’ve focused on the subnet IC-OS version history of a few of the most important subnets below. The current version is in bold, on the left of which are prior deployed versions (crossed out if due to be unelected), and on the right of which are versions that have not yet been deployed to that subnet and are not due to be unelected.

  • tdb26 (system), has been running 2c4566b since 2024-05-21 (4 days):
    • 19dbb5c,33dd2ef,687de34,80e0363,bb76748,2c4566b,9866a6f,30bf45e,5ba1412,b6b2ef4
  • uzr34 (system), has been running 5ba1412 since 2024-05-22 (3 days):
    • 19dbb5c,33dd2ef,687de34,80e0363,bb76748,2c4566b,bb76748,30bf45e,5ba1412,9866a6f,b6b2ef4
  • w4rem (system), has been running b6b2ef4 since 2024-05-23 (2 days):
    • 19dbb5c,33dd2ef,687de34,80e0363,bb76748,9866a6f,b6b2ef4,2c4566b,30bf45e,5ba1412
  • x33ed (application), has been running 5ba1412 since 2024-05-23 (2 days):
    • 19dbb5c,33dd2ef,687de34,80e0363,bb76748,2c4566b,5ba1412,9866a6f,30bf45e,b6b2ef4
  • pzp6e (fiduciary), has been running 5ba1412 since 2024-05-23 (2 days):
    • 19dbb5c,33dd2ef,687de34,80e0363,bb76748,30bf45e,5ba1412,2c4566b,9866a6f,b6b2ef4

In case there’s an unexpected need to rollback to the prior deployed version, it seems sensible to always leave at least one prior deployed version for each subnet remaining in the registry (otherwise the only option would be to roll foward, or await a new IC-OS release if necessary, which seems suboptimal or possibly dangerous due to needing to wait).

All but 1 of the subnets above will still be able to rollback to a prior version after this proposal is executed, but as far as I can tell tdb26 won’t be able to, it would only be able to roll forward to a version that has not yet been deployed to that subnet (or await a patch election). It’s been running that version for 4 days now, so I’m obviously talking about something that’s unlikely. But I’m still interested in whether there’s some sort of risk aversion policy being adhered to when it comes to unelecting specific IC-OS versions, and what a community member should be looking out for when asserting that such a policy is being adhered to.

Any context you’re able to provide would very helpful. Thanks in advance!

2 Likes