[Building Sakai] Issues with upgrading

[Tony Stevenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Folks,

Late last week I was asked to upgrade one of our 0.1-release instances
of OAE to Sprint 103.  This failed.  Despite help from Bert, Ian and
Chris Roby (thanks guys).

Historically we have been building our own UX and kernel.  This is
because we incorporated changes such as enabling MySQL out OOTB and a
cam.ac.uk UX change to enable the use of our institutional login process.

Several things failed, resulting in a broken system.  Since we deployed
this box several things have changed and I am not confident that the
community as a whole is fully aware of the state of the play, and the
ramifications of the current situation.

1)  UX upgrading/downgrading.
As part of the upgrade we would have to upgrade the templates, because
they they have split users/groups.  This meant that as a result of this
change, old data would no longer work (i.e. viewing groups didn't render
the navigation components).  This is a major break and without backwards
compat all our previous data is useless.  This is extremely irritating.

SUGGESTED FIX:  Implement compat across all major releases.

If you upgrade your UX, you cannot then downgrade it as the newer bundle
will have files with modified/created timestamps newer than the older
bundle and the Sling loader only currently use these to determine if it
should replace files.  This means having to restore your sling folder.
This is annoying if you have upgraded the kernel already.

SUGGESTED FIX:  Investigate alternate methods to determine overwrite
ability. Perhaps even the use of a BOFH-Overwrite flag. i.e. "I know
what I am doing, and asking you to do, so just do it already"


2)  Data Migration
During an upgrade, you want your data to come across and be compat with
the new release.  Not left behind in an old version that means you cant
use it. There is no way I would be happy to deploy a pilot until this
blocker and key component is fixed.  Also, in the event of a failed
upgrade you should be able to roll back your data (even if that is a
manual but very well documented step).

In the next release should we expect to see a bunch of
tools/scripts/docs to help migrate data from a 0.1-release?  If not,
what is the expectation for those running older releases?

To be clear I don't expect to see scripts and the likes to support
upgrades to sprint versions, but I would expect to see them for
release(a)->release(b)

3)  JCR->Sparse
I now see that ieb has pulled sparse into the master branch.  But what I
do not see is any 'real' talk/effort on producing a migration
script/tool/widget/document/etc  to tell folks how to do this.

I am happy to help where we can, and help feedback where we can.  But I
do not want to go into this blindly. I would need to see some structure
before we took part.

- ----

Now, our local instance wasn't trashed because I kept several copies of
the sling folder (and many more throughout the failed upgrade process)
and the original jar file.

To recover the instance I had to restore both of these.

In summary, I'm not currently seeing sufficient information, time, or
resource being spent in this area.  Surely this would be a key area
before the next release, else you will risk alienating those at the
coalface. Again I am happy to help with this.



- -- 

Cheers,
Tony

- ------------------------
tony at pc-tony.com
pctony at apache.org
tony at caret.cam.ac.uk

http://blog.pc-tony.com

GPG - 1024D/51047D66
- ------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ZNaAACgkQyceSTlEEfWY9DACcCxc0fFhP3a7afFvlfBE1tDaE
KSwAni9MYfLC82tR7bhR2VFj3xo4Tsfv
=H+eh
-----END PGP SIGNATURE-----