On 06/12/2014 06:21 AM, Filip Hajny via smartos-discuss wrote:
12. 6. 2014 v 10:45, Tim Boudreau via smartos-discuss
<[email protected]>:
Someone can correct me if this is likely to have unanticipated side effects,
other than the ones already mentioned in this thread (i.e. you need to be
*really* confident that the packages you update will update cleanly - and do a
snapshot first!).
Yes, definitely make a snapshot before you start, and if the VM provides any public
service and you can’t just take it out of a balanced pool, make sure you handle it
as a planned downtime. Of course, ideally you’d have your entire VM scripted up in
Chef or similar (heck, even Bash scripts are better than nothing), but sometimes
that’s just sometimes not possible. (One those "I’ll just handle this one
update manually and I swear I’ll script up the setup next time” things.)
For the records again (since I write from a Joyent address), Joyent doesn’t
recommend that you do this.
I’ve done this myself way too many times (not recently though) and we even
tried to come up with a script that takes the user through known obstacles.
However, it turned out there’s just no way to prepare for all possible
consequences and factors, and providing a script immediately makes this a
supported procedure in many eyes, so…
In general, issues are less likely to crop up if you’re only moving by a
quarter, compared to two years, and if you have a minimum number of packages
(e.g. started from ‘base’) rather than way too many (started from ‘standard’ or
even the old ‘smartosplus’).
It’s crucial to check the initial “I’m going to upgrade all these packages for
you” message that pkgin gives you (and yes, it’s annoying difficult to read and
parse) and look for any major upgrades of MySQL or PostgreSQL. Especially
PostgreSQL updates (e.g. moving from 9.1 to 9.2) are a pain, because you need
to create a full dump of your storage before you even start the update, then
import it into a blank one again. This may just apply to any package that
stores user data in its own format.
Another typical problem you may hit is when a config file changes significantly
or even stops working because of a major update. One of the good things about
pkgsrc is that every single file that a package installs under $PREFIX/etc is
copied there at installation time from an example under
$PREFIX/share/examples/$package. So what you could do diff each config file
against the *old* example file and save that as a patch. If you get stuck on
the updated VM later on, you could take the *new* example config file, apply
the patch to it (or transplant the changes manually) and fix the problem.
Another of the issues I ran into is when packages *don't* get new
version numbers in the new quarter, things can get weird.
I wanted to remove the gcc47-runtime package from my zone transitioning
from 2013Q4 to 2014Q1 and discovered a bunch of packages were still
depending on it. Why? Because they had identical version numbers in the
new quarter. I had to forcibly reinstall all of them before I could
remove the obsolete package.
You can get yourself into a very messy state that mostly works, but will
be painful for the next upgrade.
(Or at the very least is wasteful of memory because you have two
different versions of libgcc being used side by side... no big deal in a
big zone, but in a busy zone with a small memory cap it can all start to
add up...)
So yes, if you don't mind the bumps and bruises, snapshot the zone, and
go for it.
Just keep in mind what Jonathan wrote in his email.
There's a spectrum between "we'll take care of all the upgrade details
for you" and "here's the latest and greatest, deploy at will".
Ubuntu is the epitome of the former, and pkgsrc, of the latter.
-Nahum
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
