Project: nova Series: diablo Blueprint: add-options-network-create-os-apis Design: Pending Approval Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/add-options-network-create-os-apis Spec URL: http://wiki.openstack.org/add-options-network-create-os-apis Our goal is to add optional parameter to the Create server API to achieve following objectives:- 1) Specify number and order of networks to the create server API. In the current implementation every instance you launch for a project having 3 networks assigned to it will always have 3 vnics for every instance. In this case it is not possible to have one instance with 2 vnics ,another with 1 vnic and so on. This is not flexible enough and the network resources are not used effectively. So there should be some provision given to the users to specify the networks from the project at the time of server creation process. 2) Support fixed IP address reservation. When you launch a server, you can specify the fixed IP address you want to be assigned to the vnic from a particular network. This feature will be supported to all of the network models. Project: nova Series: diablo Blueprint: add-remove-securitygroup-instance Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/add-remove-securitygroup-instance Spec URL: None Add OS APIs as an extension to associate/disassociate security group to/from instances. Project: horizon Series: diablo Blueprint: admin-instancetypes Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/admin-instancetypes Spec URL: None Django-nova now allows modifying instance types (flavors) directly through the admin interface. Project: nova Series: diablo Blueprint: admin-server-actions Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/admin-server-actions Spec URL: http://wiki.openstack.org/NovaAdminServerAPI Certain actions to be taken on servers are reserved for administrator access, such as suspending them. This blueprint defines those actions. Project: nova Series: diablo Blueprint: agent-update Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/agent-update Spec URL: http://wiki.openstack.org/AgentUpdate The agent should be updated on a newly created instance before it is used. This will ensure that it is running the latest and most stable code. Project: glance Series: diablo Blueprint: api-limited-results Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-limited-results Spec URL: None Support the limit and paging of results to GET /images and GET /images/detail Project: glance Series: diablo Blueprint: api-results-filtering Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-results-filtering Spec URL: http://wiki.openstack.org/GlanceImageFilter Allow callers to pass in query args to filter results of the GET /images and GET /images/detail calls. Allow the following query args: disk_format, appliance_format, name, status, size Project: glance Series: diablo Blueprint: api-results-ordering Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-results-ordering Spec URL: None The collections returned by calls to /images and /images/detail should be able to be ordered by a subset of the image model attributes. Ascending and descending sort directions should both be supported. Project: glance Series: diablo Blueprint: api-versioning Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-versioning Spec URL: http://etherpad.openstack.org/GlanceApi Support versioning of the Glance API Project: keystone Series: diablo Blueprint: auth-using-global-token Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/auth-using-global-token Spec URL: None Current Working 1. User does an authenticate call with his set of credentials without specifying a tenant id. 2. User gets a response that includes Token (ie: Token not tied to any tenant.I am calling this Unscoped Token), service catalog(The catalog would just have keystone listed as a service=> needs confirmation from Ziad.) and the list of roles (roles not tied to any specific tenant). 3. User uses the token and makes the get tenants call. 4. User gets a response that lists all the tenants for which a role relationship exists between the user and a tenant. 5. User again does an authenticate call using his credentials and also specifies any one of the tenants. 1=> User has to use his credentials again. 6. User gets the response that includes a service catalog that is tenant specific and a token that a user could use against the mentioned endpoints. Proposed Working 1. User does an authenticate call with his set of credentials without specifying a tenant id. 2. User gets a response that includes Token (ie: Token not tied to any tenant.I am calling this Unscoped Token), service catalog(The catalog would just have keystone listed as a service) and the list of roles (roles not tied to any specific tenant). 3. User uses the token and makes the get tenants call. 4. User gets a response that lists all the tenants for which a role relationship exists between the user and a tenant. 5. User again does an authenticate call using his unscoped token and also specifies any one of the tenants. => User doesn't have to use his credentials again. 6. User gets the response that includes a service catalog that is tenant specific and a token that a user could use against the mentioned endpoints. Project: glance Series: diablo Blueprint: authentication Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/authentication Spec URL: None Support Keystone Authentication layer, via in-process middleware and remote auth middleware. Project: nova Series: diablo Blueprint: backup-with-rotate Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/backup-with-rotate Spec URL: None A common usage of image snapshots is to take a backup; it would be useful to combine this with a rotation function that would automatically delete the oldest images of a server, retaining the N most recent. So, this would be a very simple extension that would snapshot a particular server, then remove the oldest snapshots of the same server ID, keeping the N (user-specified) most recent. Project: keystone Series: diablo Blueprint: backward-compatibility Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/backward-compatibility Spec URL: http://docs.rackspacecloud.com/files/api/v1/cfdevguide_d5/content/ch03s01.html Support existing client functionality including GET /v1.0 to get a token and returning URLs to clients so they know where to go to get their data. We're proposing the following as an approach: 1. Auth 1.0/1.1 compatible calls will be implemented as a WSGI component on Keystone 2. The BaseURLs will be translated to X-Storage-URL (and other 1.0 compatible headers) using settings in a conf file for the WSGI component. 3. Authorization (token generation, etc...) will be performed by the core 2.0 API and routed to it by the WSGI layer (i.e. no duplication of token generation code within WSGI component) 4. Auth 1.0 and 1.1 compatibility will be released for the public API only to support existing tooling. 5. We will rename folders in Keystone to the following: auth_protocols will changed to `middleware` and will host middleware for use with other services. backends will be created for back-end components (sqlite, ldap, etc...) frontends will be added and will host frontends for Keystone (including the Auth 1.0/1.1 WSGI component) Project: nova Series: diablo Blueprint: boot-from-volume Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/boot-from-volume Spec URL: http://wiki.openstack.org/BootFromVolume BootFromVolume VMs should be able to boot from a volume. This requires the volume API in the OS API. Project: glance Series: diablo Blueprint: changes-since-filter Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/changes-since-filter Spec URL: None Allow a special filter called "changes-since" that will allow a client like an RSS reader to supply the last time the same GET request was made. Have the changes-since filter introduce a WHERE updated_at > $changes_since_value. Project: nova Series: diablo Blueprint: clone-volume Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/clone-volume Spec URL: http://wiki.openstack.org/CloneVolume With this feature, we can create lots of same volumes from one golden snapshot, which is useful for hosting companies. This blueprint adds support for "--snapshot" option of euca-create-volume, and enable us to create a new volume from a existing snapshot volume. Project: nova Series: diablo Blueprint: compute-host-system-architecture-awareness Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/compute-host-system-architecture-awareness Spec URL: None Currently an assumption is made that the computer host(s) can run the image architecture. This works well if the compute host can run the architecture, such as the host being amd64 - which can run i386 additionally ... Or the host being i386 and all the images coincidently being the same. As other architectures become more important, ARM and PowerPC for example. There should be a notion of compute node capabilities. This blueprint tries to address the first pass of supporting i386 and amd64 capabilities, allowing the scheduler to select the best node for the instance based on architecture. Project: nova Series: diablo Blueprint: configuration-drive Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/configuration-drive Spec URL: http://etherpad.openstack.org/clouddrive This proposal is to configure each VM with an additional small disk image that is formatted with a ISO9660, FAT32 or some other easily readable file system that can be mounted by all or most modern operating systems. The disk would be mountable by the hypervisor to write configuration data and files that the guest could then read or execute. Initially, we would write metadata to to the drive that the guest could use to configure itself or provide a reference point in case of misconfiguration. The drive could also be the landing point for files that are injected to the instance at boot time. Project: horizon Series: diablo Blueprint: dash-security-groups Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/dash-security-groups Spec URL: None For most real-world deployments, it will be necessary to allow users the ability to manage security groups. This is especially true with the current nova implementation, which denies all instance traffic by default. This blueprint proposes adding the ability to create, list, modify, and delete security groups to the dashboard. It also proposes adding the ability to display security groups for instances, as well as the ability to launch instances in security groups. Project: glance Series: diablo Blueprint: delayed-delete Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/delayed-delete Spec URL: None Allow delaying the actual deletion of an image. If glance-api.conf has delayed_delete set to False or not set at all (it defaults to False) immediatly delete the image. If delayed_delete is set to True glance-api sets the status to pending_delete but does not call the backend delete. From the user's point of view it is actually deleted, and future calls will 404. A new daemon glance-scrubber is introduced which looks for pending_delete images that are older than a configurable interval and will actually delete from the backend the images. Project: glance Series: diablo Blueprint: delete-image Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/glance/+spec/delete-image Spec URL: None I'm told that Glance does not currently have the ability to delete an image. While trivial, this needs to be supported, and it needs to have a REST API (DELETE to /images/{id}) to support it. Use cases: (1) Service provider needs to automatically delete old images after a time. (2) User needs to delete a snapshot/backup image when no longer needed. (3) Developer needs to remove a bad image from the repository. Project: nova Series: diablo Blueprint: diablo-generic-messaging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/diablo-generic-messaging Spec URL: http://wiki.openstack.org/GenericMessagingSystem Implement a generic messaging driver for Nova that allows any messaging system to be used in place of RabbitMQ. Rabbit can still be used if desired. See spec URL for more details. Project: nova Series: diablo Blueprint: different-schedulers-per-call Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/different-schedulers-per-call Spec URL: None The Scheduler code naively assumes that there is one scheduler that will work for both run_instances and create_volume. This won't work in a lot of situations. We should allow for specifying a different scheduler for each call that needs to be scheduled. Project: nova Series: diablo Blueprint: disk-scrubbing Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/disk-scrubbing Spec URL: http://wiki.openstack.org/DiskScrubbing Data on disk space associated with a deleted server will be explicitly scrubbed (overwritten or deleted) before the disk space is allocated to a new customer. Project: nova Series: diablo Blueprint: distributed-scheduler Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/distributed-scheduler Spec URL: http://wiki.openstack.org/DistributedScheduler The current default scheduler and data model (simple abstraction with a SQLAlchemy backend) works fine for small to medium sized local installations, but we need to discuss plans for large installations, possibly spanning multiple data centers. See the specification URL for more details and discussion. Project: nova Series: diablo Blueprint: distros-net-injection Design: Obsolete Lifecycle: Complete Impl: Not started Link: https://blueprints.launchpad.net/nova/+spec/distros-net-injection Spec URL: None Support for net and key injection for different Linux distros. We need different template and file path for each distro. And need ability to determine distro. Project: nova Series: diablo Blueprint: error-codes Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/error-codes Spec URL: http://wiki.openstack.org/StandardizedErrorCodes Top level exceptions should include a standardized set of error codes in addition to the normal exception data (stack trace, exception type, etc.) This is to ease customer support by permitting the customer to state "I'm getting a X1234 error when I try to start my server". We need to grab all the Exxx codes from Slicehost as a starting place. We need to catch all top-level exceptions and write them to a rabbit queue with these new codes (and the logger). Project: horizon Series: diablo Blueprint: expand-openstackapi-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/expand-openstackapi-support Spec URL: None OpenstackAPI supports some functionality that didn't exist in EC2, and we should support those things. Project: nova Series: diablo Blueprint: explicit-vm-mode Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/explicit-vm-mode Spec URL: None Currently for Xen, there is a complex process of deciding if an instance should be run in PV or HVM mode. In practice, setting the os_type to 'windows' is commonly used, even if the OS being run is not Windows. Project: horizon Series: diablo Blueprint: extensibility Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/extensibility Spec URL: None As openstack grows, we will have additional modules that need control: volumes, lbaas, dns, queue, ... Additionally extensions to core components can require additional UI. Just as nova allows extensions, we should allow people to add new "top" or "side" components Project: nova Series: diablo Blueprint: finalize-nova-auth Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/finalize-nova-auth Spec URL: None This is a placeholder spec for finalizing the integration between nova and the auth service. For this to be completed we need: 1) No more project/role/user info in nova 2) Replication of existing authz features in in either keystone or separate authz service 3) Migration plan for old data into keystone/authz Project: horizon Series: diablo Blueprint: floating-ips-interface Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/floating-ips-interface Spec URL: None Currently the Openstack Dashboard does not provide an interface to associate floating IPs with tenants and instances. This blueprint proposes adding an interface for users to manage floating IPs in a manner similar to how Amazon EC2's interface works. In addition this blueprint proposes adding an interface for the admin syspanel which will give system administrators an idea of how floating IPs are being used throughout the network. This means displaying a list of floating IPs and providing detail on their relationships to tenants and instances. The API for floating ips has already been implemented here: http://wiki.openstack.org/os_api_floating_ip Some things that may need to be addressed in the interface are things like: - Quotas Project: glance Series: diablo Blueprint: glance-cli-filters Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/glance-cli-filters Spec URL: None Have bin/glance support new results filters and ordering. Currently, only glance.client supports these. Would be great to have the glance CLI tool also support them. Remember to updated the docs, too! Project: glance Series: diablo Blueprint: glance-coverage Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/glance-coverage Spec URL: None Implement the coverage reporting for Glance as it is in Burrow. Get unit test coverage up above 90%. Project: glance Series: diablo Blueprint: glance-dashboard Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/glance/+spec/glance-dashboard Spec URL: None A web interface for the Glance project. The console will utilize the Glance API to present and query information about the registry and image store. Project: glance Series: diablo Blueprint: glance-notifications Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/glance-notifications Spec URL: https://blueprints.launchpad.net/nova/+spec/notification-system Rackspace needs the ability to maintain event notifications (and add to them) for parity with our existing features. Such a notification system has been implemented for Nova, and the same thing should be implemented for Glance. I'm merely linking to the existing Nova blueprint since the goal is to have them feature identical. The REST API endpoint is /images/{id}/events (cf. /servers/{id}/events) Project: nova Series: diablo Blueprint: ha-flatdhcp Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/ha-flatdhcp Spec URL: None Our current approach for HA networking is hot failover of the network- host because everything uses nova-network as a gateway. While this should ultimately be fixed by the nova-network additions, there is the possibility of a small set of changes that would give us a lot more redundancy. This involves a new network manager that is similar to FlatDHCP with two additional features. 1. Instead of nova-network functioning as the gateway for all of the hosts, we will use a switch as the gateway. This means either delegating dhcp requests from the switch to nova-network or setting an external gateway in the config options for dnsmasq. Forwarding rules will have to be manually created on the gateway to allow metadata to work 2. Instead of natting on nova-network, natting rules for floating ips will be created on the compute hosts themselves. These changes will mean that losing nova-network will not affect networking for running instances. Project: glance Series: diablo Blueprint: i18n Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/i18n Spec URL: None Implement i18n support for Glance Project: keystone Series: diablo Blueprint: identity-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/identity-api Spec URL: https://github.com/openstack/keystone/blob/master/keystone/content/admin/identityadminguide.pdf?raw=true Spec for identity API. This continues support for the Rackspace Auth protocol version (1.x) and moves it to the OpenStack namespace at version 2.0. Project: nova Series: diablo Blueprint: implement-network-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/implement-network-api Spec URL: http://wiki.openstack.org/QuantumNetworkManager Create a new instance of NetworkManager that will work with the rest of nova using the existing interface but make calls to Quantum instead of manipulating the bridge field in the Nova DB networks table (integration with Melange is planned, but is only a stretch goal for Diablo-4). Project: nova Series: diablo Blueprint: implement-volume-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/implement-volume-api Spec URL: None The volume service must implement a REST API. This will allow openstack API clients to create and destroy volumes and ultimately allow the existing volume code to be replaced by a more robust service in the future. Project: horizon Series: diablo Blueprint: improve-template Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/improve-template Spec URL: None Improve the look and feel of the site and update the base templates and CSS to be more modern. Project: horizon Series: diablo Blueprint: improve-unit-tests Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/improve-unit-tests Spec URL: None Unit test coverage improved. Project: nova Series: diablo Blueprint: instance-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/instance-migration Spec URL: http://wiki.openstack.org/InstanceMigration Develop a feature to allow cloud administrators to perform maintenance tasks of physical servers. This feature will allow admins to shutdown an instance and move it to a new host node. Project: horizon Series: diablo Blueprint: instance-snapshots-interface Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/instance-snapshots-interface Spec URL: None Many cloud users require the ability to snapshot instance states for both application management and backup purposes. This capability presently exists in the compute.api, so it is straightforward to adapt this functionality for the dashboard. This blueprint proposes adding the ability to create snapshots of any running instance through the dashboard. The resulting images would be visible in a special dashboard view, where they could subsequently be deleted, launched, and (possibly) edited. Project: nova Series: diablo Blueprint: integrate-network-services Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/integrate-network-services Spec URL: None Integration of Melange, Donabe & Quantum services into Nova. Project: nova Series: diablo Blueprint: integrate-nova-authn Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/integrate-nova-authn Spec URL: http://wiki.openstack.org/openstack-authn Keystone provides a common auth framework for all of the services. This blueprint is for the initial integration of the keystone service (described below) with nova. The first version will be a very non- invasive approach with a couple of middlewares. The purpose of this blueprint is to define a standard for authentication in OpenStack that enables services to support multiple authentication protocols in a pluggable manner. By providing support for authentication via pluggable authentication components, this standard allows OpenStack services to be integrated easily into existing deployment environments. It also provides a path by which to implement support for emerging authentication standards such as OpenID. The standard is not an authentication system onto itself, but rather a protocol by which authentication systems may be integrated with OpenStack services. Project: glance Series: diablo Blueprint: iso-boot Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/iso-boot Spec URL: https://blueprints.launchpad.net/nova/+spec/iso-boot Introduce 'iso' DISK_FORMAT type. This provides metadata that signals to Nova compute that the image should be attached with a CDROM block device rather than as a read/write harddisk. Project: nova Series: diablo Blueprint: key-management Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/key-management Spec URL: None The Openstack API needs functionality to manage key-pairs equivalent to the following in the EC2 API: boto.connect_ec2 - get_all_key_pairs - create_key_pair - delete_key_pair Project: horizon Series: diablo Blueprint: keystone-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/keystone-support Spec URL: None Added support for keystone as an authentication backend. This allows full integration with nova, swift, and other OpenStack services that share this common authentication method. Project: nova Series: diablo Blueprint: kvm-block-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/kvm-block-migration Spec URL: http://etherpad.openstack.org/kvm-block-migration Support KVM block migration feature as a part of live migration support. Project: nova Series: diablo Blueprint: kvm-pause-suspend Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/kvm-pause-suspend Spec URL: http://wiki.openstack.org/Kvm-Pause-Suspend Enabling KVM to pausing instance and suspending instance. The difference between "pause" and "suspend" is that "Suspend stores the state of VM on disk while pause stores it in memory (RAM)". In other word, suspend is similar to "hybernation". Project: nova Series: diablo Blueprint: ldapdriver-add-attributes Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/ldapdriver-add-attributes Spec URL: None Currently the ldap driver acts as the owner of a director server. In many deployments this may not be the case. The ldap driver should be configurable to add objectclasses and attributes instead of adding users. Ideally, when the ldap driver sees a user exists, it should check to see if the objectclass and attribute exist. If the neither exist, it should add them, if the objectclass exists, and the attributes do not, it should add the attributes. The use case behind this is a directory server that is already populated with users, and is managed by other means. The directory server admin can add ACIs to allow the update of objectclasses and the nova attributes, or just to the nova attributes. Project: nova Series: diablo Blueprint: libvirt-refactoring Design: Obsolete Lifecycle: Complete Impl: Deferred Link: https://blueprints.launchpad.net/nova/+spec/libvirt-refactoring Spec URL: http://wiki.openstack.org/LibvirtAPI The current method for connecting to a libvirt-based hypervisor, through nova/virt/libvirt_conn.py, is functional but is lacking support for a number of great libvirt features. Some of the items we are missing are optimizations and others are simply new features that we could provide to the world if we take a step back and look at the design of the LibvirtConnection class. I'd love feedback publicly and/or privately for the attached wiki page outlining potential improvements for connecting to libvirt. Project: nova Series: diablo Blueprint: linuxnet-vif-plugging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/linuxnet-vif-plugging Spec URL: http://wiki.openstack.org/LinuxnetVifPlugging In Diablo-3 we introduced "vif-plugging" to the hypervisor "virt" layer, allowing flexibility in how vNICs are attached to the network switch. This allowed non-linux bridge switch technologies (e.g., Open vSwitch, 802.1qbh) to be used with nova. This blueprint adds that same capability to the Linuxnet, allowing the L3/DHCP capabilities to be "plugged" into Quantum networks. Project: glance Series: diablo Blueprint: local-image-cache Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/local-image-cache Spec URL: None Implement simple local filesystem cache with LRU flush Project: horizon Series: diablo Blueprint: localization Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/localization Spec URL: None Add i18n localization support to the openstack-dashboard so that it can be translated into multiple languages. Project: nova Series: diablo Blueprint: network-refactoring Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/network-refactoring Spec URL: http://wiki.openstack.org/network-refactoring Let’s have a session to specifically discuss the refactoring work needed in nova in order to support other networking models and services. The main discussion of this session will discuss the code already implemented in lp:ntt-pf-lab/nova/network-service and how to continue to make the networking code able to support networking as a first class service. This discussion is oriented on the actual code, and less on the vision (which will be discussed in the naas session) Project: keystone Series: diablo Blueprint: no-artificial-primary-key Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/no-artificial-primary-key Spec URL: None According to Keystone Developer Guide, artificial primary keys must be given in queries while adding a role to user, endpoint to tenant, and so on. For example, to add a role to user, we must provide something like: { "roleRef":{ "id":1, "roleId":"admin", "tenantId":"one" } "id" is an artificial primary key. In fact, it is autogenerated. So, documentation should be updated. Project: nova Series: diablo Blueprint: notification Design: Discussion Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/notification Spec URL: http://wiki.openstack.org/notification Support notification service that used by Watcher API (see also: Blueprint link to http://wiki.openstack.org/watch ) Project: nova Series: diablo Blueprint: notification-system Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/notification-system Spec URL: http://wiki.openstack.org/NotificationSystem Openstack desperately needs a system to notify interested parties of events relevant to them. More specifically, the ability to notify external consumers of events like instance builds, deletions and migrations are useful for monitoring and billing applications. We feel that a unified and defined notification system will discourage the inevitable requests for one-off implementations, and also will provide the opportunity to implement a clean, scalable solution. As such, we're proposing Openstack uses PubSubHubBub, which uses basic REST and Atom/RSS feeds to notify subscribers of information they care about. It sees substantial use in large production websites, and we feel that it would be appropriate for us. Project: nova Series: diablo Blueprint: nova-api-serialization Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-api-serialization Spec URL: http://wiki.openstack.org/Nova/ApiSerializationSpec The current approach to serialization and deserialization in Nova limits the ability of developers to make changes to requests and responses. This blueprint proposes a new, more modular approach which will make development easier when dealing with serialization and deserialization concerns. Project: nova Series: diablo Blueprint: nova-instance-referencing Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-instance-referencing Spec URL: http://wiki.openstack.org/NovaInstanceReferencing With the addition of zones to OpenStack, we now have a complication in addressing instances, since currently instances are referenced by their Primary Key, which is an auto-incremented integer. This is part of the current Rackspace API. Adding zones, which each have their own database, means that there is no guarantee of uniqueness among these PKs. We need to discuss alternatives, weighing how well they work, and how they would affect both current code as well as the APIs. Project: neutron Series: diablo Blueprint: nova-linuxnet-vifplugging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/nova-linuxnet-vifplugging Spec URL: None This is a pointer in the Quantum project to the Nova blueprint: https://blueprints.launchpad.net/nova/+spec/linuxnet-vif-plugging Project: nova Series: diablo Blueprint: nova-multi-nic Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-multi-nic Spec URL: None Once the hypervisors xenapi/libvirt are prepared to handle multiple nics and prepared to receive network_info from compute instead of looking it up themselves, the nova multi-nic feature can be put in place. Primary changes include: 1) removing mac_address column from the instances table and creating a mac_addresses table. This is for storing which instances own which mac addresses as well as which network each mac is for. 2) generation of mac addresses is moved to the network manager 3) allocation of mac addresses is handled by the network manager 4) network manager provides functionality for generating/storing mac address and IPs, and returning this information 5) compute calls allocation functionality, receives back a list of (network object, IP/mac_addr info dict) tuples 6) compute passes this list to the virt driver as a part of the spawn process. 7) assuming the virt layers are already set up to handle receiving network info and being able to handle multiple networks, mac_addresses and IPs as a apart of the xs_multi_nic and libvirt_multi_nic blueprints Project: neutron Series: diablo Blueprint: nova-quantum-manager Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/nova-quantum-manager Spec URL: None This is a pointer in the Quantum project to the Nova blueprint: https://blueprints.launchpad.net/nova/+spec/implement-network-api Project: nova Series: diablo Blueprint: nova-quantum-vifid Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-quantum-vifid Spec URL: http://wiki.openstack.org/NovaVifID Quantum requires that a service like nova expose a "interface-id" via the API that a tenant or an orchestrator can use to plug an interface into a quantum network. This work will likely require an API extension to expose this value, changes to the database to store this ID, and passing this value to the virt driver so that the vif-plugging there can use it. Project: neutron Series: diablo Blueprint: nova-quantum-vifid Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/nova-quantum-vifid Spec URL: None This is a pointer in the Quantum project to the Nova blueprint: https://blueprints.launchpad.net/nova/+spec/nova-quantum-vifid Project: nova Series: diablo Blueprint: nova-quota-schema Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-quota-schema Spec URL: http://wiki.openstack.org/Nova/QuotaKeyValueSpec Currently, the quota table in the nova db has a column for every type of quota we manage. Thus, each time we add a new type of quota to the system, we have to make a schema change. I propose that we switch to a key-value approach for quotas so that adding new types of quotas does not require a schema change. Project: nova Series: diablo Blueprint: nova-virtual-storage-array Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-virtual-storage-array Spec URL: http://wiki.openstack.org/NovaVsaSpec In order to emulate the current IT environments, and to provide better capabilities than Amazon's EBS, we would like to add to nova the capability to create virtual storage arrays. VIrtual Storage Arrays are block storage devices, that have the same performance, reliability and features than current enterprise SAN arrays like EMC Clariion or HP 3PAR. With this feature Users of the cloud will be able to buy, on demand, virtual storage arrays and connect them to their virtual servers as they do in the physical environment. Within the Virtual Storage Array (VSA), storage administrators will be able to choose things like type of drives (SSDs, SAS, SATA), type of interface (iSCSI, AoE, FCoE), cache size, how many virtual controllers, policies around snapshots and remote replications and RAID level. With this feature, cloud providers implementing OpenStack will be able to offer to their clients, enterprise class storage systems at the low cost of simple disk drives attached to servers. Users of the cloud, will be able to choose particular QoS for the storage they use (i.e use only SAS drives or only SATA). The proposal is to add VSA as an addition to OpenStack without the need to change the volume APIs. Project: nova Series: diablo Blueprint: openstack-api-backup-schedule Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/openstack-api-backup-schedule Spec URL: None Once backups are supported in Nova, add support to schedule them through the API. See http://docs.rackspacecloud.com/servers/api/cs- bindguide-latest.pdf page 48 - 52 for the Rackspace API methods. Project: nova Series: diablo Blueprint: openstack-api-floating-ips Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/openstack-api-floating-ips Spec URL: http://wiki.openstack.org/os_api_floating_ip During the bexar summit, we determined floating IPs (currently in nova ec2 api) and shared IP groups (coming as part of openstack/rackspace API requirements) are different things. In order to ease migration for folks already using the ec2 API, we need to add equivalent floating API functionality into the OpenStack API. This should simply be a matter of adding new API methods into OpenStack and calling the same code being used for the ec2 API (probably pushed down into the network module). Project: horizon Series: diablo Blueprint: openstack-api-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/openstack-api-support Spec URL: None We require the OpenStack API for running nova, so that we can easily extend it's functionality. For this, we need to add support for the OpenStack API. Project: nova Series: diablo Blueprint: openstack-compute-api-11-finalization Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/openstack-compute-api-11-finalization Spec URL: None We need to finalize what 1.1 will look like as discussed in this thread: https://lists.launchpad.net/openstack/msg01642.html. This should be done in the context of another blueprint: https://blueprints.launchpad.net/nova/+spec/api-defintion-process. Coming out of this discussion, we should have a clear understanding of what this API looks like in diablo, especially from the standpoint of the response and request formats. During this discussion it may be interesting to note that 1.1 is mostly implemented as per the spec: http://docs.openstack.org/openstack-compute/developer/content/. Project: keystone Series: diablo Blueprint: openstack-identity-service Design: Drafting Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/openstack-identity-service Spec URL: http://wiki.openstack.org/openstack-authn? Create an identity service for use with OpenStack. Initially using token-based authentication and necessary middleware to support integration with OpenStack core services; Nova, Glance, and Swift. Anti-Requirement: Do not build an identity system! Instead, use existing systems for heavy lifting. Local storage can be used for reference implementation or PoC Architecturally, therefore, implement a generalized claims-based architecture: Ex: base class that can: Request -> GetClaims -> ValidateClaims -> Returns claim-based authentication. 1.) Receive Claim 2.) Validate Claim 3.) Decorate request 4.) Forward request Requirement from Nova: Lightweight Delegation - As a User who is associated with a Tenant ID, I should have the ability to delegate Tenant IDs to other users and access those Tenants via a call in the new Keystone Service. Draft Acceptance Criteria: 1.) User is able to grant additional Tenants 2.) Each Tenant has a unique token 3.) The User is able to login with Username & Password/API key ...or... 4.) The User is able to login with Username & Password/API key AND Tenant ID (optional) 5.) A TenantID must always have at least one user. 6.) A user must be associated with a TenantID which may be a default tenant initially. 7.) The Admin User can pass a TenantID token and use a new call to list_all_tenants (Admin only) 8.) The non-Admin User can pass a TenantID token and use a new call to list_all_tenants available to THAT USER ONLY. 9.) The user can pass a TenantID token and use a new call to list_all_users (by TenantID) Requirement from Swift: Support existing Auth functionality (Rackspace Auth, DevAuth, SWAUTH) Requirement from Glance: Integrate with Glance Keystone work: 1.) Install Glance 2.) Standardize the interfaces 3.) Prove ability to write to service Glance work: 1.) Add middleware with tenant key 2.) Functional Tests over that communication to ensure they are attached properly (image:tenant) 3.) Modify Logging to include the middleware context. Requirement: Include documentation Acceptance Criteria: 1.) Must Include "How to start Service" 2.) Must include Presentation 3.) Dev Guide must be updated to include all new features 4.) Create Admin Guide and Install Guide 5.) Update Guide(s) to follow "Open Stack" look and feel Project: nova Series: diablo Blueprint: os-quotas Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/os-quotas Spec URL: None Currently, it is only possible to manage quotas using nova-manage. It would be useful to provide similar functionality through the osapi. Project: nova Series: diablo Blueprint: os-security-groups Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/os-security-groups Spec URL: http://wiki.openstack.org/os-security-groups Support management of security group in OS API 1.1 same as it is present in the nova EC2 API. Project: glance Series: diablo Blueprint: pluggable-auth Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/pluggable-auth Spec URL: http://wiki.openstack.org/ClientAuthenticationPlugin We don't really want Glance to ONLY support Keystone authentication. In many installations, it will be sufficient to have no auth at all for Glance. Therefore, we'd like to add an auth plugin layer to Glance so that it could support no auth (the default) or Keystone (optional) or other forms of authentication if desired by the implementor. Team Ozone expects to develop this layer and the associated Keystone plugin. Project: keystone Series: diablo Blueprint: pluggable-identity-store Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/pluggable-identity-store Spec URL: None Provide support for plugging in identity stores so Keystone (and therefore OpenStack) can be used and integrates with operator identity systems (like Open LDAP, eDir, Active Directory, etc...). Project: nova Series: diablo Blueprint: primary-ip-attribute Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/primary-ip-attribute Spec URL: None In a hybrid environment, the *public* IP address of an instance may not be controlled by Nova. Instead, the primary IP address may be part of the dedicated hardware; for example, a router/NAT device. In this case, the Nova-provided IP address cannot actually be used to access the instance (from outside the local LAN). Rackspace has this situation with our hybrid customers, but I do not believe that this is a Rackspace-specific issue, and will arise when anyone is using Nova in a hybrid network environment. The proposed Network as a Service (NaaS) might address this issue in the long-term, but the functionality is needed before NaaS becomes available, and this specific situation (integrating with an external router/NAT device) may still occur. The data stored for an instance is expanded to include a single attribute, PrimaryIP (ok, perhaps two attributes, for V4 and V6), that can be set by the user during instance creation or afterwards. This is *different* than the Public IP or Private IP normally assigned. Unfortunately, we can't use simple metadata for this, since external tools (for example, CloudKick) need to use this IP address to access an instance if it's set, and thus it needs to be part of the API contract and supported. The field should always be set; by default to the Public IP address of the server, but can be overwritten by the user. If there are quibbles over the name, some alternatives are "External Management IP" or "External Access IP." Project: nova Series: diablo Blueprint: provider-firewall Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/provider-firewall Spec URL: http://wiki.openstack.org/spec-provider-firewall Drop all traffic from blacklisted IPs before it reaches instances. Project: horizon Series: diablo Blueprint: quantum-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/quantum-support Spec URL: https://blueprints.launchpad.net/quantum/+spec/quantum-client-gui Having a GUI to demonstrate the base Quantum functionality will be critical to helping people understand the value of Quantum and provide feedback. The Dashboard for Openstack has achieved official "incubator" status as of June 2011, so a logical starting point would be add a representation of Quantum there. Project: glance Series: diablo Blueprint: query-filters Design: Superseded Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/glance/+spec/query-filters Spec URL: None The current Glance implementation is somewhat simplistic, especially for a multi-tenanted environment. This specification is for a proposal to enhance the Glance REST API by allowing query parameters on the /images and /images/detail resources. In a multi-tenanted environment, especially one with thousands of users or customers, returning a collection of images can be extremely cumbersome. By providing filtering via query string parameters, this collection can be used to reduce the set of images to a more manageable size. Project: nova Series: diablo Blueprint: ram-limits Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/ram-limits Spec URL: None Some deployers are primarily concerned with the amount of ram a user has access to across their instances. However, ram limits are not currently supported in the nova quota system. Additionally, in order to conform with the api 1.1 spec, quota limits should be exposed in the openstack api. Since instance and core limits do not show up in the api 1.1 spec, it should be possible for them to be hidden in the api. This blueprint can either leverage the schema changes in dependency nova-quota-schema, or make schema changes of its own. Project: nova Series: diablo Blueprint: reasonable-aws-compatibility Design: Obsolete Lifecycle: Complete Impl: Not started Link: https://blueprints.launchpad.net/nova/+spec/reasonable-aws-compatibility Spec URL: http://etherpad.openstack.org/ReasonableAWSCompatibility This is an effort trying to form a consensus on how compatible to the Amazon AWS API we make nova. In other word, what is "reasonable" compatibility? It could include also related activities including something like design/coding guideline and testing. Project: nova Series: diablo Blueprint: rebuild-servers Design: Discussion Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/rebuild-servers Spec URL: None Given an existing instance, provide support to re-image it. See http://docs.rackspacecloud.com/servers/api/cs-bindguide-latest.pdf page 35 for the Rackspace API around this. Project: nova Series: diablo Blueprint: refactor-privesc Design: Drafting Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/refactor-privesc Spec URL: None This spec proposes a refactoring of the way nova executes commands as root. Rather than calling "sudo" in the command, a run_as_root=True parameter is added to the utils.execute call. This allows to plus another root helper than sudo. * Removes rogue direct usage of subprocess module by proper utils.execute calls * Adds a run_as_root parameter to utils.execute, that prefixes your command with FLAG.root_helper (which defaults to 'sudo') * Turns all sudo calls into run_as_root=True calls * Update fakes accordingly * Replaces usage of "sudo -E" and "addl_env" parameter into passing environment in the command (allows it to be compatible with alternative sudo_helpers) * Additionally, forces close_fds=True on all utils.execute calls, since it's a more secure default Project: glance Series: diablo Blueprint: refactor-stores Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/refactor-stores Spec URL: None Currently, all the store backends use a @classmethod setup that requires the controller to constantly pass a set of options for calls to get(), create(), delete(), etc. This is inefficient because it means a whole bunch of option processing is done on each request, especially on create(). We should be creating a stateful object that validates itself when the API server is created. Project: horizon Series: diablo Blueprint: refactor-syspanel Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/refactor-syspanel Spec URL: None The nova-syspanel module was refactored to be a submodule of django- openstack. Project: keystone Series: diablo Blueprint: remove-default-tenant Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/remove-default-tenant Spec URL: None Default tenant is an ambiguous construct. It contains an _implied_ role which is not called out explicitly. This blueprint suggests getting rid of a default tenant and, where the functionality is needed, allowing various implementations to represent the relationship using a role (ex. Dashboard is going to create a "Member" role which will be used to associate users with tenants). Impact: 1. Authenticating without a tenant specified will return an unscoped token (as per original design spec here: https://github.com/rackspace/ keystone/raw/master/doc/design/flow_diagram.png). 2. Identity managers using the service API and back-end plug-in developers will need to manage the link between user and tenant. 3. Some APIs will change (like PUT /users/userId/tenant). Project: keystone Series: diablo Blueprint: roles-for-none-tenant Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/roles-for-none-tenant Spec URL: None Currently, in /users/userId/roleRefs a tenant must be provided: { "roleRef":{ "id":1, "roleId":"admin", "tenantId":"one" } } There must a way to add a role without a tenant: { "roleRef":{ "id":1, "roleId":"admin", } } Here is a proposed patch: https:/ /github.com/aababilov/keystone/commit/9171a73a8646afffba0f8bea67530dbd ea7c4428 It just allows to parse a roleRef without a tenantId Project: nova Series: diablo Blueprint: schedule-instances-on-heterogeneous-architectures Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/schedule-instances-on-heterogeneous-architectures Spec URL: http://wiki.openstack.org/ScheduleHeterogeneousInstances Nova should have support for cpu architectures, accelerator architectures, and network interfaces and be able to route run_instances() requests to a compute node capable of running that architecture. In addition, nova should prevent a user from inadvertently specifying, for example, an x86_64 machine image to run on a Power7 compute node or vice-versa. The scheduler should check for inconsistencies. Project: nova Series: diablo Blueprint: search-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/search-api Spec URL: http://wiki.openstack.org/NovaSearchAPI Cloud administrators and technical support personnel will often need to diagnose a problem based on limited information; for example, a user might report that a specific server is down. Nova should provide an API that permits queries to search for servers by name or IP address. The API should also permit wildcards (for example, "find hosts 192.168.2.*"). Project: keystone Series: diablo Blueprint: service-catalog-version-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/service-catalog-version-support Spec URL: None Current response to the Authenticate call returns a service catalog that does not inherently support multiple versions of catalog endpoints. THe problem with that is that as endpoint versions change, the catalog will also need to change. This could be problematic for client code that was writing expecting a specific version. That version should be supported in the catalog for as long as it is supported at that endpoint. This would mean we would have multiple endpoints listed - one for each version. A better solution would be to categorize services by version as well so the XML path or JSON hierarchy does not change for the duration that that specific version is supported at that endpoint. The current service catalog also does not help determine types. Since the naming could be inconsistent, a type is needed so we know if we are looking at a compute, object storage, or other kind of service. Sample catalog with versioning and servicetype (aka endpoint type): XML: internalURL="https://service1.internal.com/v2.0/blahblah"/> internalURL="https://service1.internal.com/v2.0/blahblah"/> JSON: { "serviceCatalog": [{ "name": "Cloud Servers" "type": "compute": [{ "publicURL": "https://compute.north.host/v1 /blah-blah", "internalURL": "https://compute.north.host/v1 /blah-blah", "region": "North", "versionId": "1.0", "versionInfo": "uri", "versionList": "uri" }, { "publicURL": "https://compute.north.host/v1.1/blah-blah", "internalURL": "https://compute.north.host/v1.1/blah-blah", "region": "North", "versionId": "1.1", "versionInfo": "https://compute.north.host/v1.1/", "versionList": "https://compute.north.host/", }] }, "name": "Cloud Files" "type": "object store": [{ "publicURL": "https://compute.north.host/v1/blah-blah", "internalURL": "https://compute.north.host/v1/blah-blah", "region": "South", "versionId": "1.0", "versionInfo": "uri", "versionList": "uri" }, { "publicURL": "https://compute.north.host/v1.1/blah- blah", "internalURL": "https://compute.north.host/v1.1 /blah-blah", "region": "South", "versionId": "1.1", "versionInfo": "https://compute.north.host/v1.1/",, "versionList": "https://compute.north.host/" }, links: [{"rel": "next", "href": ": "uri}] }, , links: [{"rel": "next", "href": ": "uri}] ] } } Project: glance Series: diablo Blueprint: shared-images Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/shared-images Spec URL: http://etherpad.openstack.org/GlanceSharedImageGroups Currently, Glance has only a coarse idea of ownership. Images are either public or not public, with public images shown in calls to GET /images and GET /images/details and private images shown only when calling GET /images/. We would like to add the ability to have shared image groups. This is dependent on the authentication integration, since we first need an authentication "tenant" in order to relate a set of images to a tenant and allow images to be shared with other tenants. Project: nova Series: diablo Blueprint: simple-usage Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/simple-usage Spec URL: None In smaller clouds, we can just query the database to get compute utilization information. We propose that in addition to http://wiki.openstack.org/SystemUsageData we have two apis: get a summary of usage for all tenants, and for a specific tenant - within a specified period. Project: nova Series: diablo Blueprint: snapshot-volume Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/snapshot-volume Spec URL: http://wiki.openstack.org/SnapshotVolume We can use snapshots for backups and to create golden volumes. This blueprint adds support for creating a snapshot of a nova volume with euca-create-snapshot. Project: horizon Series: diablo Blueprint: swift-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/swift-support Spec URL: None Support for managing swift containers and objects has been added to the OpenStack Dashboard. A new module called django-swift has been added that complements django-nova and provides management UIs for swift. Project: nova Series: diablo Blueprint: system-usage-records Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/system-usage-records Spec URL: http://wiki.openstack.org/SystemUsageData Usage creation on any billable event (to be defined in the spec). Ensure bandwidth is included on usage events. Administrative API for usage record creation/download. Project: glance Series: diablo Blueprint: test-refactor Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/test-refactor Spec URL: None We should use unittest2 features, including @skipIf and the setUpClass @classmethods. SQLAlchemy already requires unittest2, so it's not a new dependency for us. In addition, we should clean up some of the repetitive code shared between /tests/functional/test_curl_api.py and /tests/functional/test_s3.py In addition, we should be able to rework the unit testing to remove the need for a faked datastore. We should be able to just force a SQLite in-memory database, which should add the DB API layer into the unit testing mix. Project: keystone Series: diablo Blueprint: token-tenant-for-nova Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/keystone/+spec/token-tenant-for-nova Spec URL: None Currently, in nova queries, user default tenant is always used as nova's project in nova context. However, if token has a tenant, it should be used in place of user default one. For example, we get a token qwerty for user joeuser (his default tenant is abc) and tenant xyz. Currently, nova will use context (joeuser, abc) for token qwerty. The correct behavior should be using (joeuser, xyz). This patch fixed the issue: https://github.com/aababilov/keystone/commit/c306d9ca130717 f660a8bfbb8887676cc67260ca Project: nova Series: diablo Blueprint: unittest-examples Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/unittest-examples Spec URL: None We need good documentation and examples for creating unit tests. This will allow us to make sure that the unit tests remain consistent throughout the code base. As a minimum, we should have: example very basic unit test example use of stubs example use of mox documentation on what should go into a unit test vs functional test When complete, this can go in our tests directory as test_example.py Project: nova Series: diablo Blueprint: volume-type Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/volume-type Spec URL: http://etherpad.openstack.org/volume-type Enable different storage classes within a storage system, and uses of multiple storage backends within a Nova installation This involves: 1. Adding VolumeType with an id and a name, similar to InstanceType 2. Adding VolumeTypeExtraSpecs to allow specific values to be associated with volume types 3. Example scheduler that can use these values to a) schedule to different backends and b) pass the extra metadata to create_volume Project: glance Series: diablo Blueprint: wsgi-refactoring Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/wsgi-refactoring Spec URL: None Bring over the new goodness from Nova's updated WSGI layer Project: nova Series: diablo Blueprint: xs-ovs Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xs-ovs Spec URL: http://wiki.openstack.org/XenServerOVS Adds support for the Open vSwitch in XenServer. This allows for the transition away from the Linux Bridge which utilizes iptables/arptables/ebtables rule to the vSwitch which will allow for more granular networking protections, including networking protections for IPv6. Project: nova Series: diablo Blueprint: xs-xenstore-pump Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/xs-xenstore-pump Spec URL: None Xenstore is reloaded on a reboot of the guest. During Windows Boot, if sysprep is ran, the instance is rebooted. This causes the Xenstore to be flushed and drops all configurations that may have initially been injected. The pump would monitor the instance during boot time and ensure the configurations are maintained in the proper xenstore domain until the instance is completely booted