Date: Thu, 8 Jun 2017 11:42:29 +0200 From: Luca Pizzamiglio <luca.pizzamiglio@gmail.com> To: Arto Pekkanen <isoa@kapsi.fi> Cc: freebsd-pkg@freebsd.org Subject: Re: pkg rollback Message-ID: <CAB88xy9hkjgdTg-x=kuO5gjv9MWE2yh4tx%2BSZgkYQnqKQOtnTg@mail.gmail.com> In-Reply-To: <a4b73481-ac0b-faa3-7187-30dc05c19888@kapsi.fi> References: <CAB88xy_%2BTC4ErxY9UVSkoLH1eeiWNO7Ho%2B_848b09Z_GmDTU-A@mail.gmail.com> <a4b73481-ac0b-faa3-7187-30dc05c19888@kapsi.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
yes zfs snapshot/rollback could be usable, if /usr/local is on zfs. If /usr/local is on ufs, zfs snapshot is not an option :) Several older systems here were installed with root based on ufs and /usr/local is not on the zfs tank :( Reinstall all of them is, currently not an option. IMHO pkg snapshot/rollback would work on ufs and only for packages, but I see zfs as a valuable option, if applicable. Best regards, Luca On Thu, Jun 8, 2017 at 2:53 AM, Arto Pekkanen <isoa@kapsi.fi> wrote: > Why does not ZFS snapshot and rollback work for this scenario? > > On 7.6.2017 16:40, Luca Pizzamiglio wrote: >> Hi all, >> >> I'm trying to figure out how an automatic process to upgrade packages >> on production machines can look like. >> >> A kind of: >> # pkg upgrade >> # restart services >> # if everything not OK >> # rollback >> # restart services >> >> I'm considering a package repository that is not guaranteeing 100% >> stability, like `latest`. >> Even intercepting events needing manual intervention (i.e. reported by >> UPDATING), a blind pkg upgrade can break the web application running >> on top. >> So, I was thinking if it's possible to perform some kind of rollback. >> >> to proof if it's possible, I wrote a shell scripts with two features >> (it helped me a lot to understand how pkg works): >> # backup >> ## backup the repo sqlite database >> ## run `pkg update` and determine all actions would be performed by >> `pkg upgrade` (a kind of `pkg upgrade` simulation) >> ## backup all packages from the cache that would be replaced by `pkg upgrade` >> ## download all new packages to determine potentially conflicts >> ## backup all packages from the cache that would be replaced by `pkg >> upgrade` (after determined conflicts) >> ## restore the repo sqlite database >> # rollback >> ## restore the repo sqlite database >> ## install all previously backup'ed packages >> >> Another approach, less complex, but I guess even valid, could be: >> # backup (or snapshot) >> ## backup of the repo sqlite database >> ## take a snapshot of all installed packages >> # rollback (a previously stored snapshot) >> ## restore the repo sqlite database >> ## reinstall all previously backup'ed packages >> >> Adding two features [snapshot and rollback] to pkg(8), the automated >> upgrade process would become: >> # pkg snapshot >> # pkg upgrade >> # restart services >> # if everything not OK >> # rollback >> # restart services >> >> What do you think? >> What am I missing? >> Ideas, suggestions and feedback are welcome, so, please, feel free to reply. >> >> Best regards, >> Luca >> >> PS: I'd use `pkg snapshot`, because `pkg backup` already exist and it >> has another meaning. >> PS2: In some case, `zfs snapshot` could work as well, but it's not >> always possible >> PS3: if feebacks are positive, I'd like to implement those features >> _______________________________________________ >> freebsd-pkg@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-pkg >> To unsubscribe, send any mail to "freebsd-pkg-unsubscribe@freebsd.org" >> > > -- > Arto Pekkanen >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB88xy9hkjgdTg-x=kuO5gjv9MWE2yh4tx%2BSZgkYQnqKQOtnTg>