-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
omego db upgrade #30
omego db upgrade #30
Conversation
In theory travis should currently fail due to the db change from 5.0.0 to 5.1-latest ( |
Thoughts:
|
|
Only one of the upgrades in TestUpgrade was working, the other just restarted the same server since the Python CLI module from the second upgraded server wasn't re-imported. I've changed this to only test a single upgrade with a breaking DB change, so Travis should really fail this time. |
I wanted them to be as unambiguous as possible
Implementing backups by running
I've already implemented |
The upgrade test on Travis passes on my fork (though it fails later because there are no tags, so there is no version defined): https://travis-ci.org/manics/omero-setup/builds/20954998 |
This now needs merging of |
Using plain Exception or nothing means pytest and Mox don't pick up errors.
Also made exception catches more specific
If the integration test times out (server download takes too long) you can still check whether the unit tests passed.
DB arguments may be common to both db and server admin commands
Also fixed the sorting of SQL versions in the new server
New flag added, --upgradedb, defaults to false
The latter should ensure psql never hangs whilst waiting for input if it can't connect
Ideally External should be a singleton due to the way it imports omero.cli. For now just pass the constructed object around if necessary
Also a couple of flake8 fixes
in case we're running unzip and it prompts for an ovewrite
I think this is ready for some testing. |
Atm I have problems with my old omego. I just do not get the linking between the OMERO-CURRENT and the folder with the unzipped server right.
Any ideas please ? |
Maybe some progress:
followed by the very long output (probably unpacking the server, no errors there)
But OMERO-CURRENT was magically created, see below:
|
To add to the confusion I'm not sure if ome/openmicroscopy#2184 was in your build, and whether it would affect things. When I tried this just now it seemed to work:
Can you try this again exeactly as before: delete everything and re-run. Also pass The plan is to have a proper |
Also |
Works fine for me. Thanks to @manics for explanation and handholding. Ready to merge. |
@manics: next steps? Merge this, tag, upload a new version of |
Originally I used the
psycopg2
python module to connect to Postgres (https://github.com/manics/omero-setup/compare/f42ba2d42f092e3e78930248a295285965816785), but this is an additional dependency which may require the postgres-devel package and a compiler. 8195422 changes this to use thepsql
binary instead. ThePGPASSWORD
envvar is used internally to pass the password topsql
. If DB backups are implemented thepg_dump
binary will need to be run anyway.omego db upgrade --dbhost host --dbname name --dbuser user --dbpass pass --serverdir path/to/server
omego db init --dbhost host --dbname name --dbuser user --dbpass pass --serverdir path/to/server
omego upgrade --dbhost host --dbname name --dbuser user --dbpass pass --upgradedb
OMERO4.4
toOMERO5.0
andOMERO5.0
toOMERO5.1DEV
should work.Note credentials aren't read from
config.xml
so if you've got multiple DBs ensure you pass the connection details.Current issues:
etc/config.xml
, or by callingbin/omero config get omero.db.xxx
omero db
instead? Or will we end up tying ourselves in knots?omego db upgrade --dry-run
tells you if an upgrade would be performed,omego upgrade --upgradedb --dry-run
doesn't