Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(pocket-ic): support custom blockmaker metrics at each round #3685

Open
wants to merge 28 commits into
base: master
Choose a base branch
from

Conversation

pietrodimarco-dfinity
Copy link
Contributor

@pietrodimarco-dfinity pietrodimarco-dfinity commented Jan 30, 2025

Currently PocketIC at each tick() executes a round with state_machine_tests. However a dummy blockmaker is used.

The metrics_collector_canister I am building store and serve node metrics from all the subnet. To test this canister I need then to modify PocketIC so that at each "round" it stores blockmaker metrics that I can pass in from tests

@pietrodimarco-dfinity pietrodimarco-dfinity requested review from a team as code owners January 30, 2025 11:12
rs/state_machine_tests/src/lib.rs Outdated Show resolved Hide resolved
rs/state_machine_tests/src/lib.rs Outdated Show resolved Hide resolved
rs/state_machine_tests/src/lib.rs Outdated Show resolved Hide resolved
@pietrodimarco-dfinity pietrodimarco-dfinity marked this pull request as draft January 30, 2025 11:30
@pietrodimarco-dfinity pietrodimarco-dfinity changed the title Adapt pocketIC to customize blockmaker at each round feat(pocket-ic): support custom blockmakers at each round Jan 30, 2025
@dsarlis
Copy link
Member

dsarlis commented Jan 30, 2025

support custom blockmakers at each round

What does this even mean? PocketIC does not include IC's consensus, so I'm likely missing some context here.

@pietrodimarco-dfinity
Copy link
Contributor Author

support custom blockmakers at each round

What does this even mean? PocketIC does not include IC's consensus, so I'm likely missing some context here.

Currently PocketIC at each tick() executes a round with state_machine_tests. However a dummy blockmaker is used.

The metrics_collector_canister I am building store and serve node metrics from all the subnet. To test this canister I need then to modify PocketIC so that at each "round" it stores blockmaker metrics that I can pass in from the test

@pietrodimarco-dfinity pietrodimarco-dfinity changed the title feat(pocket-ic): support custom blockmakers at each round feat(pocket-ic): support custom blockmaker at each round Jan 30, 2025
@mraszyk
Copy link
Contributor

mraszyk commented Jan 30, 2025

What does this even mean? PocketIC does not include IC's consensus, so I'm likely missing some context here.

PocketIC doesn't include production consensus, but its blocks must still include stats stored in the replicated state and served by the management canister via the node metrics history endpoint. These stats are currently mocked and this PR allows to override the mocked value for testing the node metrics history endpoint.

@dsarlis
Copy link
Member

dsarlis commented Jan 31, 2025

Thanks for the answers, so I think a small edit of the title to "support custom blockmaker stats at each round" would immediately make it more clear.

@pietrodimarco-dfinity pietrodimarco-dfinity changed the title feat(pocket-ic): support custom blockmaker at each round feat(pocket-ic): support custom blockmaker metrics at each round Jan 31, 2025
@@ -1335,7 +1335,7 @@ impl StateMachine {
/// and execute a round with this payload.
/// Note that only ingress messages submitted via `Self::submit_ingress`
/// will be considered during payload building.
pub fn execute_round(&self) {
pub fn execute_round(&self, blockmaker_metrics: Option<BlockmakerMetrics>) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please rename this function to fn execute_round_impl and introduce a pair of public functions:

pub fn execute_round(&self) // calls execute_round_impl(None)
pub fn execute_round_with_blockmaker_metrics(&self, blockmaker_metrics: BlockmakerMetrics)

this way, there's no breaking change to the existing function

// management canister calls

#[update]
async fn node_metrics_history_proxy(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please move this to the existing test canister under //packages/pocket-ic and use that test canister instead of creating a new one?

@@ -1101,9 +1101,10 @@ pub async fn handler_tick(
State(AppState { api_state, .. }): State<AppState>,
Path(instance_id): Path<InstanceId>,
headers: HeaderMap,
axum::extract::Json(raw): axum::extract::Json<TickConfigs>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
axum::extract::Json(raw): axum::extract::Json<TickConfigs>,
axum::extract::Json(ticks_configs): axum::extract::Json<TickConfigs>,

@@ -1,4 +1,5 @@
#![allow(clippy::test_attr_in_doctest)]
use crate::common::rest::TickConfigs;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's please move this closed to the remaining rest types

Comment on lines 293 to +294
let endpoint = "update/tick";
self.post::<(), _>(endpoint, "").await;
self.post::<(), _>(endpoint, TickConfigs::default()).await;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self.tick_with_configs(TickConfigs::default()).await;

}

#[test]
fn test_custom_blockmaker() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's move this test to //packages/pocket-ic and extend the test canister there; please use candid::Principal instead of ic_types::PrincipalId and mgmt canister types from pocket_ic::management_canister_types

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants