#459: current prod dump doesn't work with current master
------------------------+---------------------------------------------------
Reporter: jblayloc | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: *general* | Version:
Resolution: | Keywords:
------------------------+---------------------------------------------------
Comment (by simko):
1) It should not be generally assumed that one is able to take DB
snapshot of an Invenio instance running //master// branch as of
YYYY-MM-DD-1 and deploy it on an Invenio instance running master
branch as of YYYY-MM-DD-2. Because master branch is where the
bleeding-edge feature development happens, it can contain numerous
changes (possibly even back-and-forth) between any two given commits
as far as the DB structure and setup goes.
The benefit of making a generic upgrade script between any two given
commit points on the //master// branch would not be so huge, because
the master branch is usually deployed on non-production sites only,
and developers maintaining such sites can upgrade things using their
inner knowledge of commit logs and following `update-vX.Y.Z-tables`
statement instructions from the main `Makefile.am`. (Though these may
theoretically change in a back-and-forth manner over time, as I
mentioned above, it rarely actually happens due to the pull-on-demand
QA review model; but still, the difference of how the same
`update-vX.Y.Z-tables` target looked between any two given commit
points must actually be inferred from `git diff`.) I consider this to
be a price to pay for using the master branch; but for developers it
is not so high a price.
2) However, what you describe is exactly how things work for the
//maint// release series branches, where people can usually deploy new
updates without worries, because APIs and DB structure is kept
consistent within a given release series branch between any two given
commit points. (If not, people will run `make update-v0.99.2-tables`
after deployment.) So it should be rather safe to take a YYYY-MM-DD-1
DB snapshot of some release series branch and deploy it using
YYYY-MM-DD-2 sources of the same branch. Though one may still need to
run `update-vX.Y.Z-tables` statements between two point releases.
Here, making a generic upgrade script between any two given commit
points on any given release branch, not relying on
`update-vX.Y.Z-tables` between point releases, may be beneficial. We
have actually been planning to transform `make update-v0.99.2-tables`
statements into `inveniocfg --upgrade-X-to-Y` statements, but it did
not happen yet. Here, `X` could be not only `v0.99.2` but also
`v0.99.2-36-g237ae6e`, say, which would give exactly what you
describe. Though a simple setup where `X` denotes only point releases
may still be sufficient, probably.
3) In the concrete case of using an INSPIRE PROD DB dump that you
mention, what a PROD DB dump offers when compared to a new INSPIRE
master branch vanilla installation is mainly the metadata. So it
should be enough to take only the `bib*` and `idx*` and `rnk*` parts
from PROD (roughly speaking) and deploy these on that new vanilla
instance. (In this case followed by author index re-indexing, since
we have altered the author index nature between the two commits, see
the inspire-dev discussion about Campbell-Wilson diffs on PROD/TEST.)
Such a selective import of selected PROD tables should also achieve
what you were looking for, I think. We port bibliographic part of
PROD sites to DEV sites from time to time just like that.
Concerning the attached example of resetting actions and roles, it
should not be necessary: (i) you probably missed to execute firerole's
`repair_role_definitions()` from the `update-vX.Y.Z-tables`
instructions, see also my merge commit log note in
5e7ab76014eb0774658074a6ed439aa04fa244ed; (ii) adding new paper
claiming actions and roles could have been done by calling
`webaccessadmin -u admin -a -c`. Anyway, you can as well wait until
PROD's master tip is advanced, as we are musing about it on
`inspire-dev`, and then you will be able to install the new DB
snapshot in full. (An alternative to taking just a few interesting
tables like bib/idx/rnk ones, as mused about in the previous
paragraph.)
--
Ticket URL: <http://invenio-software.org/ticket/459#comment:1>
Invenio <http://invenio-software.org>
