Optional daemon

[Aaron Ogle]

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 <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> 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 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
>
> @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle>
>
> https://rocket.chat
>
>
>
> --
> Snapcraft mailing list
> 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

@aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle>

https://rocket.chat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20161027/e9aa0eb4/attachment.html>