- 1 OpenStack 2013.1 (Grizzly) Release Notes
- 1.1 General Upgrade Notes
- 1.2 OpenStack Object Storage (Swift)
- 1.3 OpenStack Compute (Nova)
- 1.4 OpenStack Image Service (Glance)
- 1.5 OpenStack Dashboard (Horizon)
- 1.6 OpenStack Identity (Keystone)
- 1.7 OpenStack Network Service (Quantum)
- 1.8 OpenStack Block Storage (Cinder)
- 2 Known packaged distributions
OpenStack 2013.1 (Grizzly) Release Notes
NOTE: Grizzly is due to be released on April 4th. This page is work in progress.
General Upgrade Notes
- Many projects have had their service launching scripts (e.g. nova-api) or their admin CLIs (e.g. keystone-manage) ported from optparse to argparse. This has lead to some minor incompatibilities in the arguments accepted by commands. For example, in glance you can no longer do glance-manage db_sync --config-file=... but must instead do glance-manage --config-file=... db_sync because the option is for the top-level command rather than the sub-command.
- Maybe projects have had their default loglevel changed to WARNING. Use verbose=True to change the loglevel to INFO (the previous default) and debug=True to change the loglevel to DEBUG. See bug #989269
OpenStack Object Storage (Swift)
Key New Features
OpenStack Compute (Nova)
Key New Features
- Cells: Grizzly will include a preview (experimental) release of cells functionality. Cells provides a new way to scale nova deployments, including the ability to have compute clusters (cells) in different geographic locations all under the same nova API.
- Availability Zones: Availability Zone support has been enhanced. Previously, the only way to set the availability zone for a given compute node was via its configuration file. You can now set a node's availability zone via the API.
- Admin APIs: There have been multiple additions to the API for administrative actions. This has been done to continue to move away from needing the nova-manage utility for most administrative tasks.
- API support for instance passwords: This enhancement to nova improves support for instances that require passwords to work, such as those running Windows. Instances can now generate and post an encrypted password to the metadata API (write once). This password can be retrieved via the public nova API. This functionality can be integrated with a guest initialization tool such as cloud-init.
- Bare metal instances: Grizzly includes a new hypervisor driver than can deploy machine images to bare metal, allowing tasks to run with no virtualisation overhead. This is supported but not fully featured - for instance, only Debian (and derived) Linux images are supported so far.
- Improved MySQL connector performance: Some enhancements have been made to allow better interaction with MySQL and the threading model used by nova (eventlet).
- Database archiving: Support for pruning deleted items and placing them in separate tables to keep the most frequently written tables from growing without bounds.
- Instance Action Tracking: Nova has been updated to keep track of all actions performed on an instance. There is an API extension for accessing this information. Viewing the list of instance actions provides deeper insight into the history of an instance. It also provides much better error reporting for users and administrators.
- No-DB-Compute: The nova-compute service can now run in a mode where it has no direct access to the database. This improves Nova's security.
- Quantum Security Groups: When managing security groups through Nova's API, all actions will be proxied to Quantum when Quantum is the network provider.
- File injection without mounting guest filesystem: Nova has the ability to use libguestfs to support file injection into a guest filesystem. Previously this was done by mounting the guest filesystem on the host. This has been refactored to use libguestfs APIs that do not require mounting the guest filesystem, which is much more secure.
- Default Security Group Rules: Nova can now be made to add rules to the default security group when it is created for a tenant.
- libvirt Custom Hardware: The libvirt driver in Nova will now check for properties on an image that specify specific hardware types that should be used. An example of when this is useful is for an image that does not support virtio, and should use a fully virtualized hardware type instead.
- libvirt Spice Console: The libvirt driver in Nova now supports Spice virtual consoles.
- powervm Resize, Migrate, and Snapshot: The powervm driver in Nova now supports the resize, migrate and snapshot operations.
- Unique Instance Naming: When issuing an API command to create multiple servers, Nova will now give each instance a unique name based on a configured template. Previously all instances would have the same name.
- Availability Zones in OpenStack API: Support for availability zones has been enhanced in the OpenStack API. You can now list availability zones through the API. The availability zone for an instance is also included in instance details.
- Glance Direct Image File Copy: If Glance provides Nova a URL to the image location on a shared filesystem, Nova will now get the image content from there instead of through the Glance API. This will result in faster instance boot times under some circumstances.
- Boot without image: It is now possible to boot a volume-backed instance without specifying an image, if block-device-mapping is passed to the nova boot command.
- Quota-instance-resource: It is now possible to set accurate quota for CPU, disk IO, and network interface bandwidth(duo to a bug bandwidth Qos can't works) of an instance. By using this feature, you can provide a consistent amount of CPU capacity no matter what the actual underlying hardware.
- Network adapter hot-plug: It is now possible to hot-plug a pre created port to a running instance.
OpenStack Image Service (Glance)
Key New Features
OpenStack Dashboard (Horizon)
Key New Features
OpenStack Identity (Keystone)
The term "tenant" is now known as "project." Both terms may be used interchangeably during this release, but "tenants" are specifically exposed by the legacy Identity API v2.0, and "projects" are exposed by the Identity API v3.
Key New Features
- PKI Tokens: Traditional tokens (simple UUIDs) have been replaced by signed tokens (using PKI) capable of being validated offline.
- New API: Support for Identity API v3 which is deployed identically on both port 5000 and 35357 by default.
- User groups: manage role assignments for groups of users (managed on Identity API v3, affects both APIs).
- Domains: a high-level container for projects, users and groups providing namespace isolation and an additional level of role management (managed on Identity API v3, affects both APIs).
- Trusts: Project-specific role delegation between users, with optional impersonation (Identity API v3 only).
- Credentials: generic credential storage per user (e.g. EC2, PKI, SSH, etc.) (Identity API v3 only)
- Policies: a centralized repository for arbitrary policy engine rule sets (Identity API v3 only).
- Token values no longer appear in URLs (Identity API v3 only).
- RBAC: policy.json controls are enforced for all Identity API v3 calls.
- A default domain is created automatically by keystone-manage db_sync; any existing users and tenants are migrated into this domain and Identity API v2.0 calls assume this domain as context. Entities created outside of the default domain are not accessible via the v2.0 API. The default domain may not be deleted through the API, although which domain is considered the "default" is configurable via default_domain_id in keystone.conf.
- Member role: Users with a default tenant_id attribute or any relationship to an existing tenant are granted a new role that is automatically created by keystone-manage db_sync. After this migration, the default tenant_id attribute (v2.0) and default_project_id user attributes no longer grant any actual authorization, and are instead treated as a user-specified preference. The name and ID of the member role are configurable via member_role_id and member_role_name in keystone.conf. The default values (9fe2ff9ee4384b1894a90878d3e92bab and _member_, respectively) are intended to avoid conflicts with existing deployments.
- keystone.conf [token] default_format = <UUID | PKI> defines whether UUID or PKI tokens are generated. PKI is the default, and requires keystone-manage pki_setup to be run, or existing certificates to be installed.
- keystone.middleware.auth_token is deprecated and has been moved to keystoneclient.middleware.auth_token. This means you no longer need to install keystone on a node where you only need authentication middleware. Pipeline configuration of services which consume auth_token must be revised to refer to keystoneclient instead of keystone.
- keystone.middleware.swift_auth has been removed it has been moved in havana to Swift you will need to update the paste stanza for keystoneauth from the filter_factory to egg:swift#keystoneauth
OpenStack Network Service (Quantum)
Key New Features
OpenStack Block Storage (Cinder)
Key New Features
|Feature||Supported in v1||Supported in v2|
|List Bootable Volumes||yes||yes|
|Filter volumes by attributes||yes||yes|
|Filter volumes by metadata||yes||yes|
|Filter snapshot by attributes||yes||yes|
|Filter snapshot by metadata||yes||yes|
|Update volume metadata||yes||yes|
|Update snapshot metadata||yes||yes|
- API extension folder moves from cinder/api/openstack/volume/contrib to cinder/api/contrib
Cinder API v2
- List volumes/snapshots summary actually is a summary view. In v1 it was the same as detail view.
- List volumes/snapshots detail and summary has display_name key changed to name.
- List volumes/snapshots detail and summary has display_description key changed to description.