Currernt config hook implementation scales very badly

Wed Feb 1 17:39:44 UTC 2017

If we made some generic config helpers in Go, they could be part of the
core snap instead of being included in each individual one.

However, it's actually very hard to have an arch-independent snap, in my
experience, due to the number of dependencies you typically need to
bundle which are often arch-dependent.

Michael Hall
mhall119 at gmail.com

On 02/01/2017 10:08 AM, Didier Roche wrote:
> Le 01/02/2017 à 15:48, Michael Hall a écrit :
>> On a related note, does anybody have a suggestion on a lightweight way
>> of programmatically modifying configs in .ini, XML or JSON?
>>
>> I have a couple of use-cases (erlang-based nosql databases) where the
>> server updates the the local configuration, so I can't just overwrite
>> the whole thing every time. Didier's example will work for a very basic
>> key=value config file, but not something more structured, and I'd hate
>> to introduce Python, Perl or Java just for this.
> 
> That's exactly why I limited for now to simple key=value (and
> sourceable) files, while keeping comments and other formats (so .ini
> file should work if you scaffold it). I wanted to limit the hook to
> shell script to be architecture independant and not adding a dep on some
> runtime language.
> 
> I don't know if it's sane to have more structured one in dash-compatible
> shell. Introducing helpers written in Go means that you have to compile
> your (potential arch-all snap like a nodejs webserver) to be arch-dependant.
> Thoughts?
> 
> Didier
>>
>>
>> Michael Hall
>> mhall119 at ubuntu.com
>>
>> On 02/01/2017 08:54 AM, Didier Roche wrote:
>>> 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
>>>>
>>>>
>>>
>>>
> 
> 
> 