[almighty] How are we handling migrations at the moment ?

[Karanbir Singh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/09/16 08:39, Shoubhik Bose wrote:
> Hi,
> 
> I've changed the work item type fields to have an additional field 
> called "system.remote_item_id" which has a required=false ( in the 
> createCommon() method in migration/migration.go )
> 
> When the code gets merged to master, the existing work items would
> need to be altered. How would that be handled?

there have been a few conversations around this, so now is perhaps a
good time to formalise a process for us to start with[1]

version the db schema,

then its upto the core to workout what schema is presently deployed
and to run migrations on new migration availability - and then to set
suitable downtime/ expectation on the services ( ui for now ), during
this migration.[1]

And ideally, to also include a plan for post-deployment verification /
failforward.


Regards

[1]: We are working through db options and what, by way of
availability and migration options / snapshot backup options, we might
have there. In itself thats an open conversation right now, so we
should assume a static single instance db for core/api right now.
- -- 
Karanbir Singh, Project Lead, The CentOS Project, London, UK
Red Hat Ext. 8274455 | DID: 0044 207 009 4455
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJX5OEbAAoJEI3Oi2Mx7xbtRwoH/1HhSwqrU2E3LyOvGNsdoTzC
Pd7caXVYzCquaKKqUifvu/ztWfSA2J6/2uQw5qYeVpZjuJx8I+PWG00Wg1+5xcts
GNbjbuGsGzDdEptxugRlROf/hDrLY8POnu4EOdv5jJKGWRi0BJqRNDp7Ze9QGTy8
E0LyFv+WshVBXzIP34fsCAnpdtxv9OOkLPDCsJ/LQg3JWB7SzA7pGSAuzc6gd2gi
Q7db99wj7HU310kAW1I7FWa/bookLHbSMMJd1a2xh5kQ9JbE3jx1k5dN6zMbIgC4
v1LUuUaSXTcMUg0IdJeW86M13H48hhJ46C10RPJBxOk4XrYYmQ4lLupHuJiaesc=
=gQqn
-----END PGP SIGNATURE-----