Forum OpenACS Development: Clarification of Upgrade milestone criterion

We have a milestone criterion, "all the core packages have upgrade scripts."  I would like community input on exactly what this should mean for 5.0 and for future upgrades.  Here are some possibilites:

Level 1
1) Go to APM.
2) Click upgrade.
3) Done

Level 2
1) install 4.6.3 vanilla
2) untar the the 5.0 tarball on top of the 4.6.3 files
3) visit apm upgrade page
4) Click upgrade
5) Wait for server to restart
6) Done

Level 3
Less than 20 manual steps (where 1 step is the same scope as those in https://openacs.org/doc/openacs-5-0-0/upgrade-openacs.html item 6)
Successfully upgrades a vanilla 4.6.3 to 5.0.0 which passes the same quality tests as a native 5.0.0 site
Instructions are in standard documentation

Level 4
At least 10 reports of successful upgrades from 4.6.3 to 5.0 "in the field"

Level 5
At least 1 report of successful upgrade.

(Full list of criteria: https://openacs.org/projects/openacs/5.0/)

Collapse
Posted by Don Baccus on
At the moment we're facing upgrade difficulties that aren't entirely off our own making.

In particular OpenACS 5.0 requires some PG 7.3 features, but upgrading from PG 7.2->PG 7.3 introduces complexities which aren't, strictly speaking, "our problem".  Yet ... we need to support this upgrade path.

Even after this upgrade, there's constraint metadata in PG 7.3 that's missing in PG 7.2, which means in the future we can't necessarily rely on being able to do ALTER TABLE on an instance that's been migrated from PG 7.2->PG 7.3.  It may be possible to write an upgrade script to drop all referential integrity triggers (FOREIGN KEY constraints) and recreate them with ALTER TABLE but that won't happen for 5.0 and will never be automated (you'd only run such a script on  an instance you know was migrated from PG 7.2->7.3)

And Dirk Gomez reports that migrating from 8.1.7->9i requires FORTY-THREE manual steps!  (he is going to investigate whether or not an export/import cycle will suffice but since Oracle documents the manual steps, it may not).

Fortunately thus far the AOLserver and Tcl people have been kind enough not to f**k our world in such fashion ...

Anyway ... we need to address upgrade problems due to changes in our underlying platform as well as upgrade problems we bring upon ourselves, and our criteria probably needs to expose the fact that we run into such problems.

Collapse
Posted by Joel Aufrecht on

I don't understand what "our criteria probably needs to expose the fact that we run into such problems." means. Could you explain more?

I propose that our upgrade criterion not distinguish between work/risk caused directly by our code and work/risk caused by underlying platform changes necessitated by our code. If I have an OpenACS 4.6.1 site which I want to upgrade, I have certain set of problems which I _must_ fix in order to upgrade, regardless of their origin.

In other words, if there is a code change in 5.0 that requires a platform upgrade, the work of the platform upgrade should be counted against meeting our upgrade criterion. This will have the effect, I hope, of encouraging more backwards platform compatibility, which is more work for OpenACS developers but a Good Thing for users. We should also continue to address the "more work" part by providing more resources for developers along the lines of the test servers. That way, new code can be tested against older platform combos without requiring developers to maintain a full suite of old software.

Collapse
Posted by Jade Rubick on
I would vote for 3 and 4 for this release, and 1 in the future. I don't mind if it takes manual steps to update this release, but it would be nice not to have to in the future.
Collapse
Posted by Dirk Gomez on
An export and a subsequent import may cut it. Needs to be tested and of course we may run into funny problems (e.g. new reserved keywords :)

Is someone considering the move from Oracle 8i to 9i within the next few months?

Collapse
Posted by Dirk Gomez on
There also is a GUI-based "migration assistant" btw. 43 (and 4 optional) steps for the ones that want to do it on their own - it is also reported that the manual process is much faster.

Anyway, I want to try exp and imp.

Collapse
Posted by Barry Books on
I moved from 8i to 9i last month (as well as NT to Solaris). Export and Import did most of the work. I still had about 20 things to fix by hand. I also set 9i to use the 8i sql parser. Finally search the archives as there is a view fix you might need. You'll need to practice a few times. Also the performance of 8i and 9i is different. Be prepared to do some query tuning after you're done.
Collapse
Posted by Dirk Gomez on
Can you write that together Barry? We should have an "upgrade to Oracle 9i" section in the 5.0 docs.
Collapse
Posted by Andrei Popov on
As an idea for a cleaner upgrade (and borrowing from Oracle export/import comment) -- woul pg_dump data only and a restore into a *blank* data structure of 5.0 work?