o/assertstate: Commit fetches asserts and checks enforcement - #17377
o/assertstate: Commit fetches asserts and checks enforcement#17377miguelpires wants to merge 3 commits into
Conversation
miguelpires
added
the
confdb
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #17377 +/- ##
==========================================
- Coverage 78.85% 78.85% -0.01%
==========================================
Files 1404 1409 +5
Lines 196234 197296 +1062
Branches 2466 2561 +95
==========================================
+ Hits 154748 155585 +837
- Misses 32191 32365 +174
- Partials 9295 9346 +51
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Thu Jul 23 18:47:25 UTC 2026 Spread tests skipped |
miguelpires
changed the title
028f78f to
ebfb6d6
Compare
| type valsetChange struct { | ||
| // kind can be "monitor", "enforce" or "forget" | ||
| kind string | ||
| id valsetRef |
There was a problem hiding this comment.
both the name and the type of this are a bit confusing. A close thing we have is asserts.AtSequence, maybe there's a name more like that we can use?
There was a problem hiding this comment.
Do you mean the valsetChange, the valsetRef or both?
There was a problem hiding this comment.
sorry I meant the name "id" and the type name "valsetRef"
There was a problem hiding this comment.
I renamed it to atSequence and documented the fields better. Sorry, I had to force push to remove another commit I added to this branch by mistake
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Use (TryEnforced|Monitor)ValidationSets to fetch validation sets and perform checks (enforcement or against model) before changing state. Since changes made through confdb can affect many validation sets, it's important to note that changes are not atomic. We'll first check if all the enforce changes can be applied and abort, if not. These is the most frequent failure scenario so it's the first one to be checked. From then on, if a monitor or forget change fails, the previous changes are still persisted. This could be due to model checks failing or a failure to fetch a validation set. We can make these changes atomic, but it would require quite a bit of special-purpose code, so I didn't think it was was worth it, since the original API doesn't support it anyway. Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
6575e0a to
93df1a9
Compare
pedronis
left a comment
pedronis
left a comment
There was a problem hiding this comment.
thx, small further naming remark
| // kind denotes the type of change which can be "monitor", "enforce" or "forget". | ||
| kind string | ||
| // valsetID identifies the validation-set, possibly pinning to a sequence. | ||
| valsetID atSequence |
There was a problem hiding this comment.
valsetPt perhaps, as in Pt meaning point aka sequence point
github-actions
Bot
added
the
Auto rerun spread
3 participants
Use (TryEnforced|Monitor)ValidationSets to fetch validation sets and perform checks (enforcement or against model) before changing state. Since changes made through confdb can affect many validation sets, it's important to note that changes are not atomic. We'll first check if all the enforce changes can be applied and abort, if not. This is the most frequent failure scenario so it's the first one to be checked. From then on, if a monitor or forget change fails, the previous changes are still persisted. This could be due to model checks failing or a failure to fetch a validation set.
We could make these changes atomic, but it would require quite a bit of special-purpose code, so I didn't think it was was worth it, since the original API doesn't support it anyway.
https://warthogs.atlassian.net/browse/SNAPDENG-37233