Skip to content

Conversation

sarataha
Copy link
Contributor

@sarataha sarataha commented Sep 4, 2025

This is a follow up PR to #8667 as suggested by @davepacheco in #8667 (comment)

Instead of verifying table coverage for individual blueprint insertions, this change tracks coverage cumulatively across all tests in test_representative_blueprint().

@davepacheco
Copy link
Collaborator

Thanks for taking this one on. I just wanted to give you a heads-up that I probably won't be able to look for a week or two. (If anyone else at Oxide can take a look, go for it!)

@sarataha sarataha marked this pull request as ready for review September 6, 2025 13:19
Copy link
Collaborator

@davepacheco davepacheco left a comment

Choose a reason for hiding this comment

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

This looks pretty good. I have a few small suggestions, but we don't have to make most of these changes.

self.counts.values().all(|&count| count == 0)
}

/// Add counts from another BlueprintTableCounts to this one.
Copy link
Collaborator

Choose a reason for hiding this comment

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

What do you think about having BlueprintTableCounts contain an integer counter of the number of blueprints we think should be here? new() would set it to 1, and add() would add the count from the other.

Then in ensure_blueprint_fully_populated(), for the non-exception tables, their counts should match the count in the struct.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That totally make sense, thank you! Will add it shortly.

Comment on lines -4676 to -4737
"bp_pending_mgs_update_sp",
"bp_pending_mgs_update_rot",
"bp_pending_mgs_update_rot_bootloader",
"bp_pending_mgs_update_host_phase_1",
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess you removed these because now the exceptions are tables that are not in any of the representative blueprints. (My other suggestion was assuming this was the same semantics as before, that some blueprints might not have them.)

Do you know if it'd be hard to create representative blueprints that exercise the three clickhouse tables? I feel like you had that in an earlier version of the earlier PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes I remember the Clickhouse config. You're right now that cumulative tracking is implemented the same pattern can be applied to Clickhouse. I think I can apply the same pattern and it shouldn't be difficult 🙂

@sarataha sarataha force-pushed the blueprint-coverage-test branch from bd8bde9 to 8bb5e6f Compare October 1, 2025 21:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants