-
Notifications
You must be signed in to change notification settings - Fork 583
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/snapstate: properly handle components when refreshing to revision that has been on the system before #14498
o/snapstate: properly handle components when refreshing to revision that has been on the system before #14498
Conversation
I forgot a commit here, will open again shortly. |
3118cf4
to
a655bf5
Compare
8e7d528
to
0bfd630
Compare
…hat has been on the system before
e1bab5e
to
5a3180e
Compare
…ady installed for a snap revision that we don't want anymore
5a3180e
to
93b98c2
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.
I'm a bit confused by the change in snapstate.go
@@ -13796,10 +13796,10 @@ func (s *snapmgrTestSuite) TestUpdateStateConflictRemoved(c *C) { | |||
|
|||
func (s *snapmgrTestSuite) TestUpdateWithComponentsBackToPrevRevision(c *C) { |
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.
shouldn't we have kept both a version with and without components of this?
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.
I can add the old version back if you like, but this is really just additive, the functionality of the original test is still there.
overlord/snapstate/snapstate.go
Outdated
// | ||
// This is mostly relevant when we're moving from one snap revision to another | ||
// snap revision that has already been installed on the system. The target snap | ||
// might have components that are installed that we don't want any more. |
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.
I'm confused by this comment, aren't the component linked to a given snap revision, why would we remove components when switch around by revision?
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.
Yes, they are linked by snap revision. Consider this case:
snap revision 1, components a, b
snap revision 2, components b, c
When we move from snap revision 2 -> 1, we need to unlink component a (and discard it, if nothing else references it) and install component c.
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.
I am a bit confused about the comment too, should "target snap might have components that are installed that we don't want any more" be "target revision might have components that were installed in the past but that we don't want any more"? Or maybe state more clearly that this is about checking a revision that was active in the past and still around but not currently. I always find misleading when we talk about installed revisions for non-active but present revisions.
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.
I see what you mean, I'll update it to be explicit when I'm talking about something that was installed in the past.
…vision we are moving to
Here is the set of tasks generated by the new test:
|
…ponents This test ensures that we don't hit the store when we have no components to check on.
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.
couple of worries/questions
overlord/snapstate/component.go
Outdated
func installComponentAction(st *state.State, snapst SnapState, snapRev snap.Revision, channel string, opts Options) (*store.SnapAction, error) { | ||
var si *snap.SideInfo | ||
if snapRev.Unset() { | ||
si = snapst.CurrentSideInfo() |
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.
mmh, test don't seem to hit this case?
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.
Looking at the code, we can't reach that case. Removed.
overlord/snapstate/snapstate.go
Outdated
i18n.G("Unlink component %q for snap revision %s"), ci.Component, snapsup.Revision(), | ||
)) | ||
|
||
unlink.Set("snap-setup", snapsup) |
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.
will this confuse findSnapSetupTask ? that's one example but I fear we might have a few bits of logic that assume there is mainly one task in a snap lane with snap-setup attached to it vs id?
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.
I've change this in 6014886.
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.
Don't know why I didn't do that in the first place.
…ng extra already-present components
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
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, just some nitpicks about comments
overlord/snapstate/snapstate.go
Outdated
// | ||
// This is mostly relevant when we're moving from one snap revision to another | ||
// snap revision that has already been installed on the system. The target snap | ||
// might have components that are installed that we don't want any more. |
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.
I am a bit confused about the comment too, should "target snap might have components that are installed that we don't want any more" be "target revision might have components that were installed in the past but that we don't want any more"? Or maybe state more clearly that this is about checking a revision that was active in the past and still around but not currently. I always find misleading when we talk about installed revisions for non-active but present revisions.
overlord/snapstate/snapstate.go
Outdated
|
||
// note that we don't need to worry about kernel module components here, | ||
// since the components that we are removing are not associated with the | ||
// currently installed snap revision. unlink-component differs from |
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.
and here it says "currently installed", which contradicts how "install" is used in the function description
@@ -14127,8 +14475,8 @@ type updateWithComponentsOpts struct { | |||
} | |||
|
|||
func componentNameToType(c *C, name string) snap.ComponentType { | |||
typ := strings.TrimSuffix(name, "-component") | |||
if typ == name { | |||
typ, _, ok := strings.Cut(name, "-component") |
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.
nitpicking, but this is not doing the same as TrimSuffix (not that I expect a component to be called xx-componentblah-component, but still...)
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.
I did it this way because I wanted to be able to add some components like "test-component-extra", the difference was intentional.
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.
Ok, I see, sounds good
This change properly handles components when refreshing to a snap revision that has already been on the system.
When doing something like:
snap refresh --revision=n snapname
, wheren
has already been installed on the system, we were previously just switching back to the components that were installed with that revision. This is more of a revert than a refresh.To properly handle this, we should consider which components are currently installed, and remove any that are not available for the revision
n
, and check with the store for the most up-to-date revisions of components.