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.fazz...@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.fazz...@canonical.com <mailto:kyle.fazz...@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. > k...@canonical.com > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- *Aaron Ogle* Core Developer aaron.o...@rocket.chat @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle> https://rocket.chat
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
