Optional daemon

[Aaron Ogle]

Point definitely well made.  I'm with you now.  :)

Now this being the case.  I can't just swap the location.  This is where I
would need a rock solid upgrade hook.  But I would only need to run it the
once. Any suggestions?  Or any good examples?

On Fri, Oct 28, 2016 at 1:54 PM Kyle Fazzari <kyle.fazzari at canonical.com>
wrote:

>
>
> 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
>
> --
> 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/20161028/2a0fe1cd/attachment.html>