feat(registry): add invariant that cloud engines only contain type4 nodes#9621
feat(registry): add invariant that cloud engines only contain type4 nodes#9621pierugo-dfinity merged 19 commits intomasterfrom
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):
-
Update
unreleased_changelog.md(if there are behavior changes, even if they are
non-breaking). -
Are there BREAKING changes?
-
Is a data migration needed?
-
Security review?
How to Satisfy This Automatic Review
-
Go to the bottom of the pull request page.
-
Look for where it says this bot is requesting changes.
-
Click the three dots to the right.
-
Select "Dismiss review".
-
In the text entry box, respond to each of the numbered items in the previous
section, declare one of the following:
-
Done.
-
$REASON_WHY_NO_NEED. E.g. for
unreleased_changelog.md, "No
canister behavior changes.", or for item 2, "Existing APIs
behave as before.".
Brief Guide to "Externally Visible" Changes
"Externally visible behavior change" is very often due to some NEW canister API.
Changes to EXISTING APIs are more likely to be "breaking".
If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.
If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.
Reference(s)
For a more comprehensive checklist, see here.
GOVERNANCE_CHECKLIST_REMINDER_DEDUP
pierugo-dfinity
dismissed
github-actions[bot]’s stale review
- Done
- No breaking changes
- No data migration is needed: Looking at the mainnet’s registry, there are no subnet of type
CloudEngineand no nodes of reward typeType4. - No need of a security review
There is a registry [invariant](https://sourcegraph.com/r/github.com/dfinity/ic@be84ed74ce86fbc7db95edaeba782f4106313dc5/-/blob/rs/registry/canister/src/invariants/subnet.rs#L118-L129) that enforces that cloud engines must have a free cycles cost schedule. A separate [PR](#9621) will add a second invariant enforcing that cloud engines must contain only `type4` node reward types, as this is already how nodes deny incoming connections from cloud engine nodes in the [firewall](#9315). This PR ensures those two invariants are satisfied when creating cloud engines in system tests by default (though can still be broken if needed by calling `with_cost_schedule`/`with_node_reward_type`). Moreover, note that this means that it becomes a requirement for any system test running a cloud engine to also have an API BN. As of `HEAD`, cloud engines already use API BNs to [replicate the registry](#9222) (because NNS nodes' firewall blocks them). Existing system tests using cloud engines work because the nodes' reward types are not set in the registry, thus default to contacting NNS nodes. Soon ([draft PR](#9595)), fetching delegations will also go through API BNs. This PR thus also adds an API BN to existing tests that use cloud engines.
daniel-wong-dfinity-org
left a comment
daniel-wong-dfinity-org
left a comment
There was a problem hiding this comment.
I am preemptively approving. This means that no re-review is REQUIRED, but as always, re-review requests are 100% welcome.
2 participants
This PR adds two invariants to the registry concerning cloud engines: