-
Notifications
You must be signed in to change notification settings - Fork 574
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
seedwriter: check if the optionSnap channel is same as model assert #14071
base: master
Are you sure you want to change the base?
seedwriter: check if the optionSnap channel is same as model assert #14071
Conversation
cd8b4f3
to
c1cad8d
Compare
@@ -427,9 +427,23 @@ func (w *Writer) SetOptionsSnaps(optSnaps []*OptionsSnap) error { | |||
if err != nil { | |||
return fmt.Errorf("cannot use option channel for snap %q: %v", whichSnap, err) | |||
} | |||
if err := w.policy.checkSnapChannel(ch, whichSnap); err != nil { |
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.
AFAIU the original check is intentional and if you are using a mode with grade > dangerous, the channel is already specified in the model itself, thus it is a mistake to attempt to pass one in the command line.
Note that it is enough to pass the snap name as --snap <name>
to include an optional snap. During seeding the snap will be set up to track the right channel
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.
The current behavior is mostly so that the check is very simple and consistent, and there is no giving the impression that one can specify a different channel if grade != dangerous. What's the use case for passing in a channel anyway? As @bboozzoo explained --snap <name>
is enough to trigger inclusion of the optional snap.
If we define `presence: optional` for an app snap in the model assertion, and the default channel is `24/stable` for example, then when we pass `--snap=SNAP=24/stable` to `snap prepare-image` with a model assertion that has model grade higher than `dangerous`, I will get an error `error: cannot override channels, add devmode snaps, local snaps, or extra snaps with a model of grade higher than dangerous` However, I am expecting that snapd should check whether the channel for option snap is same as the channel defined in model assertion, maybe snapd should only return error if channel is not the same and the model grade is higher than dangerous Signed-off-by: Aristo Chen <[email protected]>
c1cad8d
to
633b7a2
Compare
Thanks for the explanation! Previously I wasn't familiar with the IMO, maybe snapd should accept both I just realized that my original patch will affect all scenarios even if |
If we define
presence: optional
for an app snap in model assertion, and the default channel is24/stable
for example, then when we pass--snap=SNAP=24/stable
tosnap prepare-image
with a model assertion that has model grade higher than dangerous, I will get an errorerror: cannot override channels, add devmode snaps, local snaps, or extra snaps with a model of grade higher than dangerous
However, I am expecting that snapd should check whether the channel for option snap is same as the channel defined in model assertion, maybe snapd should only return error if channel is not the same and the model grade is higher than dangerous