Update the SNS Root's canister_status API

Developers
1

Currently, the SNS root has a canister_status API with the following interface

canister_status: (record {canister_id:principal}) → (record {
  status:variant {stopped; stopping; running};
  memory_size:nat;
  cycles:nat;
  settings:record {
    controllers:vec principal
  };
  module_hash:opt vec nat8
})

This lacks data when compared to the management canister’s canister_status API

canister_status : (record {canister_id:principal}) -> (record {
    status : variant { running; stopping; stopped };
    settings : record {
      controllers : vec principal;
      compute_allocation : nat;
      memory_allocation : nat;
      freezing_threshold : nat;
      reserved_cycles_limit : nat;
    };
    module_hash : opt blob;
    memory_size : nat;
    cycles : nat;
    reserved_cycles : nat;
    idle_cycles_burned_per_day : nat;
});

If there isn’t a specific reason for these interfaces to be so different, I’d imagine that the data is all there and just needs to be exposed by the SNS Root canister, so hopefully this would be an easy code change & improvement.

Essentially this CanisterStatusResult type just needs to be updated to what is currently coming back from the management canister.

1 Like
2

@DanielThurau @lara

Bumping this for visibility’s sake.

3

Let me ping folks as wel

1 Like
4

Hi @icme , thanks for tagging, this was helpful to make sure we see it!

While I am collecting pros and cons of adding this, could you maybe explain why you would like to have the additional information there? Is there some use case that you cannot meet without this information or were you just generally wondering why it is not the same?

Thanks and have a good start into the new week!

1 Like
5

Sure!

Pros:

  • Makes additional metric information about SNS canisters available to SNS developers, or those who wish to help monitor SNS canisters (achieves parity with non-SNS canisters). Many SNS canisters have frozen in the past, so I’m building a solution that will help monitor SNS canisters and provide additional visibility for their DAOs.
  • Being able to see the memory_allocation metric could have helped to prevent this issue
  • Freezing threshold & idle cycles burn are important stats in order to determine at what amount of cycles the canister will freeze
  • Cycle balance is already public via the current API, so there is no additional attack vector that isn’t already (potentially) exposed by the current API.
  • Having more canister data metrics is generally good?

Cons:

  • Development time is required (albeit very little dev time)
  • You probably want to keep this up to date as the canister_status API evolves (i.e. adding query metrics)
2 Likes
6

Thanks a lot for the extensive lists!
We discussed this internally and agree that it would make sense to include the same fields in root as are available on the management canister.
We will consider the individual fields when we pick up the work, but currently don’t see a reason for any of them not to be copied over.

Thanks for the suggestion!

1 Like
7

Status update: Commit 9d5e046 adds the following fields to the canister_status response of SNS root (and NNS root):

  • reserved_cycles
  • idle_cycles_burned_per_day
  • within settings:
    • compute_allocation
    • memory_allocation
    • freezing_threshold
    • reserved_cycles_limit

IIUC, this fulfills the request being made here. Please, lmk if something is missing.

Next step(s): Most likely, we will make a proposal this Friday to publish a new SNS root WASM with those code changes.

(Of course, SNSs will then have to upgrade to that version in order to run the new behavior.)

2 Likes
8

@lara @daniel-wong

The canister_status API now provides a few additional fields, specifically the interface spec on the management canister has been updated to include:

log_visiblity and query_stats.

These query stats are useful in understanding how much query traffic a canister is receiving.