-
Notifications
You must be signed in to change notification settings - Fork 594
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
o/devicestate: refactor remodeling code to use new snapstate API #14898
o/devicestate: refactor remodeling code to use new snapstate API #14898
Conversation
92ea8ad
to
3a2bbfd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one question
@@ -1597,11 +1561,29 @@ func createRecoverySystemTasks(st *state.State, label string, snapSetupTasks []s | |||
// that is represented by the snap.SideInfo. | |||
type LocalSnap struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't we reuse types from snapstate like PathSnap etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did a pass
overlord/snapstate/target.go
Outdated
Components []PathComponent | ||
} | ||
|
||
type PathComponent struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs a doc comment, also shouldn't this be defined before it is used?
}), nil | ||
} | ||
|
||
func (r *remodeler) installedRevisionUpdateGoal( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this one probably merits a comment and its use of a StoreGoal which will not result in store usagge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On that note, about not reaching out to the store. This is problematic in case of components, since we always reach out to the store if the snap has components installed (since they might require updates, even if the snap doesn't).
I wonder, is this a place for a new *Goal
, that only considers snaps and components that are already installed on the system?
offline bool | ||
localSnaps []*snap.SideInfo | ||
localSnapPaths []string | ||
type remodeler struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it might be worth in a follow to move this and its dedicated helpers to a remodeler.go file?
overlord/snapstate/target.go
Outdated
@@ -813,7 +813,7 @@ type pathInstallGoal struct { | |||
|
|||
// PathInstallGoal creates a new InstallGoal to install a snap from a given from | |||
// a path on disk. If instanceName is not provided, si.RealName will be used. | |||
func PathInstallGoal(instanceName, path string, si *snap.SideInfo, components map[*snap.ComponentSideInfo]string, opts RevisionOptions) InstallGoal { | |||
func PathInstallGoal(instanceName, path string, si *snap.SideInfo, components []PathComponent, opts RevisionOptions) InstallGoal { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we're already touching all affected places, could this use PathSnap?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks!
overlord/devicestate/devicestate.go
Outdated
path string | ||
// remodelTarget represents a snap that is part of the model that we are | ||
// remodeling to. | ||
type remodelTarget struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type remodelTarget struct { | |
type remodelSnapTarget struct { |
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #14898 +/- ##
==========================================
+ Coverage 78.20% 78.30% +0.10%
==========================================
Files 1151 1154 +3
Lines 151396 153091 +1695
==========================================
+ Hits 118402 119883 +1481
- Misses 25662 25826 +164
- Partials 7332 7382 +50
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
A bunch of nested remodel tests fail with:
|
2288fe5
to
0036344
Compare
Tue Jan 14 22:19:17 UTC 2025 No spread failures |
…take in a type that can wrap local snaps and components
… contains components
…r in preparation for components The refactor makes it so all of the decisions about what to do for a snap in the incoming model are all in the same place. I feel that this is pretty useful now, and it will simplify adding the logic that is needed for handling components as well.
… that is used in snapstate.PathSnap
…te.PathInstallGoal api
… current snap is not tracking a channel
4f1135d
to
e159ff0
Compare
Required failures are:
These are known failures and are unrelated to this change. |
The new snapstate API supports components, so we need to swap over to that before anything else.
This also includes a refactor to move where we make some of the decisions during remodeling. Specifically, we were duplicating a lot of the logic for what snap to install/update for essential and non-essential snaps. This will get worse when introducing components, so I think it makes sense to move things around a bit so that we can share some more code for the essential and non-essential snaps.