Divided the keystone docs into four categories, depending
upon the usage criteria: general information (which will
be common for all), developer documentation,
user documantation and operator documentation.
Change-Id: I2f5dd41acd9874739accc54c4f4fd69460b58334
The current implementation of db_sync --expand automatically runs any
outstanding legacy operations to ensure it's safety. However, that
behavior also means that legacy migrations may violate the safety
assumptions around --expand.
This is only true for Mitaka to Newton upgrades, as there should not be
any newer migrations in the legacy repository to be triggered by this
behavior.
[1] 0ebd557325/keystone/common/sql/upgrades.py (L269-L271)
Change-Id: Ib175f7fce96011d77eb4783123cb2d265d60aa42
Closes-Bug: 1676925
This patch fixes a bug and causes a log message along with an exit
code to be returned when a DBMigration error is raised.
Change-Id: Iba7aff606937561ad98e2ef551ca4005bd4f337d
Closes-Bug: #1663627
This patch adds a new command to the db_sync upgrade commands. --check
will check the current state of the users upgrade repos and relay info
back to the user based on what version each command is currently at and
if the user has any outstanding db_sync commands left to run. It will
also notify the user if the db_sync commands were not upgraded in order
Closes-Bug: 1642212
Change-Id: I79d3640a780d624f14059fe311fafa0542c03357
The openstack.org pages now support https and our references to
the site should by default be one signed by the organization.
Change-Id: I30a462e03d1fd7852511e22cac34c6bc0e8917f4
The new keystone upgrade features (keystone-manage db_sync --expand)
requires for MySQL deployments that the keystone user is granted SUPER
privilege or that set global log_bin_trust function_creators=1; is run.
Adding a warning message to notify reader.
Change-Id: I78738a335d14c6ad824c348a7385bb1ee8ad75bf
Closes-Bug: 1638368
Trivial fix for the following:
/home/ericwb/keystone/doc/source/upgrading.rst:115: WARNING:
Enumerated list ends without a blank line; unexpected unindent.
Partial-Bug: #1602422
Change-Id: Ia1e65267440df6dd43e7b5fe47f86f871a13975d
For clustered Keystone nodes it's possible to optimize the upgrade
process to minimize downtime. Additionally a process to quickly restore
after a failed upgrade are described.
Change-Id: I746d46a968dd887b0559644f91ae207055146390
This documentation conflicts a bit with the approach originally proposed
in bp manage-migration because it depends on the notion of having
database triggers to assist in the migration process.
Change-Id: Iec9269ab6d799b757451cb8afe7fa889fe7068b9
Rolling upgrades are being introduced in the Newton release, which will
substantially impact the process that deployers will have to follow to
upgrade keystone.
This will provide us a basis for documenting rolling upgrades (also,
it's about time we documented our current process).
bp manage-migration
Change-Id: I5a37c781b83967b12cda60b054c612df3c3cb697
Samriddhi Jain