Proposal to elect new release rc--2024-05-09_23-02


Are you able to share any further information about the event that occurred that brought the II and XRC canisters down and/or required them to be taken offline?

I gather that the schnorr commit that made MasterPublicKey mandatory was involved in this issue, given that it’s reverted in this latest release as the only change. Are you able provide details about how the issue unfolded?

I also have a couple of side questions if that’s okay:

  • I see that uzr34 is often the first subnet to receive a particular version of the IC-OS releases (the version that has the new storage layer feature disabled - for now). Given that this is a critical system subnet, I suspect there’s a good reason that new IC-OS releases rollout to it as a priority (rather than testing the waters first with some less critical subnets). Presumably this is due to the dependency that other subnets have on the uzr34 subnet? If you’re ablet to clarify, this information would be useful.
  • I noticed that the II canister was upgraded shortly after the incident was resolved (having already deployed a recovery catch-up package). The canister upgrade featured numerous changes. Has that II canister upgrade played a part in getting the uzr34 subnet back on track, or is the timing of that upgrade a coincidence?
  • I’ve noticed that there’s not a second IC-OS hotfix release (one that has the storage layer feature enabled). Presumably that’s because the issue experience by the uzr34 subnet is not applicable to any of the subnets that have had the new storage layer feature enabled. Is that correct? Any elaboration you’re able to provide about why those other subnets are not susceptible would be useful.
  • A more general question about the relationship between the new storage layer feature on/off proposal pairs; Can I ask if anyone knows why the storage layer feature flag has been implemented as a compile-time setting (requiring two different binaries, and therefore two separate IC-OS election proposals for on/off settings), rather than a runtime or install-time flag? My understanding is that the latter approach would require just one binary and fewer IC-OS election proposals (along with some other benefits)