You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(ic-admin): [CON-1637] halt a subnet without necessarily provisioning SSH keys (#9780)
This PR changes the arguments `ssh_readonly_access` and
`ssh_node_state_write_access` in `ic-admin`'s
`ProposeToTakeSubnetOfflineForRepairsCmd` command to be optional. This
allows to halt the subnet without provisioning SSH keys as
[suggested](#7361 (comment))
in the PR introducing the command. This allows to replace all halting
commands in`ic-recovery` with this one. This PR also addresses Leo's
other comments in the linked PR.
Behavioural changes/remarks:
- It was not and still is not possible to halt the subnet while
provisioning an empty list of SSH keys, i.e. clearing the current list.
You can either overwrite the list with a non-empty list or (thanks to
this PR) do no change. I cannot think of any realistic use-case for
overwriting with an empty list so this should be fine (note that this is
a limitation from `ic-admin`, this is still possible through a direct
call to the governance canister's `SetSubnetOpereationalLevel`).
- Unhalting will now always clear the list of SSH keys. In particular:
- App subnet recoveries' `Unhalt` step will clear the list instead of
overwriting it with a singleton empty string (this is actually an
interesting artifact that you can deduce that a subnet was previously
recovered by checking whether its `SubnetRecord::ssh_readonly_access`
field is `[""]` instead of `[]`).
- When unhalting the source subnet in subnet splitting, the list will be
cleared instead of doing no change (see change in `subnet_splitting.rs`.
This is actually probably the intended effect, which ensures that the
SSH readonly key that was deployed to the subnet is cleared.
- As a (maybe unintended) side-effect, this will also clear the list in
the destination subnet, which could have been non-empty when creating
the subnet, but again I doubt this corresponds to any realistic
scenario.
---------
Co-authored-by: IDX GitHub Automation <infra+github-automation@dfinity.org>
0 commit comments