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

Patch Envelopes: remove envelopesToUpdate #3806

Merged
merged 1 commit into from
Mar 13, 2024

Conversation

uncleDecart
Copy link
Contributor

Previous patch envelope unit test flakiness revealed that using envelopesToUpdate boolean map creates a a situation, where in some cases patch envelope is not getting updates. This happens occasionally (around 2 out of 200 runs).

In spirit of KIS (Keep It Simple) this patch removes envelopesToUpdate and iterates over every attached patch envelope when updating state. Since number of patch envelopes attached to Edge App is small in real life scenarios, it won't affect performance. Morevover, one could argue that without the need to determine which patch envelope is affected when VolumeInstance is changed of contentTree appears, such approach is more suitable.

Note that queue update queue still won't grow, since update channel is still buffered to one.

Thanks @christoph-zededa for finding the problem!

Copy link

codecov bot commented Mar 12, 2024

Codecov Report

Attention: Patch coverage is 64.70588% with 12 lines in your changes are missing coverage. Please review.

Project coverage is 19.67%. Comparing base (a93b850) to head (88d34b4).
Report is 32 commits behind head on master.

Files Patch % Lines
pkg/pillar/cmd/zedrouter/patchenvelopes.go 64.70% 8 Missing and 4 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3806      +/-   ##
==========================================
- Coverage   19.71%   19.67%   -0.04%     
==========================================
  Files         235      235              
  Lines       51757    51723      -34     
==========================================
- Hits        10204    10178      -26     
+ Misses      40815    40807       -8     
  Partials      738      738              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@christoph-zededa
Copy link
Contributor

christoph-zededa commented Mar 12, 2024

LGTM - Thx for your time.

@eriknordmark
Copy link
Contributor

Did we include PE support in 11.0? If so we should label this stable and backport to 11.0-stable.

@uncleDecart
Copy link
Contributor Author

@eriknordmark , yep. I'll put stable on it and backport

@uncleDecart uncleDecart added the stable Should be backported to stable release(s) label Mar 13, 2024
@uncleDecart
Copy link
Contributor Author

@eriknordmark we include PE partially in 11.0-stable (only inline objects, no volume reference), so backporting this test doesn't make sense. Should I backport all of the patches to 11.0-stable?

Previous patch envelope unit test flakiness revealed that using
`envelopesToUpdate` boolean map creates a a situation, where in some cases
patch envelope is not getting updates. This happens occasionally (around 2 out
of 200 runs).

In spirit of KIS (Keep It Simple) this patch removes `envelopesToUpdate` and
iterates over every attached patch envelope when updating state. Since number
of patch envelopes attached to Edge App is small in real life scenarios, it
won't affect performance. Morevover, one could argue that without the need
to determine which patch envelope is affected when `VolumeInstance` is changed
of `contentTree` appears, such approach is more suitable.

In addition, this patch introduces `RWMutex` in `PatchEnvelopes` struct, because
in `updateEnvelopes` function assigns map to new value, which can cause a race
condition.

Note that queue update queue still won't grow, since update channel is still
buffered to one.

Signed-off-by: Pavel Abramov <uncle.decart@gmail.com>
@eriknordmark
Copy link
Contributor

@eriknordmark we include PE partially in 11.0-stable (only inline objects, no volume reference), so backporting this test doesn't make sense. Should I backport all of the patches to 11.0-stable?

If this isn't needed in 11.0-stable then no need. Do we have an API Capability defined for the PE support? If so we should make sure it isn't set in 11.0-stable.

Copy link
Contributor

@eriknordmark eriknordmark left a comment

Choose a reason for hiding this comment

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

LGTM

@uncleDecart
Copy link
Contributor Author

If this isn't needed in 11.0-stable then no need. Do we have an API Capability defined for the PE support? If so we should make sure it isn't set in 11.0-stable.

We didn't define capability for the PE support. We should introduce it, I'll take a look

@eriknordmark eriknordmark merged commit 74539b8 into lf-edge:master Mar 13, 2024
55 of 63 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stable Should be backported to stable release(s)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants