Script to import routines and globals into a new instance of OpenVista
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenVista/GT.M Integration |
Fix Released
|
Medium
|
Jon Tai |
Bug Description
The ovinstanceadd utility creates a new, empty OpenVista instance, but we need to import routines and globals into it for it to be useful. There are a variety of formats an OpenVista instance can come in - routines can be in %RO or individual-files format, for example. They can be zipped up, or already unpacked. The import utility, ovimport, should be as flexible as possible (perhaps providing differnt flags) and automatically do the right thing to get routines and globals loaded.
ovimport should warn (and possibly abort?) if the target instance already has routines and/or globals in it. If run as root, ovimport may have a flag that would cause it to wipe out existing routines and database files before importing new routines/globals.
After importing routines, they should be compiled.
If we decide to make packages of OpenVista Server itself (like kernel-source packages, they would just install zip files to /usr/src or similar) we may want to provide some kind of integration between ovimport and the OpenVista Server packages so a user could select which OpenVista Server release to import.
Related branches
Changed in openvista-gtm-integration: | |
assignee: | nobody → jontai |
importance: | Undecided → Medium |
milestone: | none → phase-1 |
Changed in openvista-gtm-integration: | |
status: | Fix Committed → Fix Released |
First revision has been committed - supports a %RO-format file or a directory of loose routines for routine import, supports a %GO-format file or a ZWR-format file for global import. Routines are recompiled after import. Journaling is temporarily disabled during the global import to improve performance. ovimport checks to see if an OpenVista instance is empty before importing, and supports proposed -f flag.
Still to do: support compressed files; play nicely with packages of OpenVista server in the future.
At this point, I'm going to put this up for review/merging; the remaining items will have to be handled in separate branches in the future.