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" <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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" <[email protected]> >> 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 >>> [email protected] >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >> > > > -- > Boris Rybalkin > [email protected] > -- Boris Rybalkin [email protected] -- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/snapcraft
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
