Didier: With each upgrade we perform a database migration. So when reverting back the data structure in the database might have changed. This is potentially something we could handle inside of our platform specifically. But figured I would ask :)
On Thu, Oct 27, 2016 at 10:53 AM Didier Roche <didro...@ubuntu.com> wrote: > Le 27/10/2016 à 17:33, Aaron Ogle a écrit : > > Didier: > > This sounds like exactly what I wanted! So once this lands I will be able > to just use: snapctl get value to get user set information? > > Exactly! > > > > Will the snapctl command be available anywhere in the snap or only in the > hooks? > > > I guess the main intent is to use them primarily in hooks, but nothing > should prevent it to be available in your other snap daemon as well (as > it's part of the core rootfs). > > > > Also the upgrade hook looks like it could be a thing of beauty. Any plans > for a downgrade hook? > > > I don't know about any plan for that, I'll let others answer. I think you > mean a downgrade hook being executed after a snap revert to fetch back > "newer data" that could be lost in the revert process and transfer back to > the older version? Or do you have any other use case in mind? > > > Didier > > > On Thu, Oct 27, 2016 at 10:14 AM Didier Roche <didro...@ubuntu.com> wrote: > > Le 27/10/2016 à 16:50, Aaron Ogle a écrit : > > Greetings, > > > > With our Rocket.Chat snap, we're looking to be able to allow someone > > to run an external mongodb instead of the built in one. As well as > > we'd like to add something like caddy / traefik etc to do ssl > > termination. But its not a daemon we would want enabled out of the > > box because of the effect on existing users. > > > > So basically looking for a way let the user of a snap enable or > > disable two different daemons in our snap. > > > > Is this possible using anything out of the box? Or would I have to > > make the command ran in the daemon look at an environment variable / > > file etc. and determine if it should make the daemon just exit? > > > > How have others handled this? Or allowing users to customize snap > > behaviour? > > Hey Aaron, > > sounds like a great plan for usability! > > I would suggest using configure hooks to proceed that. Hooks are just a > way for users to set variable=value. Based on that, you can control your > daemon with a configure script (triggered by this command) inside your > snap. This one can triggers start and stop inside a mongodb daemon > wrapper (waiting for a certain value to be passed for instance before > executing the real daemon). > > The documentation is not yet published on snapcraft.io AFAIK, but is > available there: > https://github.com/snapcore/snapd/blob/master/docs/hooks.md. > > However, please keep in mind about this bug > https://bugs.launchpad.net/snappy/+bug/1636931, we need a new core image > to have snapctl available from your snap, and so, you won't be able to > experiment it right away. > > I'll probably write a codelab on this precise topic in a couple of weeks > FYI (once the feature is really available to users and developers). > Cheers, > Didier > > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- > > *Aaron Ogle* Core Developer > > aaron.o...@rocket.chat > > @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle> > > https://rocket.chat > > > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- *Aaron Ogle* Core Developer aaron.o...@rocket.chat @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle> https://rocket.chat
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft