7am PST / 4pm CET
Note we're using Zoom now:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/737202874
Or iPhone one-tap :
US: +16699006833,,737202874# or +14086380968,,737202874#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 408 638 0968 or +1 646 876 9923
Meeting ID: 737 202 874
International numbers available: https://zoom.us/zoomconference?m=F0kj5u6u0wFxr7Xfz5NKZxl0xyLhuTPF
Time | Item | Who | Notes |
---|---|---|---|
10m | Agenda and action item review | Josh Zamor | Open Action item review from https://openlmis.atlassian.net/wiki/x/vAAND Open action items from last time:
|
Database migration speed? | Chongsun Ahn (Unlicensed) | ||
Migration testing? Integration? Job? | Chongsun Ahn (Unlicensed) | ||
(didn't get to) | Cross-service migration | Chongsun Ahn (Unlicensed) |
|
While testing latest code against production data for release testing, we found that fulfillment service wasn't starting in a short amount of time - the service was starting, but stuck in a long migration script.
This was because updates to schema / copying data was on a table which had 7+ million rows. Through a bit of digging uncovered this recommendation: https://dba.stackexchange.com/questions/52517/best-way-to-populate-a-new-column-in-a-large-table/52531#52531 . Which recommends duplicating the table, making the changes to the duplicate, and then replacing the old table with the new.
Question: How do we ensure that when we're writing migrations, we're avoiding writing migrations that take hours?
We do know with our implementations that some hours of downtime are:
Prefer a mix of 1 and 2.
Where do we get the data for item #1? For things like PoD line items that has a lot of data, we should commit to making performance data.
Action Items:
Current approach is to use a jenkins job that:
We also have experimented with a pattern of writing integration tests for individual migrations.
Some concerns with it:
Some concerns with the current approach:
Josh asks: Central to any migration testing approach is having and loading data. In the past I've used DbUnit to setup the database before test, and revert it to pre-test condition after the test has run. Is this tool (or one like it) still valuable?