You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Added a `nova-manage db online_data_migrations` command for forcing online data migrations, which will run all registered migrations for the release, instead of there being a separate command for each logical data migration. Operators need to make sure all data is migrated before upgrading to the next release, and the new command provides a unified interface for doing it.
290
+
- Added a ``nova-manage db online_data_migrations`` command for forcing online data migrations, which will run all registered migrations for the release, instead of there being a separate command for each logical data migration. Operators need to make sure all data is migrated before upgrading to the next release, and the new command provides a unified interface for doing it.
- The old top-level resource `/os-migrations` is deprecated, it won't be extended anymore. And migration_type for /os-migrations, also add ref link to the /servers/{uuid}/migrations/{id} for it when the migration is an in-progress live-migration. This has been added in microversion 2.23.
627
+
- The old top-level resource ``/os-migrations`` is deprecated, it won't be extended anymore. And migration_type for /os-migrations, also add ref link to the /servers/{uuid}/migrations/{id} for it when the migration is an in-progress live-migration. This has been added in microversion 2.23.
- A new nova-manage command has been added which will upgrade a deployment to cells v2. Running the command will setup a single cell containing the existing hosts and instances. No data or instances will be moved during this operation, but new data will be added to the nova_api database. New instances booted after this point will be placed into the cell. Please note that this does not mean that cells v2 is fully functional at this time, but this is a significant part of the effort to get there. The new command is "nova-manage cell_v2 simple_cell_setup --transport_url <transport_url>" where transport_url is the connection information for the current message queue used by Nova. Operators must create a new database for cell0 before running `cell_v2 simple_cell_setup`. The simple cell setup command expects the name of the cell0 database to be `<main database name>_cell0` as it will create a cell mapping for cell0 based on the main database connection, sync the cell0 database, and associate existing hosts and instances with the single cell.
682
+
- A new nova-manage command has been added which will upgrade a deployment to cells v2.
683
+
Running the command will setup a single cell containing the existing hosts and instances.
684
+
No data or instances will be moved during this operation, but new data will be added to the nova_api database.
685
+
New instances booted after this point will be placed into the cell.
686
+
Please note that this does not mean that cells v2 is fully functional at this time, but this is a significant part of the effort to get there.
687
+
The new command is "nova-manage cell_v2 simple_cell_setup --transport_url <transport_url>" where transport_url is the connection information
688
+
for the current message queue used by Nova. Operators must create a new database for cell0 before running ``cell_v2 simple_cell_setup``.
689
+
The simple cell setup command expects the name of the cell0 database to be ``<main database name>_cell0`` as it will create a cell mapping
690
+
for cell0 based on the main database connection, sync the cell0 database, and associate existing hosts and instances with the single cell.
- The newton release has a lot of online migrations that must be performed before you will be able to upgrade to ocata. Please take extra note of this fact and budget time to run these online migrations before you plan to upgrade to ocata. These migrations can be run without downtime with `nova-manage db online_data_migrations`.
814
+
- The newton release has a lot of online migrations that must be performed before you will be able to upgrade to ocata.
815
+
Please take extra note of this fact and budget time to run these online migrations before you plan to upgrade to ocata.
816
+
These migrations can be run without downtime with ``nova-manage db online_data_migrations``.
- The deprecated auth parameter `admin_auth_token` was removed from the [ironic] config option group. The use of `admin_auth_token` is insecure compared to the use of a proper username/password.
827
+
- The deprecated auth parameter ``admin_auth_token`` was removed from the [ironic] config option group.
828
+
The use of ``admin_auth_token`` is insecure compared to the use of a proper username/password.
- The 'live_migration_flag' and 'block_migration_flag' options in libvirt section that were deprecated in Mitaka have been completely removed in Newton, because nova automatically sets correct migration flags. New config options has been added to retain possibility to turn tunnelling, auto-converge and post-copy on/off, respectively named `live_migration_tunnelled`, `live_migration_permit_auto_converge` and `live_migration_permit_post_copy`.
870
+
- The 'live_migration_flag' and 'block_migration_flag' options in libvirt section that were deprecated in Mitaka have been completely
871
+
removed in Newton, because nova automatically sets correct migration flags. New config options has been added to retain possibility
872
+
to turn tunnelling, auto-converge and post-copy on/off, respectively named ``live_migration_tunnelled``,
873
+
``live_migration_permit_auto_converge`` and ``live_migration_permit_post_copy``.
- Legacy v2 API code is already removed. A set of policy rules in the policy.json, which are only used by legacy v2 API, are removed. Both v2.1 API and v2.1 compatible mode API are using same set of new policy rules which are with prefix `os_compute_api`.
889
+
- Legacy v2 API code is already removed. A set of policy rules in the policy.json, which are only used by legacy v2 API, are removed.
890
+
Both v2.1 API and v2.1 compatible mode API are using same set of new policy rules which are with prefix ``os_compute_api``.
- The auth parameters `admin_username`, `admin_password`, `admin_tenant_name` and `admin_url` of the [ironic] config option group are now deprecated and will be removed in a future release. Using these parameters will log a warning. Please use `username`, `password`, `project_id` (or `project_name`) and `auth_url` instead. If you are using Keystone v3 API, please note that the name uniqueness for project and user only holds inside the same hierarchy level, so you must also specify domain information for user (i.e. `user_domain_id` or `user_domain_name`) and for project, if you are using `project_name` (i.e. `project_domain_id` or `project_domain_name`).
1001
+
- The auth parameters ``admin_username``, ``admin_password``, ``admin_tenant_name`` and ``admin_url`` of the [ironic] config option group
1002
+
are now deprecated and will be removed in a future release. Using these parameters will log a warning.
1003
+
Please use ``username``, ``password``, ``project_id`` (or ``project_name``) and ``auth_url`` instead.
1004
+
If you are using Keystone v3 API, please note that the name uniqueness for project and user only holds inside the same hierarchy level,
1005
+
so you must also specify domain information for user (i.e. ``user_domain_id`` or ``user_domain_name``) and for project,
1006
+
if you are using ``project_name`` (i.e. ``project_domain_id`` or ``project_domain_name``).
0 commit comments