Currernt config hook implementation scales very badly

Wed Feb 1 15:08:02 UTC 2017

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
>>>
>>>
>>
>>