Optional daemon

[Kyle Fazzari]

On 10/27/2016 08:59 AM, Aaron Ogle wrote:
> 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 :)

So are you storing this database in $SNAP_COMMON? Because $SNAP_DATA
would do this for you, no?

>
> On Thu, Oct 27, 2016 at 10:53 AM Didier Roche <didrocks at ubuntu.com
> <mailto:didrocks at 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
>>     <didrocks at ubuntu.com <mailto:didrocks at 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
>>         <http://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 at lists.snapcraft.io
>>         <mailto:Snapcraft at lists.snapcraft.io>
>>         Modify settings or unsubscribe at:
>>         https://lists.ubuntu.com/mailman/listinfo/snapcraft
>>
>>     -- 
>>
>>     	
>>     *Aaron Ogle* Core Developer
>>
>>     aaron.ogle at rocket.chat <mailto:aaron.ogle at rocket.chat>
>>
>>     @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle>
>>
>>     https://rocket.chat
>>
>>
>>
>
>     --
>     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
>
> -- 
>
> 	
> *Aaron Ogle* Core Developer
>
> aaron.ogle at rocket.chat <mailto:aaron.ogle at rocket.chat>
>
> @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle>
>
> https://rocket.chat
>
>
>

-- 
Kyle Fazzari (kyrofa)
Software Engineer
Canonical Ltd.
kyle at canonical.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161027/f191bf0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161027/f191bf0f/attachment.sig>