Re: Optional daemon
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
>> 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
signature.asc
Description: OpenPGP digital signature
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Optional daemon
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
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
> >> 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://rocket.chat
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
Python 3 plugin sanity checking
I've started to snap up GNU Mailman 3. https://code.launchpad.net/~barry/+git/mailman-core-snap During an earlier iteration I forgot to add usr/lib to the snap part parts: mailman: plugin: python source: https://gitlab.com/mailman/mailman.git snap: - bin - lib - usr/lib <-- this If you install and run the resulting snap (e.g. mailman-core.mailman --version) Python will core dump because the stdlib, and in particular the 'encodings' module didn't get installed. $ sudo snap install --devmode ~/projects/mailman/snap/*.snap mailman-core 3.1b1 installed $ mailman-core.mailman --version Fatal Python error: Py_Initialize: Unable to get the locale encoding ImportError: No module named 'encodings' Current thread 0x7f77264e4700 (most recent call first): Aborted (core dumped) Wouldn't it make sense for the Python 3 plugin to either automatically include the stdlib (e.g. usr/lib) or complain loudly if it's not included explicitly in the resulting snap? Cheers, -Barry pgpmQucOKv9cq.pgp Description: OpenPGP digital signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Un-revert a snap
A refresh should result in the same behavior whether the snap is locally installed or is being downloaded. We've also (John has, actually) fixed the behavior so that a refresh of a specific snap will work, so your original attempt described in the first message on this thread will work correctly in the upcoming snapd 2.17. Thanks for raising the issue. On Thu, Oct 27, 2016 at 11:57 AM, YC Cheng wrote: > Not sure if the new "refresh" design will check if the local installed one > have the same channel/revision or even hash that match the one from server. > (I think we should.) And if yes, are we going to add something like > "--force" in case of some mix channel situation ? > > 2016-10-27 20:42 GMT+08:00 Gustavo Niemeyer com>: > >> We actually have that already in the upcoming version. You'll be able to >> say "snap refresh --revison=N ", similarly to how we can revert. >> >> That said, I think the expectation exposed in the first message is a >> reasonable one. We should probably not blacklist the current revision if >> the snap name was explicitly selected in the command line. >> >> On Oct 27, 2016 4:39 AM, "Didier Roche" wrote: >> >>> Le 27/10/2016 à 08:32, YC Cheng a écrit : >>> >>> I think we need a way to just Un-revert from rev 20 to rev 29 without >>> remove rev 29. >>> >>> Shall we fire a bug for that if we don't have such method exists now ? >>> >>> >>> I think it's not that easy considering the associated data. You need to >>> swap them to restart from the latest version of data from rev 20 to copy to >>> 29. Explicitely removing that version makes sense in that context. Have an >>> unrevert command won't convey that notion. >>> >>> Didier >>> >>> >>> >>> 2016-10-27 14:13 GMT+08:00 Didier Roche : >>> Le 27/10/2016 à 03:01, Marcos Alano a écrit : > Hello guys, Hey Marcos, > > > Sorry if I'm in the wrong mailing list. That's the only one about snap i > could found. The question is: how I revert-revert (un-revert) a snap? I > can install a snap: > > (sudo snap install hello) after thatr I can upgrade a snap (snap refresh > hello --channel=beta hello) and finally revert (sudo snap revert hello). > But after that if I try to re-upgrade I just can't: > > $ sudo snap refresh --beta hello > > error: cannot refresh "hello": snap "hello" has no updates available > > I'm doing something wrong? You are not doing it wrong :) The revert command "blacklists" this particular snap revisions on purpose, so that you don't reupdate to it. However, there is a way to get back to it! You can remove explicitely that revision (without removing the current snap). Data associated to the reverted revision will be cleaned up as well. Then, you can refresh. In a concrete example with the hello snap: 20 is the revision in the stable channel, 29 corresponds to the revision in the beta channel. # Install and update $ snap install hello $ snap list hello Name Version Rev Developer Notes hello 2.10 20 canonical - $ snap refresh hello --beta $ snap list hello Name Version Rev Developer Notes hello 2.10.1 29 canonical - # Revert $ snap revert hello $ snap list hello Name Version Rev Developer Notes hello 2.10 20 canonical - # Remove reverted version (and associated data) $ snap remove hello --revision=29 hello removed $ snap list hello Name Version Rev Developer Notes hello 2.10 20 canonical - # Reupdate $ snap refresh hello --beta $ snap list hello Name Version Rev Developer Notes hello 2.10.1 29 canonical - I hope that answer your questions :) Cheers, Didier -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/snapcraft >>> >>> >>> >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft@lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> -- >> Snapcraft mailing list >> Snapcraft@lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
