Support for passthrough into snap.yaml

Hello all,

Last week I’ve had a good conversation with @kalikiana about a recurring problem we find: we need to be able to use new features of snapd as soon as they are available, and in fact even before they are available (edge, beta, etc), and we should be able to use snapcraft without it refusing to pass on option that it does not understand.

So here is the proposal we got to:

  1. Snapcraft will accept two new fields, named “passthrough”. One at the top level, and one at the application scope. In points below, these locations are referred to as the target scope.
  2. When these fields exist they must necessarily contain a map.
  3. Options inside the map are passed through directly into “snap.yaml”, in the target scope where the passthrough option itself lives.
  4. Snapcraft must forbid defining an option inside the passthrough if that option is also directly present in the target scope.
  5. Snapcraft must warn whenever it sees an option in the passthrough, to remind the publisher that these options are not yet supported, with a message similar to:
    “Unsupported options are being passed through into the snap without validation.”
  6. Snapcraft might learn to report options that are potentially already supported. But it must not prevent these options from being passed through, since the option may be defined in a way that is not yet understood by Snapcraft and should thus pass through.

How does that sound?

2 Likes

FYI, the review tools in the store will continue to prompt for manual review when they see the passed through content, but it sounds like that continues to be exactly what we want (we can always manually approve).

1 Like

As someone using the “layouts” feature heavily, this does sound like a solution to the annoying problem I’m hitting continually. But I have to ask if it is avoiding the greater problem: why is snapcraft ignorant of features snapd supports?

Could snapcraft have super-basic support for experimental features in snapd, printing a warning whenever the user uses them that they are not validated and liable to change? At least then syntax errors and typos will be reported at creation time and not install time. The feature label could be prefixed to distinguish them from formally supported features, e.g. “experimental-layouts:”, so later snapcrafts can recommend adopting the formal syntax.

I’d just be concerned that snapcraft could fall further behind if people start to rely on this passthrough feature.
-G

You’re describing pretty much what pass-through is about. Except the proposal is a dedicated property that declares those experimental features rather than weakening validation of the entire snapcraft.yaml. So you would say for example

name: foo
pass-through:
    confinement: next-generation
    planet: saturn
apps:
    foo:
        command: foo
        pass-through:
            daemon: complex
            spaceship-anchor: titanium

You can see here both global properties and app-specific properties that exist being overridden by pass-through, and new ones that Snapcraft doesn’t know about. Note that all known properties are still validated normally here and only what’s specified in pass-through is not type-checked.

You will 1) get a warning for using pass-through, telling you that it’s not validated and can’t be released to the store 2) as well as an error if you’re trying to specify values in pass-through that are already regular properties in the same snapcraft.yaml.

1 Like

Implementation here: snapcraft#2053

Thanks!

Per comment there, looks surprisingly clean. The only recommendation looking through the code would be to keep “passthrough” without the hyphen as suggested in the first proposal above.

That’s cleaner in code and avoids underlines and dashes in what is a single term conceptually. Both forms seem to exist in English, with the one without the hyphen usually being used for nouns.

Is there a reason we don’t want this for other top-level objects in the snap.yaml? Hooks, plugs, slots?

These are not really validated right now as far as I’m aware ie. in the schema they are mere objects.

Ah indeed, plugs and slots are just passed through already. Hooks are limited to a plugs property, though.

I’ve just started playing with this feature using snapcraft 2.41 from beta channel, it appears that snaps built with passthrough are gated by snapcraft, I’m getting the following warning:

The 'passthrough' property is being used to propagate experimental properties to snap.yaml that have not been validated. The snap cannot be released to the store.

@sergiusens @kyrofa Can we please remove the second part of this message? What we want to do is to flag for manual review rather than reject it, but it’s the store that should be reporting that not snapcraft itself, since those rules can change and snapcraft won’t know it.

(cc @jdstrand)

2 Likes

Note that nothing is gated here, it’s just meant to be a warning about the fact that the store will flag it. However, you’re right: the store may add support for whatever is being passed through, it doesn’t make sense for Snapcraft to really say anything about the store.

2 Likes

Second part of the message removed here.

2 Likes