[OPEN-ILS-DEV] Evergreen maintenance

[Jason Etheridge]

On 3/23/07, Harry Bochner <Harry.Bochner at biogenidec.com> wrote:
<snip>
> So before I spend too much more time on the installation phase, I'd
> like to get some input on what we might expect the maintenance phase
> to look like, once everything is installed and running.

Hi Harry, I'm one of the Evergreen developers and occasionally perform
minor ILS upgrades for PINES, and can give my POV for some of this,
but I don't perform OS or dependency upgrades or any major ILS or
database upgrades, so I'll need for Brad, Mike, and Bill to come in
and correct anything I get wrong here.  I do push out client code
upgrades and can to speak to that as well.

In my experience, once you get a stable environment there's relatively
little action required for maintenance.  In PINES, we update the
prerequisites (Apache, Jabber, Linux, etc.) infrequently, and usually
only for security fixes (and of course, most of these internal
services are firewalled off from the Internet in the first place).  I
believe upgrades for getting at new functionality (from Postgres,
etc.) should correspond with major releases of Evergreen.

We have two dedicated ldirector boxes for load-balancing/failover that
don't run Evergreen at all, and merely distribute traffic among
multiple "bricks" (clusters of servers) that do run Evergreen.  The
ldirector boxes are trivial to maintain, but you could get appliances
to do the same thing.

As for updating the ILS, that can be as simple as dropping a release
tarball into a shared filesystem (NFS for us) and running a single
update command on each brick.  Since we are using a cluster, a lot of
the time we can do "rolling" upgrades one brick at a time without
bringing down the whole system, and if needed, we can sometimes limit
ourselves to testing an upgrade on a single brick to see if any
problems manifest.  We can add and remove bricks as needed.  Now, some
upgrades will require a complete shutdown of the system (I think for
example, if the database engine or the schema needs updating), but I
don't believe there are any ILS "policy" changes that require it (Bill
can correct me if I'm wrong), though currently, some changes (like
adding a shelving location) would require a restart of any running
staff client programs to clear their caches (if say, they want to see
that shelving location, but that'll change in the future).

The staff client program is a glorified web browser, and it'll be a
rare ILS upgrade that would require a corresponding upgrade of the
client code installed out in the libraries.  Most of the functionality
is served remotely and cached locally, and the local code is mainly
for providing an off-line interface for bookmobiles and in case of
network outages, and for access to the local file system for storing
some preferences, etc.  If it weren't for current perceptions of "web
app" vs "native app", I'd likely be developing the client as a Firefox
extension (though those perceptions are changing, thankfully).  To
date, PINES is still running on the same staff client executable since
"go-live" back in September, though I've been trying to foist a beta
client on them. :)

Now, there are some things we need or would like to see in the long
run.  Work is ongoing to make installation easier.  There's some
volunteer effort to integrate autotools, for example, and there are
volunteer wiki maintainers who are updating the installation
instructions for different distributions with what we learn on this
mailing list.

There's also a proposal for something Mike calls FIT, for Build,
Package, Deploy, Maintain:
http://open-ils.org/dokuwiki/doku.php?id=build_install_deploy_fit

>From that page: "Currently, the entire Evergreen package runs almost
unaltered from the CVS layout. This was an initial design decision to
avoid the overhead of moving things around into a different structure
for a running system, and has served well in a development
environment. It has allowed us to build and test changes in a running
system with almost no down time using simple symlinks. Now that we're
stamping versions and receiving a good bit of outside interest,
though, it makes sense to create a more structured packaging system.
It will also make easier a degree of automated testing during the
build process, and ease the creation of dependency checking hooks."

> Thanks in advance for any feedback (including, perhaps, less
> high-powered packages we might look into).

No problem.  Let me know if this helps, or if you have any other questions.

The only other open source package I could recommend would be Koha,
which left you dissatisfied.  Recent versions of it are more capable
with larger collections, though that's not likely a problem for you.
I don't know what else has changed recently (as far workflow
improvements, etc.) but I'm sure some of the Koha folks on here would
be willing to chime in.

I'm a little enamored with Delicious Library (a Mac application), but
I'm not sure how suitable it would be for you:
http://www.delicious-monster.com/

-- 
Jason Etheridge
GPLS -- PINES Development
http://open-ils.org/