42 lines
2.4 KiB
YAML
42 lines
2.4 KiB
YAML
---
|
|
prelude: |
|
|
The 15.0.0 release includes many new features and bug fixes. It is
|
|
difficult to cover all the changes that have been introduced. Please at
|
|
least read the upgrade section which describes the required actions to
|
|
upgrade your cloud from 14.0.0 (Newton) to 15.0.0 (Ocata).
|
|
|
|
That said, a few major changes are worth mentioning. This is not an
|
|
exhaustive list:
|
|
|
|
- The latest API microversion supported for Ocata is v2.42. Details on
|
|
REST API microversions added since the 14.0.0 Newton release can be found
|
|
in the `REST API Version History`_ page.
|
|
- The Nova FilterScheduler driver is now able to make scheduling
|
|
decisions based on the new Placement RESTful API endpoint that becomes
|
|
mandatory in Ocata. Accordingly, the compute nodes will
|
|
refuse to start if you do not amend the configuration to add the
|
|
``[placement]`` section so they can provide their resource usage.
|
|
For the moment, only CPU, RAM and disk resource usage are verified by
|
|
the Placement API, but we plan to add more resource classes in the
|
|
next release. You will find further details in the features and
|
|
upgrade sections below, and the `Placement API`_ page.
|
|
- Ocata contains a lot of new CellsV2 functions, but not all of it is
|
|
fully ready for production. All deployments must set up their existing
|
|
nodes as a cell, with database connection and MQ transport_url config
|
|
items matching that cell. In a subsequent release, additional cells
|
|
will be fully supported, as will a migration path for CellsV1 users.
|
|
By default, an Ocata deployment now needs to configure at least one new
|
|
"Cell V2" (not to be confused with the first version of cells). In
|
|
Newton, it was possible to deploy a single cell V2 and schedule on it
|
|
but this was optional. Now in Ocata, single CellsV2 deployments are
|
|
mandatory.
|
|
More details to be found when reading the release notes below.
|
|
- There is a new nova-status command that gives operators a better
|
|
view of their cloud. In particular, a new subcommand called "upgrade"
|
|
allows operators to run a pre-flight check on their deployment before
|
|
upgrading. This helps them to proactively identify potential upgrade
|
|
issues that could occur.
|
|
|
|
.. _REST API Version History: http://docs.openstack.org/developer/nova/api_microversion_history.html
|
|
.. _Placement API: http://docs.openstack.org/developer/nova/placement.html
|