Forum OpenACS Q&A: Response to Enhancing the Installation Process: Automation.
Posted by
Lee McKusick
on 08/31/00 07:03 AM
I really would like an OpenACS RPM and so far the difficulties mentioned that I understand are:
1. Installing direct to a /web partition where the disk space and file system is correct size and type is awkward.
2. Upgrading a Postgres data structure without a dump and reload is ... shall we call it beyond the state of the art for Postgres?
3. Upgrading TCL scripts, SQL scripts and in-production user introduced customizations is well... well hard?
I have a thought, this problem needs to be subdivided into smaller pieces. Now I am just thinking here... like a pizza, there are more ways to slice it than just one.
First; nsd, the java mail programs, and Postgres can be gathered up as RPMs.
The hard part is the OpenACS system has data structures, algorithms and user visible functions spread out.
Parts of OpenACS are specific to AOLServer 3.0. Other parts require TCL 7.6. Some important database functions will be solved differently when Postgresql changes to version 7.2
A data structure like "ecommerce.sql" and the hard work of offering that data correctly to users occurs in several different places, and so far I am mostly just grepping to get an idea of what happens.
So here is a proposal, maybe one way to organize OpenACS is to create a Postgres relational database and copy the entire OpenACS system into that data structure.
So, a select * from modules where version = "3.2.2" ; would regenerate the entire OpenACS 3.2.2 system.
The idea is to store OpenACS in a series of relational tables. The list of queries we wish to run against these tables will drive the design of the table data structure.
So the RPM or tarball or whatever of OpenACS has these parts:
1. A front end script.
2. A dumpfile or a complete database.
3. Dependency stuff for Postgresql RPMs etc.
So, what sort of queries would this database respond to?
1. Output the documentation for installation, for any module, for any item, table, screen, transaction. Search every comment in every file. A one line title for every paragraph. FAQ's, OpenACS installation tables.
2. Output all the tables and screens for any version.
3. Output the changed parts between versions for any module.
4. Do a diff on a production system against any reference version.
5. Give OpenACS users an elegant way to contribute all the pieces of a new module back to OpenACS without driving Ben Adida crazy.
That means we need a gadget to Parse files in a production system and complain about missing documentation, missing comments. And finally, import the diff of the production system into the database.
6. We need to pick a good way to label each file with the dependencies on specific versions of TCL, Postgresql, and nsd that are now embedded implicitly in the big version number for the entire OpenACS suite of files.
A production installation needs lots of help working through the hassles of sticking with an old reliable executable while adding new functionality from later OpenACS releases.
7. My OpenACS system, the whole caboodle of 3.2.2 plus AOLServer 3.0 is 4 gigs, very roughly.
1. Installing direct to a /web partition where the disk space and file system is correct size and type is awkward.
2. Upgrading a Postgres data structure without a dump and reload is ... shall we call it beyond the state of the art for Postgres?
3. Upgrading TCL scripts, SQL scripts and in-production user introduced customizations is well... well hard?
I have a thought, this problem needs to be subdivided into smaller pieces. Now I am just thinking here... like a pizza, there are more ways to slice it than just one.
First; nsd, the java mail programs, and Postgres can be gathered up as RPMs.
The hard part is the OpenACS system has data structures, algorithms and user visible functions spread out.
Parts of OpenACS are specific to AOLServer 3.0. Other parts require TCL 7.6. Some important database functions will be solved differently when Postgresql changes to version 7.2
A data structure like "ecommerce.sql" and the hard work of offering that data correctly to users occurs in several different places, and so far I am mostly just grepping to get an idea of what happens.
So here is a proposal, maybe one way to organize OpenACS is to create a Postgres relational database and copy the entire OpenACS system into that data structure.
So, a select * from modules where version = "3.2.2" ; would regenerate the entire OpenACS 3.2.2 system.
The idea is to store OpenACS in a series of relational tables. The list of queries we wish to run against these tables will drive the design of the table data structure.
So the RPM or tarball or whatever of OpenACS has these parts:
1. A front end script.
2. A dumpfile or a complete database.
3. Dependency stuff for Postgresql RPMs etc.
So, what sort of queries would this database respond to?
1. Output the documentation for installation, for any module, for any item, table, screen, transaction. Search every comment in every file. A one line title for every paragraph. FAQ's, OpenACS installation tables.
2. Output all the tables and screens for any version.
3. Output the changed parts between versions for any module.
4. Do a diff on a production system against any reference version.
5. Give OpenACS users an elegant way to contribute all the pieces of a new module back to OpenACS without driving Ben Adida crazy.
That means we need a gadget to Parse files in a production system and complain about missing documentation, missing comments. And finally, import the diff of the production system into the database.
6. We need to pick a good way to label each file with the dependencies on specific versions of TCL, Postgresql, and nsd that are now embedded implicitly in the big version number for the entire OpenACS suite of files.
A production installation needs lots of help working through the hassles of sticking with an old reliable executable while adding new functionality from later OpenACS releases.
7. My OpenACS system, the whole caboodle of 3.2.2 plus AOLServer 3.0 is 4 gigs, very roughly.
