Optional daemon

[Kyle Fazzari]

On 10/27/2016 11:27 PM, Didier Roche wrote:
> Le 27/10/2016 à 19:00, Aaron Ogle a écrit :
>> On Thu, Oct 27, 2016 at 11:56 AM Kyle Fazzari
>> <kyle.fazzari at canonical.com <mailto:kyle.fazzari at canonical.com>> wrote:
>>
>>
>>     So are you storing this database in $SNAP_COMMON? Because
>>     $SNAP_DATA would do this for you, no?
>>
>>
>> Correct we are doing in $SNAP_COMMON.  Is $SNAP_DATA using CoW?  Or is
>> it going to be a full copy.  From what I could see it was a full
>> copy.  This would quickly add up.  Not to mention you loose all of our
>> messages sent when you roll back.

No, you're correct-- it's a full copy. But ...

> I would suggest to use $SNAP_DATA. Once we have garbage collection
> enabled on snapd, you will have approx. 2 copies at most of your data
> (the old version and the current one). I guess this is a reasonable
> tradeoff to ensure you can always revert safely.

This ^^ . Note that garbage collection is in place today: snapd will
begin pruning revisions once you have three of them, i.e. you will have
only the three most recent revisions taking up space.

> Imagine the case if a new version corrupts your data. You will not have
> any way to retrieve them back if you store in $SNAP_COMMON, whichever
> downgrade scripts you are writing…
> 
> So, I would argue to try $SNAP_DATA first, and then only revisit to move
> to $SNAP_COMMON if you see that doesn't suit you.

I second this. Note that the ability to revert is not necessarily
something that should be exercised a week after using the new version
("Nah, the other one was prettier. Revert!") simply because of the
limitation you pointed out. It's better used with "Uh oh, my web server
isn't coming up with this version. Revert!" or "Uh oh, my database
migration failed. Revert!"

Of course, nothing says it can't be used that way, but then you run into
the limitations of the facilities provided by snapd, and you need to
start hosting your data in a version-agnostic area (like you're doing).
Which has its risks, as Didier pointed out.

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

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