7b097f016b
The upgrade path logic was built to force a developer pattern to break things such as new tables and features across multiple patches, and the status check *can* explicitly fail if we don't explicitly go hint to it that we've added table. Yes, we have a hard coded list... Anyway, a better pattern is allow the db sync process to do the appropriate needful. Run the status check, if it fails, fallback and update the schema. Also handles the explicit failure error and tries to return a human friendly error message for when the table is not present. In the end this allows us to merge schema changes such as additional tables with their underlying objects and properly handle things as long as the schema update works as expected. This allows us to leverage an operational model of performing upgrades. Change-Id: Id5f2a8068bc064e1ed1e376524850e4739f79ef2 |
||
|---|---|---|
| .. | ||
| from-queens | ||
| resources.sh | ||
| settings | ||
| shutdown.sh | ||
| upgrade.sh | ||