Optional daemon

Kyle Fazzari kyle.fazzari at canonical.com
Thu Oct 27 16:54:53 UTC 2016



On 10/27/2016 08:52 AM, Didier Roche 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).

There's currently a limitation here in that `snapctl get/set` needs to
know the snap whose config is being queried/altered (and snaps shouldn't
be able to query/alter the config of other snaps). This is done via a
token that is generated and tracked by snapd for each hook instance and
then used in each `snapctl` invocation. Currently this token is not
generated for apps, which means `snapctl` is only useful within hooks
for the time being. I'm uncertain on the timeline, but as I understand
it, the plan is to make `snapctl` work within apps as well.

>
>>
>> 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
>>
>>
>>
>
>
>

-- 
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/7ee42163/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/7ee42163/attachment.sig>


More information about the Snapcraft mailing list