Jump to: navigation, search

Difference between revisions of "ReleaseNotes/Bexar"

Line 1: Line 1:
__NOTOC__
 
 
= Release Notes, Bexar =
 
= Release Notes, Bexar =
  
 
The Bexar release introduces large file support for OpenStack Object Storage (Swift), the OpenStack Image registry and Delivery service (Glance) and a lot of new features in OpenStack Compute (Nova).
 
The Bexar release introduces large file support for OpenStack Object Storage (Swift), the OpenStack Image registry and Delivery service (Glance) and a lot of new features in OpenStack Compute (Nova).
 
<<[[TableOfContents]]()>>
 
  
 
== New Features ==
 
== New Features ==
Line 17: Line 14:
 
=== [[OpenStack]] Compute (Nova) ===
 
=== [[OpenStack]] Compute (Nova) ===
 
* Support for raw disk images with libvirt and XenAPI hypervisors, without the complexity of a separate ramdisk or kernel image.
 
* Support for raw disk images with libvirt and XenAPI hypervisors, without the complexity of a separate ramdisk or kernel image.
* IPv6 support in all network modes but [[FlatManager]]. Use the new use_ipv6 flag, and refer to [[BexarIpv6supportReadme]] for more information.
+
* IPv6 support in all network modes but FlatManager. Use the new use_ipv6 flag, and refer to [[BexarIpv6supportReadme]] for more information.
 
* Support for a lot of new volume backends to provide highly available block volumes for VMs: Sheepdog, CEPH/RADOS, and iSCSI (XenAPI only)
 
* Support for a lot of new volume backends to provide highly available block volumes for VMs: Sheepdog, CEPH/RADOS, and iSCSI (XenAPI only)
 
* Microsoft Hyper-V support. Refer to [[HypervInstall]] for information.
 
* Microsoft Hyper-V support. Refer to [[HypervInstall]] for information.
Line 26: Line 23:
 
* Database versioning and migration support, for painless migration from one version to another
 
* Database versioning and migration support, for painless migration from one version to another
 
* Instances now use copy-on-write by default for better performance (you can use the use_cow_images flag to control that)
 
* Instances now use copy-on-write by default for better performance (you can use the use_cow_images flag to control that)
* Support for availability zones, through the introduction of a new scheduler: [[ZoneScheduler]]
+
* Support for availability zones, through the introduction of a new scheduler: ZoneScheduler
 
* A DirectAPI, using introspection to exhibit features, is now available for developers to control Nova locally
 
* A DirectAPI, using introspection to exhibit features, is now available for developers to control Nova locally
 
* Some features that were partly implemented in the Austin release got finalized in Bexar: IP allocation was moved down the chain, project VPNs are supported and Nova now fully supports iptables-driven security groups.
 
* Some features that were partly implemented in the Austin release got finalized in Bexar: IP allocation was moved down the chain, project VPNs are supported and Nova now fully supports iptables-driven security groups.
Line 50: Line 47:
  
 
=== Nova ===
 
=== Nova ===
* IPv6 is not supported in [[FlatManager]] network mode.
+
* IPv6 is not supported in FlatManager network mode.
 
* You can't upload images to the [[S3ImageService]] (objectstore) from the Openstack API (only Glance is supported), see Bug 709355
 
* You can't upload images to the [[S3ImageService]] (objectstore) from the Openstack API (only Glance is supported), see Bug 709355
* You can't use FlatDHCPManager network mode on a multiple machines deployment without using multiple interfaces (Bug 710959). Recommended mode of operation for deploying Nova on multiple machines is to use VLAN-supporting managed switches with [[VlanManager]] network mode.
+
* You can't use FlatDHCPManager network mode on a multiple machines deployment without using multiple interfaces (Bug 710959). Recommended mode of operation for deploying Nova on multiple machines is to use VLAN-supporting managed switches with VlanManager network mode.
 
* When a compute node dies, its instances may still be reported as running (Bug 661214)
 
* When a compute node dies, its instances may still be reported as running (Bug 661214)
 
* When a VM dies, a compute node won't realize until it's restarted (Bug 661260)
 
* When a VM dies, a compute node won't realize until it's restarted (Bug 661260)

Revision as of 23:57, 16 February 2013

Release Notes, Bexar

The Bexar release introduces large file support for OpenStack Object Storage (Swift), the OpenStack Image registry and Delivery service (Glance) and a lot of new features in OpenStack Compute (Nova).

New Features

