Currernt config hook implementation scales very badly

Michael Hall mhall119 at ubuntu.com
Wed Feb 1 14:48:47 UTC 2017


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.


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




More information about the Snapcraft mailing list