Project: glance Series: cactus Blueprint: api-image-format Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-image-format Spec URL: None Images can be a variety of formats (OVF, AMI, etc). We should store the format for the image in the main images registry table and process an `x-image-meta-format` HTTP header. Project: nova Series: cactus Blueprint: authentication-consistency Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/authentication-consistency Spec URL: None Currently there are different credentials for the OpenStack API and the EC2 API. An end-user must therefore know whether an application they are using uses the OpenStack API or the EC2 API under the hood, and must choose the correct set of credentials. This should be fixed: there should be one set of credentials, and it should be the EC2 credentials to minimize impact. Project: nova Series: cactus Blueprint: bexar-nova-containers Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/bexar-nova-containers Spec URL: http://wiki.openstack.org/BexarLXCContainers LXC is a leading technology for containers running on modern Linux distributions. This spec deals how we add LXC containers to nova. Project: nova Series: cactus Blueprint: cactus-flatmanager-ipv6-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/cactus-flatmanager-ipv6-support Spec URL: http://wiki.openstack.org/FlatManagerIPv6Support In Bexar release, IPv6 feature does not support FlatManager. We add FlatManager IPv6 support with libvirt. Project: nova Series: cactus Blueprint: cactus-glance-instance-monitor Design: Obsolete Lifecycle: Complete Impl: Deferred Link: https://blueprints.launchpad.net/nova/+spec/cactus-glance-instance-monitor Spec URL: http://etherpad.openstack.org/nova-instance-monitor-glance nova-instance-monitor has been updated to store its usage graph images using glance instead of the nova-objectstore. Project: nova Series: cactus Blueprint: cactus-migration-live Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/cactus-migration-live Spec URL: http://wiki.openstack.org/LiveMigration Support migration (moving running VMs from one physical node to another) without shutting down the cloud server. Project: nova Series: cactus Blueprint: cactus-stability Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/cactus-stability Spec URL: None The Cactus release is all about stability. As such, all code should aim to be cleaner, simpler and more testable. This is an umbrella blueprint for these changes. Project: glance Series: cactus Blueprint: cli-tool Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/cli-tool Spec URL: None Create a tool for interacting with a Glance API node and registry from the command line Project: nova Series: cactus Blueprint: configure-instance-types-dynamically Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/configure-instance-types-dynamically Spec URL: http://wiki.openstack.org/ConfigureInstanceTypesDynamically Nova administrators should be able to create their own INSTANCE_TYPES (standard cpu, memory, storage configs such as m1.medium in the EC2 API) without resorting to hacking the source code. Ideally, there should be an option in nova-manage which would allow INSTANCE_TYPES to added or deleted in the nova DB. Project: nova Series: cactus Blueprint: filedriver Design: Obsolete Lifecycle: Complete Impl: Deferred Link: https://blueprints.launchpad.net/nova/+spec/filedriver Spec URL: http://wiki.openstack.org/FileDriverSpec implementation of a file base volume driver to manage images created by qemu-img for example on a mounted NFS export Project: nova Series: cactus Blueprint: flavors Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/flavors Spec URL: http://wiki.openstack.org/Flavors Different workloads will have different requirements for server resources. This blueprint will allow the creation of certain flavors that package Virtual CPU, disk space, and RAM to meet the unique requirements of different workloads. These may be presented ala carte or as fixed packages. Project: glance Series: cactus Blueprint: functional-tests Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/functional-tests Spec URL: None We need a comprehensive functional testing tool that: * Starts glance-api and glance-registry, daemonized * Fire curl against both the glance-api node and the glance-registry node, noting returned results and failures * Stop glance-api and glance-registry Project: nova Series: cactus Blueprint: hypervisor-vmware-vsphere-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/hypervisor-vmware-vsphere-support Spec URL: http://wiki.openstack.org/VMware-vSphere-support Support VMware vSphere as compute provider. Project: glance Series: cactus Blueprint: image-checksumming Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/image-checksumming Spec URL: None Supply a method for caller to verify the received image Project: nova Series: cactus Blueprint: injection Design: Obsolete Lifecycle: Complete Impl: Started Link: https://blueprints.launchpad.net/nova/+spec/injection Spec URL: http://wiki.openstack.org/InjectionSpec Should be possible to define the injection of (at the moment ssh keys and network configuration) per image with nova-manage. Project: glance Series: cactus Blueprint: logging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/logging Spec URL: None Log for both glance-api and glance-registry. Add facilities for logging and place lots more descriptive debugging/info messages into glance binaries' logs Project: nova Series: cactus Blueprint: multi-cluster-in-a-region Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/multi-cluster-in-a-region Spec URL: http://wiki.openstack.org/MultiClusterZones We need the ability to deploy multiple clusters of servers within a region that can be controlled by a single api endpoint. A Nova deployment is called a Zone. Multiple Zones may be linked in such a way as to enforce the http://wiki.openstack.org/BasicDesignTenets of Nova. A zone may be connected to many child zones. Child zones know nothing of their parents. Therefore a child zone may have many parents. Related to this blueprint is Distributed Scheduler. This will provide load balancing and Server-Best-Match algorithms so that Server Instances may be distributed across many Zones. This blueprint was broken down into four branches (all merged into Cactus): Zones1: Defining parent-child zone data structure and client/cmdline tools (novaclient) for managing zones and their relationships. Zones2: Introduces the ZoneManager into the Scheduler Service. This polls child zones for their name and capabilities. Zones3: Services within a Zone can now broadcast back to all Scheduler services their current status (dynamic capabilities/load/etc) Zones4: Requests of OpenStack API Server are forwarded to child zones if the current zone cannot fulfill the request. Missing in this release: - servers.get/pause/unp ause/diagnostics/suspend/resume/rescue/unrescue/delete operations supported (OS API only) - Distributed Scheduler is slated for diablo. - Servers.get_all() operation is not currently supported. May get added as a bug fix. - Distributed Image/Flavors/Private_IP, etc operations are not supported ... unclear if they need be. Project: nova Series: cactus Blueprint: multi-nic Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/multi-nic Spec URL: http://wiki.openstack.org/multi-nic Support for more than one NIC per instance. Rackspace requires two nic's minimum (1 public, 1 private), but this should be abstracted to support N NIC's. Currently Nova assumes 1 NIC. Changes will need to propagate to guest. Project: nova Series: cactus Blueprint: multi-tenant-accounting Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/multi-tenant-accounting Spec URL: http://wiki.openstack.org/openstack-accounting As a cloud computing platform, OpenStack must support the concept of multi-tenancy. A common approach to organizing resources by 'tenant' across services is needed to be able to correlate usage tracking, auditing, authorization, etc... And within each multi-tenant service, the ability to identify each tenant's resources (for various reasons such as security, accounting, isolation, etc…) is also key. However, the definition of a 'tenant' will vary by operator and by deployment. This blueprint therefore proposes creating a lightweight standard for service developers to implement tenancy and resource grouping without a-priori knowledge of billing and accounting processes specific to the operator of an OpenStack deployment. Project: nova Series: cactus Blueprint: multinic-libvirt Design: Drafting Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/multinic-libvirt Spec URL: http://wiki.openstack.org/multinic-libvirt Support for multiple network interface per instance for libvirt. Currently, implementation of https://blueprints.launchpad.net/nova/+spec/multi-nic will affect only Xen. So we need support for libvirt. Project: glance Series: cactus Blueprint: non-static-versioning Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/non-static-versioning Spec URL: None Use a versions.py file for managing versions instead of having to maintain versions in each of the bin/* programs, setup.py, and doc/source/conf.py Project: nova Series: cactus Blueprint: openstack-api-1-1 Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/openstack-api-1-1 Spec URL: http://wiki.openstack.org/OpenStackAPI_1-1 The OpenStack API version 1.1 will support a few new features as well as bring parity between the OpenStack Compute API and Rackspace Cloud Servers API. New features in the OpenStack API 1.1 include IPv6 support, migration to the OpenStack namespace, and support for API extensions. IPv6 support is a requirement for large scale deployments of openstack. Migration to the OpenStack namespace is a requirement of the OpenStack project so that the primary API is not branded with Rackspace. API Extensions will allow developers to innovate more quickly than the core API is updated by providing a method for developers to add extensions to their local installation ahead of the code being accepted by the OpenStack community as a whole. This should stimulate additional features for the core of OpenStack as extensions can be promoted into the core API after their initial implementation as an extension. Project: nova Series: cactus Blueprint: openstack-api-metadata Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/openstack-api-metadata Spec URL: http://etherpad.openstack.org/openstack-api-metadata Support the ability to store and retrieve metadata associated with Servers via the Openstack API. See http://docs.rackspacecloud.com/servers/api/v1.0/cs- devguide-20110112.pdf (page 23). From the API spec: "Custom cloud server metadata can also be supplied at launch time. This metadata is stored in the API system where it is retrievable by querying the API for server status. The maximum size of the metadata key and value is each 255 bytes and the maximum number of key-value pairs that can be supplied per server is 5" Project: nova Series: cactus Blueprint: openstack-api-server-passwords Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/openstack-api-server-passwords Spec URL: http://etherpad.openstack.org/openstack-api-server-passwords Generate a password that will be injected into server instances when using the Openstack API. From the Cloud Servers 1.0 API: A password will be randomly generated for you and returned in the response object. For security reasons, it will not be returned in subsequent GET calls against a given server ID. Project: glance Series: cactus Blueprint: paste-deploy Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/paste-deploy Spec URL: None Use Paste.Deploy for configuration of WSGI server programs (bin /glance-api and bin/glance-registry) Project: glance Series: cactus Blueprint: registry-db-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/registry-db-migration Spec URL: None This is absolutely critical to get completed *before* the work on image-format blueprint is done... Project: glance Series: cactus Blueprint: remove-upper-db-abstraction Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/remove-upper-db-abstraction Spec URL: None It's been agreed to remove the abstraction layer above SQLAlchemy and use SQLAlchemy to its full extent within the reference registry server implementation. This means complete removal of the code in /glance/common/db.py and the "pushing up" of the code in /glance/registry/db/sqlalchemy/* to /glance/registry/db/* Project: nova Series: cactus Blueprint: support-hp-san Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/support-hp-san Spec URL: None We should support HP/LeftHand networks SAN hardware for volumes. Project: nova Series: cactus Blueprint: unified-images Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/unified-images Spec URL: http://wiki.openstack.org/UnifiedImages Allow Nova to build instances directly from VHDs, with the customer data and kernel in one image. XS-Snapshots are already created as VHDs; this blueprint will allow Nova to boot the snapshots. Project: glance Series: cactus Blueprint: use-config-parser Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/use-config-parser Spec URL: None Now that use-optparse is in Cactus, we need to add back the configuration file processing. Of course, we'll be using the standard ConfigParser module instead of the non-standard gflags flagfile. This should be done before paste.deploy to make the paste.deploy branch easier... Project: glance Series: cactus Blueprint: use-optparse Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/use-optparse Spec URL: None Remove all use of gflags from Glance. Use optparse and ConfigParser like Swift does. One less dependency, one less non-standard library. Project: nova Series: cactus Blueprint: wsgi-mapper Design: Obsolete Lifecycle: Complete Impl: Deferred Link: https://blueprints.launchpad.net/nova/+spec/wsgi-mapper Spec URL: http://wiki.openstack.org/spec-wsgi-mapper Create a mapper akin to paste.urlmap, but that handles our needs a bit better (regex routes, verb awareness). Project: nova Series: cactus Blueprint: xenapi-basic-network-injection Design: Review Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-basic-network-injection Spec URL: None The libvirt connection has the facility to inject network configuration into a new instance by modifying files. The same feature needs to be implemented for the XenAPI backend. It should also support Windows network configuration via XenServer tools. This blueprint does not cover live reconfiguration of network settings in running VMs. Project: nova Series: cactus Blueprint: xenapi-vlan-network-manager Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-vlan-network-manager Spec URL: http://wiki.openstack.org/XenapiVlanNetworking The XenAPI backed will provide support for the vlan network manager in the same way as this support is currently provided by the libvirt backend. In a nutshell: - network node configuration is not going to change - compute node configuration will be performed using XenAPI calls Project: nova Series: cactus Blueprint: xs-fileinject Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-fileinject Spec URL: http://wiki.openstack.org/XenServerFileInjection The ability to inject (pass files) into a virtual machine at creation time. Project: nova Series: cactus Blueprint: xs-inject-networking Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-inject-networking Spec URL: http://wiki.openstack.org/xs-inject-networking We need to be able to inject networking information to the xenstore for the agent to pick up and configure networking. In addition this will write xenstore message to reset networking. Depends on live xenstore blueprint https://blueprints.launchpad.net/nova/+spec/xs- xenstore Project: nova Series: cactus Blueprint: xs-ipv6 Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-ipv6 Spec URL: http://wiki.openstack.org/XenServerIPv6 Create interface templates / file injections for adding IPv6 addresses and routes to XenServer instances. Project: nova Series: cactus Blueprint: xs-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-migration Spec URL: http://wiki.openstack.org/XenServerMigrations The ability to move an instance to a new host. The source instance is torn down after the move is confirmed successful. This is not intended to be a live migration implementation as other functionality is dependent on this feature. Project: nova Series: cactus Blueprint: xs-network-qos Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-network-qos Spec URL: http://wiki.openstack.org/XenServerNetworkQoS Adds the ability to set networking bandwidth capacity limits for each instance. Capacity limits are set based on the bandwidth settings set in flavors. Project: nova Series: cactus Blueprint: xs-rescue Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-rescue Spec URL: http://wiki.openstack.org/XenServerRescue The ability to boot from a rescue image and mount the original virtual machine's disk as a secondary block device. System could have a standard rescue image or use the same base image and the instance being rescued. Project: nova Series: cactus Blueprint: xs-resize Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-resize Spec URL: http://wiki.openstack.org/xs-resize The ability to resize a running XenServer instance's disk, cpu and ram to a larger or smaller size. Project: nova Series: cactus Blueprint: xs-vm-instance-params Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-vm-instance-params Spec URL: http://wiki.openstack.org/XenServerVMInstanceParameters Track Linux vs. Windows XS VM Instance Parameters