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

o/devicestate: refactor remodeling code to use new snapstate API #14898

Merged

Conversation

andrewphelpsj
Copy link
Member

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.

@andrewphelpsj andrewphelpsj requested a review from pedronis January 6, 2025 15:38
@github-actions github-actions bot added the Needs Documentation -auto- Label automatically added which indicates the change needs documentation label Jan 6, 2025
@andrewphelpsj andrewphelpsj requested a review from bboozzoo January 6, 2025 15:38
@andrewphelpsj andrewphelpsj force-pushed the remodel-new-api-refactor branch from 92ea8ad to 3a2bbfd Compare January 7, 2025 14:14
Copy link
Collaborator

@pedronis pedronis left a 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 {
Copy link
Collaborator

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?

Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

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

did a pass

Components []PathComponent
}

type PathComponent struct {
Copy link
Collaborator

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?

overlord/devicestate/devicestate.go Outdated Show resolved Hide resolved
}), nil
}

func (r *remodeler) installedRevisionUpdateGoal(
Copy link
Collaborator

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

Copy link
Member Author

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?

overlord/devicestate/devicestate.go Show resolved Hide resolved
offline bool
localSnaps []*snap.SideInfo
localSnapPaths []string
type remodeler struct {
Copy link
Collaborator

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?

@@ -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 {
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, thanks!

path string
// remodelTarget represents a snap that is part of the model that we are
// remodeling to.
type remodelTarget struct {
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
type remodelTarget struct {
type remodelSnapTarget struct {

wdyt?

Copy link
Collaborator

@pedronis pedronis left a comment

Choose a reason for hiding this comment

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

thank you

Copy link

codecov bot commented Jan 13, 2025

Codecov Report

Attention: Patch coverage is 89.61938% with 30 lines in your changes missing coverage. Please review.

Project coverage is 78.30%. Comparing base (24a0034) to head (e159ff0).
Report is 107 commits behind head on master.

Files with missing lines Patch % Lines
overlord/devicestate/devicestate.go 87.65% 20 Missing and 10 partials ⚠️
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     
Flag Coverage Δ
unittests 78.30% <89.61%> (+0.10%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

@andrewphelpsj andrewphelpsj added the Run nested The PR also runs tests inluded in nested suite label Jan 13, 2025
@andrewphelpsj andrewphelpsj reopened this Jan 13, 2025
Copy link
Contributor

@bboozzoo bboozzoo left a comment

Choose a reason for hiding this comment

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

LGTM

@bboozzoo
Copy link
Contributor

A bunch of nested remodel tests fail with:

+ VERSION=24
+ remote.push /home/gopath/src/github.com/snapcore/snapd/tests/lib/assertions/classic-model-rev1-24.assert
Warning: Permanently added '[localhost]:8022' (ED25519) to the list of known hosts.
++ remote.exec 'sudo snap remodel --no-wait classic-model-rev1-24.assert'
sudo: unable to resolve host localhost.localdomain: Name or service not known
error: cannot remodel: cannot remodel device: cannot perform operation on local snap
+ change_id=
-----
.
2025-01-13 22:48:39 Debug output for google-nested:ubuntu-24.04-64:tests/nested/manual/hybrid-remodel (jan132223-957648) : saved to file spread-logs/google-nested_ubuntu-24.04-64_tests_nested_manual_hybrid-remodel.debug.log

@andrewphelpsj andrewphelpsj force-pushed the remodel-new-api-refactor branch from 2288fe5 to 0036344 Compare January 14, 2025 16:26
Copy link

github-actions bot commented Jan 14, 2025

Tue Jan 14 22:19:17 UTC 2025

No spread failures

@andrewphelpsj andrewphelpsj force-pushed the remodel-new-api-refactor branch from 4f1135d to e159ff0 Compare January 14, 2025 17:26
@andrewphelpsj
Copy link
Member Author

Required failures are:

google-nested:ubuntu-20.04-64:tests/nested/manual/core20-new-snapd-does-not-break-old-initrd:startwithnew
google-nested:ubuntu-24.04-64:tests/nested/manual/hybrid-remodel
google-nested:ubuntu-24.04-64:tests/nested/manual/remodel-min-size

These are known failures and are unrelated to this change.

@alfonsosanchezbeato alfonsosanchezbeato merged commit 5305352 into canonical:master Jan 14, 2025
54 of 60 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Documentation -auto- Label automatically added which indicates the change needs documentation Run nested The PR also runs tests inluded in nested suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants