- 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. See Cells docs for more details.
- 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 provisioning: 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 - see the hypervisor feature matrix for details. Also, in the event one wishes (or needs) to customize the machine image being deployed, the diskimage-builder project on stackforge is recommended. See bare metal docs for more details.
- 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 optionally run in a mode where it has no direct access to the database. This improves Nova's security, though some concerns have been raised about the performance of this new mode.
- Quantum Security Groups Proxy: 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.
- VMware Driver Improvements: Several improvements were made to the VMware driver, including support for VNC consoles, iSCSI volumes, live migration, rescue mode, Quantum, and improved Glance integration (OVF support, better download performance).
- 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.
- Quotas for fixed IP addresses: It is now possible to set quotas for the allocation of fixed IP addreses (set quota_fixed_ips in nova.conf - default is unlimited)
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) replaced by signed tokens (using PKI - introduced in the Folsom release) are now default.
- 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.
- Pluggable authentication: The default 'password' and 'token' authentication modules are now pluggable (Identity API v3 only) and can be easily replaced with custom code, for example to authenticate with an existing system. Plugins can also make calls to the existing identity driver. Authentication at the HTTP API layer is also pluggable in Identity API v3; however, see Known Issues below.
- Non-default authentication plugins will not be loaded properly due to bug 1157515 (this does not affect custom password and token authentication plugins).
- 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
- keystone.conf [DEFAULT] admin_endpoint and public_endpoint configuration options are now available to configure the full URLs returned by self-referential links to keystone, even if it's deployed behind a proxy (neither option affects how keystone listens for connections). Both default to localhost and dynamically use the admin_port and public_port options.
OpenStack Network Service (Quantum)
Key New Features
- Metadata improvements
- simplified physical network configuration requirements, eliminating key deployment hurdle
- support for overlapping IP address ranges
- Multiple Network support for multiple network nodes running L3-agents and DHCP-agents
- provides better scale + high-available for quantum deployments.
- Security groups: allows L3-L4 packet filtering for security policies to protect virtual machines.
- Backward compatible with Nova-API
- Additional features not found in Nova:
- IPv6 and IPv4 support
- inbound + outbound filtering
- Overlapping IP address range support
- Can be offloaded by plugins to enhanced filtering engines rather than iptables
- Load-balancing-as-a-Service (LBaaS)
- full load balancing API model + pluggable framework
- basic implementation based on HAproxy
- Already working with leading vendors on additional plugins, expect support for more vendor load-balancer technologies in Havana
- New Plugins supported
- Big Switch Plugin
- Brocade Plugin
- Hyper-V Plugin
- Plum Grid Plugin
- Midonet Plugin
- Additional Improvements to Existing Plugins
- Nicira NVP Plugin: Quality-of-Service, L2-Gateways, Port-Security.
- Ryu: support for OVS tunneling.
- Seamless upgrade from Folsom to Grizzly
- Support for XML API.
- Horizon GUI support for Routers + Loadbalancers. Means Horizon now implements nearly all of the main Quantum features.
The root_helper config setting has been deprecated and should be updated/replaced with rootwrap_config in cinder.conf:
root_helper=sudo /usr/local/bin/cinder-rootwrap /etc/cinder/rootwrap.conf ----> rootwrap_config = /etc/cinder/rootwrap.conf
The osapi_volume_extension setting will need updated to find the new paths for Cinder API:
osapi_volume_extension = cinder.api.openstack.volume.contrib.standard_extensions -----> osapi_volume_extension = cinder.api.contrib.standard_extensions
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.