Currernt config hook implementation scales very badly

[Didier Roche]

Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit :
>
> Yes, that's in the plans for configuration support already.  The idea
> is to extend snapctl with the ability to introspect exactly which
> settings have changed since the last successful run of the script, and
> perhaps which values it used to hold before.
>
> For the time being, I suggest not worrying much about that. Just go
> ahead and implement the semantics you want the user of the snap to
> experience. Inside the configure hook, check to see if the requested
> value is already in place and do nothing in that case. This makes the
> script idempotent, resilient because it ensures the desired state is
> indeed in place, and also cheap to execute in the common case.
>  

If someone is interested, I have implemented this kind of idempotent
configure hook example. It can be found at
https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
as part of the christmas snap demo.
It features:
- support key=value formatting
- ignoring, but not erasing unknown keys, comment lines, empty ones.
- preserving formatting and ordering, even when changing an existing key.
- only snap set arguments will be modified if a value is set. If the
value assigned to it is empty, removing the key line
- new elements not present in existing configuration file are simply
appended.

Supporting new keys (like here "foo") is just a matter of adding:
update_opt_in_config foo

at the end of the file.

I hope this helps! (note that the issue is still "what's the supported
keys for this snap?")
Cheers,
Didier

>
>
> On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert <ogra at ubuntu.com
> <mailto:ogra at ubuntu.com>> wrote:
>
>     hi,
>
>     after we recently added a config hook [1] to the core snap it is now
>     possible to disable ssh if you require [2] ...
>
>     there is a long standing request to do the same for syslog for systems
>     running from SD card, which is why i looked into trying to extend the
>     existing configure script for this, which made me notice some issue...
>
>     when you call "snap set core foo=bar", there is no indication at all
>     for the script which variable changes a value, neither in the shell
>     environment nor in the argument list.
>
>     the only way to get your value is to call snapctl for every existing
>     variable [3]. since you dont know what specific variable was requested
>     to change the only way to reliably write it is to write *all* existing
>     variables ... 
>
>     now, if you package something with a more complex config that you want
>     completely handled via snap config this gets ugly very fast... imagine
>     something like postfix with can potentially have 100s of config
>     options. instead of atomically changing a single option you will
>     regenerate the full config from scratch. this takes a lot longer,
>     bringing the risk of a completely broken config in case of a power
>     loss, beyond resulting an an awful config hook script with a large
>     block of "snapctl get" calls at the top.
>
>     can we extend the config hook implementation minimally so a "snap set
>     core foo=bar" would at least have something like "SNAP_OPTION=foo" in
>     the environment that the generating script or binary could read to
>     avoid the unnecessary processing or would that break some design
>     concept ?
>
>     ciao
>             oli
>
>     [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/
>     hooks/configure
>     <http://bazaar.launchpad.net/%7Esnappy-dev/core-snap/trunk/view/head:/%0Ahooks/configure>
>     [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref
>     erence/core-configuration.md
>     <https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref%0Aerence/core-configuration.md>
>     [3] https://github.com/snapcore/snapd/wiki/hooks
>     <https://github.com/snapcore/snapd/wiki/hooks>
>     --
>     Snapcraft mailing list
>     Snapcraft at lists.snapcraft.io <mailto:Snapcraft at lists.snapcraft.io>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/snapcraft
>     <https://lists.ubuntu.com/mailman/listinfo/snapcraft>
>
>
>
>
> -- 
> gustavo @ http://niemeyer.net
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170201/38dbc974/attachment.html>