configure hook

Fri Dec 2 09:32:12 UTC 2016

Hi Didier,

In theory I would probably agree with you, but in practice I have the
following problem.

I am running a web app which uses things like nginx and uwsgi. They need
config to run, probably because they are actually more libraries than
daemons. It would be all fine to have some static config somewhere. Not to
confuse with user config which is empty by default.

Unfortunately I cannot have static config as they require absolute paths in
their configs and I want my app to be relocatable.

So as I see it there are several solutions:

1. Generate config at runtime after installation, but before starting.
(Seems not possible in snap)
2. Generate config inside each service startup wrapper script on first
start. (Sounds not ideal, but possible)
3. Generate config at build time (not relocatable)
4. Fix existing open source tools so they do not need absolute paths in
their configs (not practical)

Thanks

On 2 Dec 2016 06:50, "Didier Roche" <didrocks at ubuntu.com> wrote:

Le 02/12/2016 à 02:53, Boris Rybalkin a écrit :

Sorry still more questions on hooks.

As I understand configure hooks are executed after services startup:
https://github.com/snapcore/snapd/blob/3dc67f49c4b6fe3acd5ad
d647ac35a42fbb395d5/overlord/snapstate/snapstate.go#L184

If this is correct (and that is what I see) it completely breaks the idea
of generating service configs (many tools want absolute paths in their
configs) with configure hook as it has to be done before the start.

This explains all my issues with keeping generated configs in SNAP_COMMON
and every time I enable services and they fail I actually see configs from
previous install :)

Could anyone confirm this?

Hey Boris,

This is correct.

However, I think this forces some best practices on daemons. Remember that
configure hooks can as well be executed while your process is running. Your
process should be able to pick any configuration change and adapt
accordingly.
So, the idea is to choose sane default, not rely on a configure file until
the user chooses so, and diverge from their default (no config file or no
key in the config file means default).

That enables you to easily migrate defaults if you change them, as still
enable people to choose their own configuration without being impacted by
future default (note that ON (default) -> OFF -> ON switch, isn't a default
anymore, it's a user choice.

To illustrate that, I wrote a snap (codelab coming early next year) where a
nodejs app have a default port and title. However, you can via "snap set"
configure another port or title, and those changes are picked immediatly by
the daemon without restarting. Note that I tried to have a generic
configure hook, generating a key=value store, where setting "" value revert
to default and keeping comments, ordering and other artefacts in your config
https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
for the config hook
https://github.com/ubuntu/snow-on-me-snap/blob/master/main.js#L71 for the
nodejs webserver picking up new config on the fly.

Hope that helps outlining why this behaviour shouldn't be a problem and why
organizing your code that way is an advantage in the end (hoping you can
act on the tools that requires this).
Didier

On Fri, Nov 18, 2016 at 12:25 AM, Boris Rybalkin <ribalkin at gmail.com> wrote:

> After reinstalling snapd (2.17.1) and cleaning /var/lib/snapd/ issue seems
> to go away.
> Thank you very much!
>
> On Wed, Nov 16, 2016 at 7:20 PM, Boris Rybalkin <ribalkin at gmail.com>
> wrote:
>
>> After upgrading snapd on desktop 16.04 from xenial-proposed now I have
>> this wired message on install:
>>
>> Run configure hook of "syncloud-platform"
>> error: cannot perform the following tasks:
>> - Run configure hook of "syncloud-platform" snap if present (cannot
>> snap-exec: cannot find hook "configure" in "syncloud-platform")
>>
>> snap --version
>> snap    2.17.1
>> snapd   2.17.1
>> series  16
>> ubuntu  16.04
>>
>> Has this changed since 2.17?
>>
>> On 14 Nov 2016 22:44, "Sergio Schvezov" <sergio.schvezov at canonical.com>
>> wrote:
>>
>>> El 14/11/16 a las 18:35, Boris Rybalkin escribió:
>>>
>>>> VM has snapd v2.17, is it possible to install this version on desktop
>>>> 16.04/16.10 so I can have it for integration tests?
>>>>
>>>
>>> It is in xenial-proposed https://launchpad.net/ubuntu/+source/snapd
>>> If you want the latest and greatest at all times (non production). If
>>> you do this, follow the pinning process in
>>> https://wiki.ubuntu.com/Testing/EnableProposed to pin snapd to
>>> xenial-proposed only and not risk getting more (potentially unstable)
>>> -proposed software.
>>>
>>> Also is there any documentation on how to install snapd on a linux?
>>>>
>>>
>>> These are the installation instructions available for the variety of
>>> distros around:
>>> http://snapcraft.io/docs/core/install, in case you wonder where I got
>>> that link from, it is available as a link on the web front of
>>> http://snapcraft.io
>>>
>>> --
>>> Snapcraft mailing list
>>> Snapcraft at lists.snapcraft.io
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/snapcraft
>>>
>>
>
>
> --
> Boris Rybalkin
> ribalkin at gmail.com
>

-- 
Boris Rybalkin
ribalkin at gmail.com

--
Snapcraft mailing list
Snapcraft at lists.snapcraft.io
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
an/listinfo/snapcraft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161202/93501594/attachment.html>