OpenStack Object Storage (Swift)

  • Large objects (greater than 5 GB) can now be downloaded using OpenStack Object Storage. While there is still a limit on the size of a single uploaded object, with this release the download size of a single object is virtually unlimited with the concept of segmentation. Refer to Managing Large Objects for more information.
  • An experimental S3 compatibility middleware has been added to OpenStack Object Storage. This middleware intercepts S3 style requests and authorization, and transforms them into swift requests.
  • Initial i18n support for logging messages.
  • Swauth is a swift compatible authentication and authorization service implemented on top of swift as wsgi middleware. This will replace the dev_auth service in a future release.
  • Advanced rate limiting middleware

OpenStack Compute (Nova)

  • Support for raw disk images with libvirt and XenAPI hypervisors, without the complexity of a separate ramdisk or kernel image.
  • IPv6 support in all network modes but FlatManager. Use the new use_ipv6 flag, and refer to BexarIpv6supportReadme for more information.
  • Support for a lot of new volume backends to provide highly available block volumes for VMs: Sheepdog, CEPH/RADOS, and iSCSI (XenAPI only)
  • Microsoft Hyper-V support. Refer to HypervInstall for information.
  • Lots of new features have been added around the Openstack API, for example admin features to pause, suspend, lock and password reset instances, but also support for per-instance diagnostics.
  • New "rescue" mode allowing an instance to mount affected disks and fix problems (see rescue_image_id, rescue_kernel_id and rescue_ramdisk_id flags)
  • Web-based serial console to access instances where networking fails (requires instances with serial console enabled). This is available through the Openstack API or the new euca-get-ajax-console tool (and introduces a new nova-ajax-console-proxy type of node)
  • Possibility to do hardware staging: new added services can be specifically load-tested before being made generally available to cloud users (administered by the nova-manage service commands)
  • Database versioning and migration support, for painless migration from one version to another
  • Instances now use copy-on-write by default for better performance (you can use the use_cow_images flag to control that)
  • Support for availability zones, through the introduction of a new scheduler: ZoneScheduler
  • A DirectAPI, using introspection to exhibit features, is now available for developers to control Nova locally
  • Some features that were partly implemented in the Austin release got finalized in Bexar: IP allocation was moved down the chain, project VPNs are supported and Nova now fully supports iptables-driven security groups.
  • Finally, lots of efforts were spent unifying the code around common standards for using the new Glance clients, for i18n, logging, service handling (through eventlet), or using paste.deploy for the API nodes.

OpenStack Image Registry and Delivery service (Glance)

  • Glance APIs (for registry and delivery) were unified, and a specific client class created
  • Support for uploading disk images directly through the glance REST-ful API
  • Addition of the glance-upload tool which can register new AMI-like images or raw disk images
  • Glance can now fetch image data on a S3-like backend.
  • Documentation for Glance is now available at http://glance.openstack.org
  • The dependency on Twisted was removed. Glance now uses only Eventlet for its server-side internals.

Others

There were also deliveries outside those core projects during the Bexar development timeframe, in particular:

  • The OpenStack Dashboard, a reference implementation of a web-based console for OpenStack Compute projects is now available. Refer to OpenStackDashboard for more information.
  • A deployment tool to deploy Nova on multiple servers. Refer to NovaInstall/NovaDeploymentTool for more information.
  • An official documentation site at http://docs.openstack.org, containing PDF and HTML versions of manuals plus the capability for user notes on each page.

Known Issues and Limitations

Nova

  • IPv6 is not supported in FlatManager network mode.
  • You can't upload images to the S3ImageService (objectstore) from the Openstack API (only Glance is supported), see Bug 709355
  • You can't use FlatDHCPManager network mode on a multiple machines deployment without using multiple interfaces (Bug 710959). Recommended mode of operation for deploying Nova on multiple machines is to use VLAN-supporting managed switches with VlanManager network mode.
  • When a compute node dies, its instances may still be reported as running (Bug 661214)
  • When a VM dies, a compute node won't realize until it's restarted (Bug 661260)
  • Using "setup.py install" does not produce a complete setup (Bugs 683137 and 727794)
  • When using XenAPI, the compute node doesn't clean up if a vm fails to spawn (Bug 694935) or if it loses its xapi session (Bug 692994)
  • nova-network may fail to start if iptables entries were flushed and a floating IP address is assigned (Bug 711948). You can use the workaround in the bug.

Glance

  • The S3 and Swift backends do not currently support the POST /images/ API command in the Glance API. These backends only currently support fetching disk images via GET calls. Support for storing disk images in S3 and Swift directly through the Glance API is planned for the Cactus release
  • There is a bug in the Swift backend that is preventing new-style account:user:key URIs from being used (Bug 717431)
  • Some errors/exceptions returned via from the reference registry server implementation (glance-registry) are being improperly consumed by the glance-api server (Bug 704854)

Blueprints implemented during the Bexar release

Bugs fixed during the Bexar release