Project: keystone Series: essex Blueprint: 2-way-ssl Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/2-way-ssl Spec URL: http://etherpad.openstack.org/2-way-ssl Motivation Currently, an Openstack service (middleware) that needs to communicate with Keystone relies on an admin_token to authenticate itself with Keystone. This admin_token is stored in a plain-text configuration file on service node. This poses security risk if this file is compromised, and also increases the management overhead of this token, if it needs to be changed across multiple nodes. An alternative solution is to authenticate the Openstack service with Keystone via Secure Sockets Layer (SSL) client authentication. Benefits Some main benefits for this approach are:     Client certificates can be obtained and stored in a secure manner. Different services can be given different service certificates, creating different classes of service with different privileges in Keystone (for example, for QoS purposes)     Certificates can be revoked easily on Keystone. Changes     Client certificate needs to be created and signed by a CA trusted by the Keystone server. Keystone middleware needs to supply the client certificate when making an HTTPS connection.     A keystore and truststore need to be created on the Keystone server.     Keystone server needs to authenticate client certificate accordingly. Review: https://review.openstack.org/#change,1038 Project: glance Series: essex Blueprint: add-qpid-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/add-qpid-support Spec URL: None AMPQ-based notifications from glance are currently only supported via the rabbitmq provider. The stable of notification strategies should be extended to support Apache Qpid as an alternative AMQP provder. Similar to the blueprint recently implemented in nova: https://blueprints.launchpad.net/nova/+spec/apache-qpid-rpc Project: horizon Series: essex Blueprint: ajax-data-refresh Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/ajax-data-refresh Spec URL: None When objects in the table are in an indeterminate or "changing" state, we should be able to poll for new updates on those objects and display the updated information to the user in near-real time. Project: nova Series: essex Blueprint: apache-qpid-rpc Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/apache-qpid-rpc Spec URL: None The current RPC API implementations rely on using rabbitmq for the AMQP infrastructure. To provide the ability to use Apache Qpid (http://qpid.apache.org/) for the AMQP infrastructure, we must provide an RPC API implementation using the Python Qpid client since Rabbitmq and Qpid do not currently use the same version of AMQP. Project: neutron Series: essex Blueprint: api-filters Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/api-filters Spec URL: http://wiki.openstack.org/quantum-api-filters Allow clients to specify filters as query parameters. Project: neutron Series: essex Blueprint: api-framework-essex Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/api-framework-essex Spec URL: None The aim of this blueprint is to keep track of the improvements in the Quantum API framework for the Essex release. This changes include: - separation of API routers,controllers, and WSGI pipeline for v1.0 and v1.1 - importing upgrades in nova Openstack API WSGI layer into Quantum (in particular the improved Serializers/Deserializers and the Resource Class) - adapation of API controllers to the new model Project: neutron Series: essex Blueprint: api-operational-status Design: Pending Approval Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/api-operational-status Spec URL: http://wiki.openstack.org/QuantumOpStatus The goal of this blueprint is to introduce the concept of "Operational Status" for resources managed by Quantum. According to the decisions taken during the Essex design summit, this will be done in the following way: - The concept of "Operational status" will be added, as an attribute, to each Quantum resource The "Operational status" represents the current avaiability state of the network resources abstracted by the Quantum API object The "Operational status" is a read-only attribute avaiable for each Quantum resource. Attribute name will be 'operational-status' - The API will allow operations on Quantum objects regardless of its operational status. The API will not block or refuse operations on API objects. More information on slides from the design summit: http://www.slideshare.net/SalvatoreOrlando1/quantum-api-11-proposal Etherpad from the design summit: http://etherpad.openstack.org/QuantumAPI1-1essex Project: horizon Series: essex Blueprint: api-simplification Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/api-simplification Spec URL: None There are numerous wrapper classes for underlying data models which have been agreed to be useless obfuscations and unnecessary code clutter which is a pain to maintain. Additionally, the APITestCase unit tests largely only test that mox returns what you tell it to, and cannot be useful without live endpoints for integration testing. As such, and of them that don't test actual logic in horizon should be removed. Project: nova Series: essex Blueprint: aws-api-validation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/aws-api-validation Spec URL: None API paramaters aren't validated on execution. Before the method is ran, we should check if the required parameters are passed, and the values of the type expected. Preferably we should implement the validation in a manner which allows generation of API documentation which shows the requirements. Nova/validate.py was meant to be a start of this by using decorators. Project: nova Series: essex Blueprint: bandwidth-rate-limit-multipliers-and-base-limits Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/bandwidth-rate-limit-multipliers-and-base-limits Spec URL: None Right now rxtx_caps are stored with an instance flavor. This worked just fine in single network implementation, but when you have multiple networks, it makes sense to have different rate limits for them. I propose a base rate being set on each network, say: network A has base rate of 10mbps network B has base rate of 25mbps Flavors will then store a multiplier instead of a bps rate. So: flavor 1 has multiplier 1x flavor 2 has multiplier 2x flavor 3 has multiplier 2.5x and so forth.. This leads to flavor rates for network A and B: flavor 1 -> 10mbps and 25mbps flavor 2 -> 20mbps and 50mbps flavor 3 -> 25mbps and 62.5mbps Project: neutron Series: essex Blueprint: basic-vlan-plugin Design: Superseded Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/neutron/+spec/basic-vlan-plugin Spec URL: http://wiki.openstack.org/Quantum-BasicVlanPlugin The aim of this plugin is to provide: - an implementation of the Quantum API which will work across all the hypervisors supported by the compute service We will at first support KVM, Xen, and ESX - and then extend support to Hyper-V when it will become more mature from the compute side - a solution for installing Quantum without requiring specialized hardware or additional software This will also help packaging and distributing Quantum without additional dependencies This plugin will provide 'simple' network isolation with VLANs, as the nova VLAN network manager currently does. IP address management, VPN access, and Floating IPs are outside the scope of this blueprint, which is aimed at implementing exclusively the Layer-2 part of the VLAN network manager for quantum. More details in slides from the summit: http://www.slideshare.net/SalvatoreOrlando1/quantum-basic- vlan-plugin In other words, the plugin proposed with this blueprint will be functionally equivalement to the OVS plugin (https://blueprints.launchpad.net/quantum/+spec/quantum-openvswitch- plugin) , with the only difference being that it will use hypervisor- specific drivers instead of Open vSwitch. This will enable Quantum to be used over a wide range of hypervisors, including ESX and possibly hyper-V. Project: horizon Series: essex Blueprint: batch-actions Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/batch-actions Spec URL: None Now that we have a fancy new reusable table component we need the ability to implement batch actions. Project: horizon Series: essex Blueprint: boot-from-volume Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/boot-from-volume Spec URL: None Add ability within dash to launch an instance from an existing volume. Project: horizon Series: essex Blueprint: bootstrap-2 Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/bootstrap-2 Spec URL: None Bootstrap 2 is (essentially) complete and will be available on Jan. 31, 2012. Project: keystone Series: essex Blueprint: cache-enabling-middleware Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/cache-enabling-middleware Spec URL: None http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html We could write a middle ware that sets standard http headers for caching when a validate token call is made. This would allow people to use standard web accelerators on top of keystone to cache the calls.Would be a huge performance boost. Project: horizon Series: essex Blueprint: cert-download Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/cert-download Spec URL: None Support in UI to download RC files. This is as simple as generating a template and downloading to the user, similar to how devstack is doing it: https://github.com/openstack- dev/devstack/blob/stable/diablo/openrc Project: horizon Series: essex Blueprint: client-side-templating Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/client-side-templating Spec URL: None As we continue to increase our user-experience focus, we are going to need more and more capacity to do client-side templating. Modal confirmation dialogs are a great example of the need for this. Project: nova Series: essex Blueprint: cloudpipe-extension Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/cloudpipe-extension Spec URL: None Create an extension for OSAPI that provides the vpn ("cloudpipe") functionality that currently exists in the ec2 admin api. Then remove it from the ec2 admin api, which is deprecated. Project: nova Series: essex Blueprint: compute-network-info Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/compute-network-info Spec URL: None It is far to expensive for compute to make requests to network every time it needs ip address info for listing vms. It should keep a local copy of this info so that it can return more quickly. Project: horizon Series: essex Blueprint: confirm-on-delete Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/confirm-on-delete Spec URL: None When applying non-reversible actions like 'Delete', 'Terminate', a confirmation should be required, to avoid accidental button clicks. Could be implemented using jQuery dialogs, with possible fall-back to non-JS browsers. Project: horizon Series: essex Blueprint: cookie-based-sessions Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/cookie-based-sessions Spec URL: None Django 1.4 includes signed cookie-based sessions. This is the most reasonable default session backend for the purposes of Horizon (specific production deployment needs will vary). See https://docs.djangoproject.com/en/dev/topics/http/sessions/#using- cookie-based-sessions for more information. Project: glance Series: essex Blueprint: custom-disk-buffer Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/custom-disk-buffer Spec URL: None When adding swift large objects the data chunks are written to the default tempdir (/tmp). It would be useful to allow a custom partition/directory to be selected for the I/O buffer in order to select a partition/directory which can have different properties to /tmp, eg * different size * different permissions * different filesystem/hardware type Project: keystone Series: essex Blueprint: database-migrations Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/database-migrations Spec URL: None Schema & data migrations should be provided to ease the maintenance cost of running keystone in a production-quality environment. Because we're using sqlalchemy as our ORM, implementing sqlalchemy-migrations (http://code.google.com/p/sqlalchemy-migrate/) is the obvious solution. Addressed by https://review.openstack.org/#change,1200 Project: nova Series: essex Blueprint: deferred-delete-instance Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/deferred-delete-instance Spec URL: None Instances can be accidentally deleted. To prevent serious repurcussions because of this, we propose that the DELETE verb on /servers/{id} actually suspend the selected server for a period of time (configurable by the Nova administrator). After that time has elapsed, a separate process will perform the actual deletion. When a user deletes their instance today, the instance's disk is torn down immediately. As a safety feature, we should allow an operator a configurable setting that would allow the system to mark a image as deleted from the user's perspective but allow an administrator or operator to restore the instance. The image should not return from the api lists from the user's perspective, but could return 'queued- for-delete' or 'delayed-delete' in the action status field. An administrator should be able to restore the instance to a running state from the admin-api by issuing an action on the deleted instance. The administrator should also be able to force a deletion of a queued instance. Any IP addresses in use by the server should be retained and then released when the disk is purged from the host machine. Host space (RAM, disk, cores) should be considered reserved while the server is pending-delete, and no new VMs should re-use that space. Project: neutron Series: essex Blueprint: devstack-quantum Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/devstack-quantum Spec URL: None We need to add Quantum to devstack to facilitate easier testing of the integration between nova and Quantum. We will need to change the stack.sh script to use the QuantumManager and find a suitable plugin (since it uses kvm now, using the openvswitch plugin and openvswitch wil work fine). Project: nova Series: essex Blueprint: disk-configuration-parity Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/disk-configuration-parity Spec URL: None This is feedback from the session at the Essex Summit to achieve disk management parity between KVM and XenServer and to provide the model for other hypervisors to be compatible in how they manage disk images within the hypervisor. The amenable solution agreed upon at the summit was to add a second disk column to the instances_type table. This would allow service providers to have different operating systems configured differently and provide a consistent view across OpenStack. Using python-novaclient, a current nova flavor-list returns the following fields. +----+--------------+-----------+------+----------+ -------+------------+----------+ | ID | Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Quota | RXTX_Cap | +----+-------------- +-----------+------+----------+-------+------------+----------+ By adding an additional disk field, operators would be able to utilize this field to show customers how the disks would be configured between instance-types. For example: +----+--------------+-----------+------ +----------+-------+------------+----------+ | ID | Name | Memory_MB | Swap | Local_GB | VCPUs | RXTX_Quota | RXTX_Cap | +----+-- ------------+-----------+------+----------+-------+------------+------ ----+ | 1 | 256 slice | 256 | 0 | 10 | 1 | 150 | 10 | | 2 | 512 slice | 512 | 0 | 20 | 1 | 300 | 20 | Could be represented as: +----+--------------+--------- --+------+----------+-------+------------+----------+ | ID | Name | Memory_MB | Swap | Disk1_GB | Disk2_GB| VCPUs | RXTX_Quota | RXTX_Cap | +----+--------------+-----------+------+----------+-------+ ------------+----------+ | 1 | 256 slice | 256 | 0 | 10 |30 | 1 | 150 | 10 | | 2 | 512 slice | 512 | 0 | 20 |60 | 1 | 300 | 20 | | 3 | 256 slice | 256 | 0 | 40 |0 | 1 | 150 | 10 | | 4 | 512 slice | 512 | 0 | 80 |0 | 1 | 300 | 20 | In the above example, ID 1 would have a primary disk of 10gb allocated and a secondary disk of 30gb allocated. if the user resized to ID 2, both the primary and the secondary partition would grow accordintly. If the user then resized to ID 3, the primary disk would grow to 40gb and the secondary disk would be dropped from their configuration. ***The secondary disk would be considered ephemeral and would not be included in system snapshots or included in the disk images coming from Glance. *** Project: horizon Series: essex Blueprint: django-one-point-four Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/django-one-point-four Spec URL: None Django 1.4 will likely be released a month or two before Essex, so we'll want to migrate to the latest version which includes multiple timezone support, signed cookies, cookie-based sessions, and much more. Project: horizon Series: essex Blueprint: ec2-credentials-download Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/ec2-credentials-download Spec URL: None In addition to https://blueprints.launchpad.net/horizon/+spec/cert- download we need to expose ec2 credentials to clouds that have the ec2 interop layer enabled. Project: keystone Series: essex Blueprint: endpoint-identifiers Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/endpoint-identifiers Spec URL: None Endpoints may change (the version may change, the region may get renamed, the URL could change as well). A client may want to keep track of which endpoint a resource is in. To do that, they need an identifier for that endpoint that they know won't change. Maybe use portable IDs: https://blueprints.launchpad.net/keystone/+spec /portable-identifiers No API spec changes needed. The spec supports an ID already. Keystone Implementation: Since each Endpoint in the Keystone is generated by an endpoint template, and each template generates one endpoint. The endpoint template ID may be used to address this blueprint. While the ID won't be unique to distinguish endpoints between tenants, it will server the intent of this blueprint, allowing clients to identify a particular endpoint when attributes change. Project: horizon Series: essex Blueprint: environment-versioning Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/environment-versioning Spec URL: None There's a recurring problem of dependencies being added and then someone getting the latest code and not knowing this is the case. A simple control mechanism would be to have ./run_tests.sh keep track of an environment version that was incremented every time a new dependency was introduced and force a rebuild if it found the current environment version (tracked in a hidden file) either out-of-date or missing. It could additionally force a rebuild on changes of any major version revision (e.g. a new release). A yes/no option could be provided to allow the developer to skip the version update if they so desire. Project: horizon Series: essex Blueprint: essex-compat Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/essex-compat Spec URL: None The time has come to push forward off of the diablo stable release and start tracking Essex trunk for the other projects (so says Devin). Project: horizon Series: essex Blueprint: exception-handling Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/exception-handling Spec URL: None Termie and I discussed a strategy for doing consistent project-wide error handling that would look something like this: we define a central error handling mechanism "catch_exception" which is called from inside an except block that knows how to handle all the various API backends' error types, and can make determinations on whether they are passable or "fatal". If they are fatal they would be raised up to a higher-level middleware that redirects to an error page or logout ciew as necessary. If they are not fatal appropriate logging and messaging happens and the code flow is returned to the view. Project: horizon Series: essex Blueprint: extensible-architecture Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/extensible-architecture Spec URL: https://gist.github.com/1318553 This is a proposal for a coherent architectural strategy to provide extensibility and greater modularity in the Horizon project. It supercedes the Dashboard Plugin Support blueprint by accomplishing the stated goals there and more. Project: nova Series: essex Blueprint: extension-refactor Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/extension-refactor Spec URL: None Refactor extensions such that we can dispose of ExtensionMiddleware and LazySerializationMiddleware. Extensions will be called directly from within the nova.api.openstack.wsgi.Resource class, instead of in a separate middleware. Doing this will also allow us to eliminate the LazySerializationMiddleware. Project: nova Series: essex Blueprint: fast-cloning-for-xenserver Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/fast-cloning-for-xenserver Spec URL: http://wiki.openstack.org/FastCloningForXenServer On a Xenserver host, Openstack gets the image from glance for instance creation. There will be local copies of an image on a given Xenserver if multiple instance (of one image) are created on it. We can avoid streaming the image and creating local copies by re-using the images that have already been streamed to a given Xenserver host. This can be achieved by using the copy on write feature provided by Xenserver. Copy on write allows an image to be cloned and re-used. Cloning of a disk is almost instantaneous and avoids the overhead of the time spend re-streaming the image. Project: horizon Series: essex Blueprint: frontend-testing Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/frontend-testing Spec URL: None Dashboard is all about the user interface and experience; as such we should test that aspect as rigorously as we test our Python code. I propose 1. to develop the appropriate hooks in Dashboard to integrate Selenium using Splinter (http://splinter.cobrateam.info/) for Python bindings, and 2. to add qUnit for javascript unit testing, which will be integrated into the project test suite via Selenium. This way we can continue to have full CI from our single point of entry in bin/test. It will introduce a few new dependencies for those who wish to run the test suite. Project: keystone Series: essex Blueprint: generate-ec2-access-secret Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/generate-ec2-access-secret Spec URL: http://wiki.openstack.org/ec2-access-secret Keystone-manage has the ability to create a secret/access for a specific user/tenant combo. We should add an API that allows creation of access/secret pairs that a keystone user can use to get credentials for the ec2 interop layer. Project: horizon Series: essex Blueprint: gettext-everywhere Design: Obsolete Lifecycle: Complete Impl: Informational Link: https://blueprints.launchpad.net/horizon/+spec/gettext-everywhere Spec URL: None Add gettext support for all strings in Dashboard. Project: keystone Series: essex Blueprint: global-templates Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/global-templates Spec URL: None In POST /tokens query, global endpoints should be returned even if no tenant is set (neither user default tenant nor token tenant). This could be implemented with the following patch: https://github.com/aaba bilov/keystone/commit/622c166eff3ecc43178c3e85d775d51bf81c382e Project: keystone Series: essex Blueprint: globalendpoints Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/globalendpoints Spec URL: None Global endpoints are returned only for scoped authenticate callsie calls that have a Tenant.They should also be returned for unscoped authenticate calls. POST /tokens for an auth with no tenantID, tenantName, or default tenant should return a serviceCatalog with global endpoints THAT DON'T HAVE A %TENANT% PARAMETER IN THEM... In support of the Nova child zone use case: 1. I authenticate with the service account (admin) ... I'm not acting on behalf of another user. This account has no associated Tenant. 2. I need to get the global endpoints so I can call the child zone. Nothing is coming back. Project: nova Series: essex Blueprint: heterogeneous-tilera-architecture-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/heterogeneous-tilera-architecture-support Spec URL: http://wiki.openstack.org/HeterogeneousTileraSupport This blueprint adds support for bare-metal provisioning of compute nodes for different provisioning back-ends, with a back-end implementation for Tilera TileEmpower 64-core tiled processor systems (http://www.tilera.com/). Project: keystone Series: essex Blueprint: hide-admin-url Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/hide-admin-url Spec URL: None The adminURL endpoint in the service catalog may contain information such as internal address space that should not be exposed publicly. Provide a way to filter that out except for calls authenticated with an Admin or ServiceAdmin role. Project: horizon Series: essex Blueprint: hig Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/hig Spec URL: None Horizon needs a Human Interface Guidelines document to define overarching design criteria for UI updates and additions. This document can be used to evaluate proposed designs to ensure consistency in the OpenStack UX. Project: horizon Series: essex Blueprint: horizon-dev-setup-doc-update Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/horizon-dev-setup-doc-update Spec URL: None Add db sync and devstack instructions to wiki and create a node in the RST docs with the same setup information. Once horizon.openstack.org domain has been set up the dev setup docs will automatically appear there (since they will be in the RST docs). Project: horizon Series: essex Blueprint: horizon-doc-site Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/horizon-doc-site Spec URL: None Once sphinx documentation support is completed, we need to automatically have the documentation compiled and available on horizon.openstack.org Project: nova Series: essex Blueprint: host-aggregates Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/host-aggregates Spec URL: http://wiki.openstack.org/host-aggregates This blueprint will introduce the concept of aggregate into Nova. Host aggregates are different from zones and availability zones: while the former allows the partition of Nova deployments into logical groups for load balancing and instance distribution, the latter are for providing some form of physical isolation and redundancy from other availability zones (e.g. by using separate power supply and network gears). Availability zones do not necessarily mean geographic distribution whereas zones usually do. Host aggregates can be regarded as a mechanism to further partitioning an availability zone, i.e. into multiple groups of hosts that share common resources like storage and network. This enables a finer level of granularity in which to structure an entire OpenStack deployment. Aggregates allows higher availability of a single guest instance within an availability zone, it enables advanced VM placement strategies, and more importantly it enables hosts' zero-downtime upgrades (for example, via VM live migration across members of the aggregate, thus causing no disruption to guest instances). We propose to expose such a concept to the admin of the cloud, and at the same time to keep this transparent to the end-user. In fact, the OSAPI already provide some capabilities for host management via admin extensions, but this is very crude at the moment. Further extending the concept means that putting a host into 'maintenance mode' implies that all the instances running on it can migrate onto an available host in the aggregate, thus causing no disruptions to guest instances. Bringing such capability in the API (and consequently in the orchestration infrastructure) also means that the admin can intervene on the plaform, and at the same time be agnostic of the kind of hypervisor that the host is running, which is very beneficial. Project: nova Series: essex Blueprint: hypervsectomy Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/hypervsectomy Spec URL: None Remove Hyper-V support. It's unmaintained and very highly suspected of being broken. Project: horizon Series: essex Blueprint: identity-backend-type Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/identity-backend-type Spec URL: None Until Keystone has a means of querying the backend identity system (LDAP, keystone's built-in user/project system, etc) which is being used, Horizon should add a setting to configure the identity backend so that we can control behavior such as whether or not users/projects can be updated, users can change their own passwords, etc. This may require more than simply setting the "type" of backed (e.g. LDAP) but instead having a dict-config-style set of capabilities for the backend (e.g. {"can_add_users": True, ...}). Project: horizon Series: essex Blueprint: improve-dev-documentation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/improve-dev-documentation Spec URL: None Improve the developer documentation for Dashboard both in the readme and on the wiki to reduce the time it takes for new developers to start contributing to the project. Project: horizon Series: essex Blueprint: improve-help-documentation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/improve-help-documentation Spec URL: None Implement contextual help in Dashboard (tooltips and/or help panel) to improve Dashboard user experience. Project: horizon Series: essex Blueprint: improve-user-experience Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/improve-user-experience Spec URL: None Implement Paul Tashima's wireframes for Dashboard that improve the overall user experience. http://speakerdeck.com/u/paultashima/p /openstack-dashboard-wireframes-10142011 Project: horizon Series: essex Blueprint: improve-visual-design Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/improve-visual-design Spec URL: None Improve the visual design of Dashboard in conjunction with user experience improvements presented at the Essex Design Summit. Project: neutron Series: essex Blueprint: init-scripts Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/init-scripts Spec URL: None We need to create init scripts for Quantum such that Quantum can be started automatically on boot and log to a predetermined location (/var/log/quantum?). Project: horizon Series: essex Blueprint: instance-detail Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/instance-detail Spec URL: None Implement an instance detail page; where users can drill down to their instance details by clicking on the name of an instance in the instance list. This greatly improves the usability from the syspanel side of things. Project: horizon Series: essex Blueprint: instance-power-state Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/instance-power-state Spec URL: None Show the power state of the instance in the instances list. Project: glance Series: essex Blueprint: interim-glance-authz-service Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/interim-glance-authz-service Spec URL: None Until Keystone is fully functional with AuthZ support, we may need some primitive authZ in Glance. Description of the proposed implementation is here: http://etherpad.openstack.org/rbac-brain This is similar to Nova's authz blueprint: https://blueprints.launchpad.net/nova/+spec/interim-nova-authz-service Project: nova Series: essex Blueprint: interim-nova-authz-service Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/interim-nova-authz-service Spec URL: http://wiki.openstack.org/ShortTermAuthZinNova Until Keystone is fully functional with AuthZ support, we may need some primitive authZ in Nova. This BP discusses how this may be possible at a low-level. Description of the proposed implementation is here: http://etherpad.openstack.org/rbac-brain Project: keystone Series: essex Blueprint: internal-reset-password Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/keystone/+spec/internal-reset-password Spec URL: None If the simple internal user-store is being utilized for accounts, keystone currently lacks the means of resetting a user's password. The for use case of the simple ID store in keystone directly (i.e. not using LDAP or other external system), enable an API that will allow the creation of a new password for an existing user. Project: nova Series: essex Blueprint: internal-uuids Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/internal-uuids Spec URL: None Currently we support uuids through our public interfaces, but internally we still depend on integers. We should transition the codebase to depend fully on uuids. We currently have a four-tiered approach: 1) Convert compute api to accept instance objects 2) Convert compute manager to accept instance uuids 3) Convert virt drivers to accept instance objects 4) Update any remaining integer- based calls Project: horizon Series: essex Blueprint: javascript-unit-tests Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/javascript-unit-tests Spec URL: None Qunit? Project: keystone Series: essex Blueprint: keystone-client Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-client Spec URL: None Create a client for Keystone. Proposing both an importable python client as well as a CLI interface that could aid with troubleshooting: Example Python API     >>> import keystoneclient as keystone     >>> session = keystone.authenticate(**my_credential_kwargs)     >>> print session.tenant     None     >>> print session.tenants()     {'a1': {'id': 'a1', 'name': 'customer-x'}, 'b2': {'id': 'b2', 'name': 'project-y'}}     >>> print session.token     43598acc- fed0-4de5-8ca5-c5fe050d60d9     >>> print keystone.validate(session.token).status     True     >>> session = session.scope(session.tenants['a1'])     >>> print session.token 278837cd-23c6-4049-95e7-a9711348786f     >>> print keystone.validate(session.token).status     True     >>> session = keystone.authenticate(**my_credential_kwargs, tenant_id='a1')     >>> print session.tenant     {'id': 'a1', 'name': 'customer-x'}     >>> print keystone.validate(session.token).status     True Keystone Example Client CLI     $ python keystoneclient.py authenticate --username="admin" --password="secrete"     { "access": {"token": {"id": "994c75b3-1678-4dce-9a36-c5a46bf3a9ef", [...]}, "serviceCatalog": [...], "user": {"id": "1", "roles": [...], "name": "admin"}}} Project: keystone Series: essex Blueprint: keystone-configuration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-configuration Spec URL: None Implement/use common config module and get Keystone in line with other OpenStack projects. See: https://blueprints.launchpad.net/openstack- common/+spec/common-config Required: validate current config handling and options Optional: implement common cfg.py from nova/glance as per openstack-common direction References: > https://github.com/markmc/nova/blob/common-config/nova/common/cfg.py > https://github.com/markmc/nova/blob/common- config/nova/tests/test_cfg.py Project: keystone Series: essex Blueprint: keystone-documentation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-documentation Spec URL: http://etherpad.openstack.org/KeystoneDocsDraft Create developer and installation documentation for Keystone. INFO: Decision in Keystone meeting: dev manuals in RST. All other manuals in openstack-manuals. Project: nova Series: essex Blueprint: keystone-export-rewrite Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/keystone-export-rewrite Spec URL: None There was code added to export users and projects from deprecated auth in nova-manage. Unfortunately it is missing an important piece. In deprecated auth user_id == user_name and project_id == project_name whereas this is not true in keystone. We therefore need to create a better export that will export into keystone directly and update the entities in the nova database with a proper ids from keystone Project: keystone Series: essex Blueprint: keystone-internal-authorization Design: Drafting Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-internal-authorization Spec URL: None In order to continue cleaning up the Keystone code, we need to move the authorization checks for ADMIN and SERVICE ADMIN roles out of all the function calls in logic/service.py and reimplement as a decorator and/or middleware. Potentially implement a context object to hold call data like other projects do. Project: keystone Series: essex Blueprint: keystone-logging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-logging Spec URL: None Improve keystone logging for production deployments including:  * specification of the output logs by configuration file  * additional debug level logging in API request flow & error/404 responses to assist in troubleshooting ZNS: I suggest bring it in line with other OpenStack projects and use whatever other projects/PTLs are using or intending to move towards (ex. OpenStack common?). Project: keystone Series: essex Blueprint: keystone-manage2 Design: Discussion Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-manage2 Spec URL: None ./bin/keystone-manage positional arguments are evil The numerous positional arguments in the plethora of keystone-manage commands make it difficult to: - Remember the syntax for a command - Discover the syntax for a command - Predict the outcome of a command - Distinguish the meaning/context of an argument - Change the CLI in the future - Debug Imagine the headache of trying to figure out what's wrong with the following management command:     $ ./bin/keystone-manage endpointTemplates add 1 nova nova http://nova.openstack.org/ http://admin.nova.openstack.org/ http://192.168.1.50/ 1     ERROR: invalid literal for int() with base 10: 'http://192.168.1.50/' Traceback (most recent call last):       File "./bin/keystone-manage", line 16, in         keystone.manage.main()       File "/Users/antiver/Dropbox/keystone/keystone/manage/__init__.py", line 293, in main         raise exc     ValueError: invalid literal for int() with base 10: 'http://192.168.1.50/' If you'd like the complete headache, here's my full CLI session: http://paste.openstack.org/show/3614/ (which would be a *lot* longer if I cared about *what* was actually being created). A (backwards- incompatible) revision should address: - Not all commands should revolve around an "object type" (e.g. ./keystone-manage db_sync) - I should not have to remember more than one positional argument - Consideration should be made for managing remote keystone services in the future (e.g. --keystone="http://remote.keystone/" - Everything should be interactively discoverable (intuitive feedback on errors, comprehensive help text) - It should be *very* easy to implement a new command, or find/review/revise an existing one Project: keystone Series: essex Blueprint: keystone-refactor-backend Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-refactor-backend Spec URL: None Use a more dynamic, pythonic backend management design more in line with other OpenStack projects. Reference: Nova, Burrow, keystonelight (https://github.com/termie/keystonelight/) See also: blueprint refactor-keystone-models Project: keystone Series: essex Blueprint: keystone-service-registration Design: Review Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-service-registration Spec URL: http://etherpad.openstack.org/service-registry Use case: 1. A service 'registers' itself with Keystone and reserves a name (Ex. Swift, or nova). 2. Registered services can then create roles for the service (Ex. swift:admin or nova:netadmin) or tuples (nova:delete:volume) and endpoint templates (and endpoints) 3. On token validation, Keystone returns these roles and a service can apply it's own policies based on them. Project: keystone Series: essex Blueprint: keystone-swift-acls Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/keystone-swift-acls Spec URL: None Support for swauth ACL enforcement mechanisms in Keystone swift middle-ware using existing Keystone functionality; roles. This is a blueprint to enhance the existing swift middleware to support the authorization callback. Project: nova Series: essex Blueprint: kvm-report-capabilities Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/kvm-report-capabilities Spec URL: None Currently, only the Xen hypervisor supports reporting capabilities back to the zone manager. This implements that functionality for KVM. Project: nova Series: essex Blueprint: lasterror Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/lasterror Spec URL: None Add in a usability feature that will help troubleshooting and debugging. Advantages:- - Easy access to error information. Use this instead of digging in the log files - Standard format for information supplied when opening bugs - Speed up deployments CLI interface example:- nova-manage last-error [] Where the arguments can be: all host Thanks Gary Project: nova Series: essex Blueprint: libvirt-file-injection Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/libvirt-file-injection Spec URL: None We support injecting files on boot through the Compute API v2. We already support it in our xen driver, but we also need to support this feature in our libvirt driver. Project: nova Series: essex Blueprint: libvirt-resize Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/libvirt-resize Spec URL: None Resize does not work in libvirt/kvm. Also there seems to be some duplication of work between resize and migration. If this can be generalized into common code, that is preferrable. Project: nova Series: essex Blueprint: live-migration-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/live-migration-api Spec URL: http://etherpad.openstack.org/live-migration-api Live migration can be executed only from nova-manage, that is, admin has to login physical server in cloud. Considering about production system management, it should be executed from remote host(through API). Project: nova Series: essex Blueprint: live-migration-resource-calc Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/live-migration-resource-calc Spec URL: http://etherpad.openstack.org/live-migration-resource-calc Please see etherpad. Project: horizon Series: essex Blueprint: migrate-to-bootstrap Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/migrate-to-bootstrap Spec URL: None Move to simple CSS structure and javascript UI framework of bootstrap. http://twitter.github.com/bootstrap/ Project: glance Series: essex Blueprint: multi-process-server Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/multi-process-server Spec URL: None The Glance API server currently starts a wsgi server on a green thread per request. This appears to limit the processing capability of the Glance API server to a single CPU. Under heavy load this can make Glance appear un-responsive. This is especially noticeable when using SSL, where a single thread can use 100% CPU for encryption and compression processing. We propose to add multi-process support by starting up a configurable number of processes each listening on the Glance server port. Project: nova Series: essex Blueprint: multiple-floating-ip-ranges Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/multiple-floating-ip-ranges Spec URL: None When registering a range of IPs as floating IPs, allow specification of the eth device and name of the pool. This will allow multiple zones: internal, public, dmz, ... When associating the IP, nova- network will bridge into the device specified in the database (instead of a global flag) and when allocating users can optionally pass in the name of the pool they want to allocate from, otherwise it will be pulled from the default pool (specified via a flag) Project: nova Series: essex Blueprint: netapp-volume-driver Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/netapp-volume-driver Spec URL: http://wiki.openstack.org/NetAppNovaVolumeDriver This blueprint proposes inclusion in Essex (targeted for Essex-4) for a nova-volume driver that accommodates volume provisioning / management on NetApp storage appliances via NetApp's OnCommand Provisioning Manager. Project: nova Series: essex Blueprint: network-info-model Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/network-info-model Spec URL: None I'm tired of network_info being a list of tuples of dicts of lists of dicts that have to be looped through in many different places to get at certain pieces of information. As such I've created a somewhat generic model for storing the information compiled by nova network that the api and virt require. I've made it easy to pass through rpc and hydrate on the other side, and have built accessor functions for getting at specific information. This prevents code duplication of the looping mechanisms and abstracts the underlying structure from api and virt so every little change won't require refactoring across the board. Project: nova Series: essex Blueprint: nexenta-volume-driver Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nexenta-volume-driver Spec URL: http://wiki.openstack.org/NexentaVolumeDriver We would like to introduce the NexentaStor support for the nova-volume service. This blueprint proposes the driver based on the iSCSI driver already integrated into the OpenStack nova-volume service, with the basic capabilities to create, export and delete volumes and snapshots. Project: horizon Series: essex Blueprint: notifications-logs-exceptions Design: Obsolete Lifecycle: Complete Impl: Not started Link: https://blueprints.launchpad.net/horizon/+spec/notifications-logs-exceptions Spec URL: None UI that shows notification, logs, exceptions, etc. Project: nova Series: essex Blueprint: nova-image-cache-management Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-image-cache-management Spec URL: http://wiki.openstack.org/nova-image-cache-management This blueprint will add image cache management to compute nodes, including the detection and deletion of corrupt imaged and images which are no longer used. It will also add the capability to pre- cache selected images to speed up initial VM start-up Project: neutron Series: essex Blueprint: nova-network-parity Design: Obsolete Lifecycle: Complete Impl: Started Link: https://blueprints.launchpad.net/neutron/+spec/nova-network-parity Spec URL: None This blueprint is to track the bugs related to achieving parity with the current set of networking features in nova. Some of this will be done in the QuantumManager for nova, but other pieces will end up as Quantum services or plugins. Project: nova Series: essex Blueprint: nova-parity-floating Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-parity-floating Spec URL: None We need to teach the QuantumManager about floating ips. Project: nova Series: essex Blueprint: nova-rootwrap Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-rootwrap Spec URL: None Nova needs root access for a number of actions, and currently does so through sudo. Each distribution needs to provide its own sudoers file in packaging, and sudoers offers suboptimal filtering of allowed actions, potentially providing a privilege escalation path. This spec continues the work started in Diablo (refactoring the privilege escalation mechanism) by proposing a more secure root wrapper that allows: * Precise filtering of arguments * Drop privileges to a lower-privileged user We'll aslo take this opportunity to review all uses of privilege escalation and get rid of unneeded ones, as well as separate commands into multiple filter profiles (by node type). Project: nova Series: essex Blueprint: nova-vm-state-management Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-vm-state-management Spec URL: http://wiki.openstack.org/nova-vm-state-management Current checks on valid state transitions are limited to a few cases, leading to multiple opportunities for non-deterministic behavior. In addition some long running tasks can lead to odd behavior – for example a VM in the building state can spend a long time in image download, be terminated, and when the image download completes go ahead and launch the VM. This blueprint would constrain the valid state transitions to a limited subset, and ensure that the remaining transitions lead to consistent and deterministic behavior. Project: nova Series: essex Blueprint: nova-volume-snapshot-backup-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-volume-snapshot-backup-api Spec URL: http://wiki.openstack.org/VolumeSnapshotBackupAPI A pair of of openstack api extentions to support the creation of snapshots and backups of volumes with richer semanics than is possible with the ec2 API Project: horizon Series: essex Blueprint: novaclient-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/novaclient-migration Spec URL: None Completely remove all code that depends on openstackx and replace with novaclient instead. Project: nova Series: essex Blueprint: optional-host-and-admin-information Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/optional-host-and-admin-information Spec URL: None In a private cloud you might be ok exposing the real hostnames where the VM is running to the client instead of hashlib.sha224(host).hexdigest(). This would also be valuable when developing/debugging on a cluster. In addition, it would be great to have extra information about the vm, i.e. path to all of the attached disks. Name of the vm in the hypervisor, etc. This could be implemented as an extension that adds extra data to the servers list for admins. Project: nova Series: essex Blueprint: osapi-console-log Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/osapi-console-log Spec URL: None The osapi does not support retrieving console logs. Support needs to be added to bring parity with ec2. Project: neutron Series: essex Blueprint: ovs-portstats Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/ovs-portstats Spec URL: None We need to create a resource extension to support retrieving statistics for a given port. The new resource will be named "stats" and callable via: GET /v1.0/extensions/ovs/tenants//networks//ports//stats Any plugin supporting this extension should list "ovs_portstats" in their supported_extensions and should implement the a get_port_stats() method which returns the following: { "rx_packets": 0, "rx_bytes": 0, "tx_errors": 0, "rx_errors": 0, "tx_bytes": 0, "tx_packets": 0 } Project: keystone Series: essex Blueprint: portable-identifiers Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/portable-identifiers Spec URL: None For entities like roles to be remain relevant across deployments, they need an identifier that remains the same in all deployments. Use Case #1: the nova role of cloud_admin should have an identifier that can be referenced in all deployments of OpenStack. This will be needed for federation, where a query may be forwarded to a remote system; a query such as "Does this user have the cloud_admin role?" Use Case #2: a bunch of VMs are moved from one cloud to another. The UUID may change, but there should be an identifier that get ported over with the VMs so they can still be uniquely identified. For E2 it will be for users and tenants. Project: glance Series: essex Blueprint: progressbar-upload-image Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/progressbar-upload-image Spec URL: None Current cli makes people think that the program is stalled while handling large files. The goal of this blueprint is to make cli more informative. Showing upload status, bandwidth and ETA or stalled while uploading an image Project: glance Series: essex Blueprint: protected-images Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/protected-images Spec URL: None Some images are more valuable than others, and Glance should provide a mechanism to protect those. Think of it as a "read-only" setting for an image. For example, a user creates an image to be used as a "gold master" from which to build other servers; that user should be able to flag that image as "protected" or "readonly" and Glance should return an error when a DELETE is issued against the resource. The ancillary function "unprotect" or "read/write" must also be provided so that images can be unprotected and then deleted if desired. Project: nova Series: essex Blueprint: public-and-private-dns Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/public-and-private-dns Spec URL: http://wiki.openstack.org/InstanceAndFloatingIPDNSForNova Add functionality to nova to automatically manage DNS entries for instances, and DNS entries associated with floating IPs, with a driver based system to handle different DNS servers. Project: neutron Series: essex Blueprint: quantum-bigswitch-plugin Design: Obsolete Lifecycle: Complete Impl: Started Link: https://blueprints.launchpad.net/neutron/+spec/quantum-bigswitch-plugin Spec URL: None Create a quantum plugin for bigswitch controller Project: neutron Series: essex Blueprint: quantum-devstack-integration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-devstack-integration Spec URL: None There is already some work on this effort in the form of Dan Wendlandt's nova-quantum.sh script available at - http://wiki.openstack.org/QuantumOVSDemo This blueprint tracks the effort to integrate this script, diablo codebase and the new devstack.sh script such that new Quantum developers can be productive in the least amount of time. This will go a long way in helping us expand the Quantum dev community. Project: nova Series: essex Blueprint: quantum-dhcp-parity Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/quantum-dhcp-parity Spec URL: None We need to add DHCP support to QuantumManager in order to bring it closer to feature parity with the current nova network managers. This won't be all that different from the current dhcp support in the other managers except that it will need to interface with quantum networks (instead of the networks table) and also be able to use both Melange and nova ipam depending on which one is configured. Project: nova Series: essex Blueprint: quantum-nat-parity Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/quantum-nat-parity Spec URL: None The QuantumManager needs to be taught about NAT .. and we also need to make sure the gateway functionality works as expected with both linux (iptabes) and ovs (flows) vif drivers. Project: neutron Series: essex Blueprint: quantum-nvp-plugin Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-nvp-plugin Spec URL: None Merge quantum plugin that talks to Nicira NVP. Project: neutron Series: essex Blueprint: quantum-ovs-tunnel-agent Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-ovs-tunnel-agent Spec URL: None Enhances the existing Quantum OVS Plugin with a tunneling agent that enables Hypervisors to be connected via GRE tunnels. The new agent can be enabled/disabled via configuration file and provides backwards compatibility with existing non-tunneling OVS Agent. Project: keystone Series: essex Blueprint: rearchitect-keystone Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/rearchitect-keystone Spec URL: http://etherpad.openstack.org/ksl rearchitect the underlying components of keystone - manage/resolve the gaps for a merge Project: keystone Series: essex Blueprint: refactor-keystone-models Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/refactor-keystone-models Spec URL: None Use a dict-like construct to manage the entity model in Keystone and add support for extended/dynamic attributes that are routed from front to backend. See Keystonelight as a reference: https://github.com/termie/keystonelight See code submitted already: ht tps://github.com/openstack/keystone/blob/d1d3df0465f6ef1b14ed71eeed84d 92c9fe6f256/keystone/models.py Project: nova Series: essex Blueprint: remove-ajaxterm Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/remove-ajaxterm Spec URL: None Ajaxterm is not secure, nor is it currently maintained. Therefore it should be removed from nova. Project: nova Series: essex Blueprint: remove-ec2-extensions Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/remove-ec2-extensions Spec URL: None Before the openstack api existed we added support for roles/user/project, vpn (cloudpipe), and misc stuff in something we called the "admin" ec2 api. As those features exist in the openstack API (and have been moved to other components such as keystone) we should remove these admin extensions. The dead code lives in nova/api/ec2/admin.py Project: nova Series: essex Blueprint: remove-virt-driver-callbacks Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/remove-virt-driver-callbacks Spec URL: None There are unused callback parameters in the virt driver (nova.virt.driver:ComputeDriver). Specifically: def pause(self, instance, callback): def unpause(self, instance, callback): def suspend(self, instance, callback): def resume(self, instance, callback): def rescue(self, context, instance, callback, network_info): def unrescue(self, instance, callback, network_info): I believe the original intention was to pass a callback and then perform a non-blocking call at the virt layer...but none of the drivers support this I would like to remove them to reduce programmer confusion. XenAPI comes the closest, but it does a blocking loop before finally calling the callback...essentially making the callback useless. Project: glance Series: essex Blueprint: retrieve-image-from Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/retrieve-image-from Spec URL: None External HTTP, S3 or Swift locations can be referenced when adding a new image, via the X-Image-Meta-Location header. The result is that the image content is not uploaded to glance, instead the external location is relied upon when serving out the image (modulo caching). The Horizon team have a requirement to allow an image be added based on content from a pre-existing location, and for glance to actually upload from that external store. This could be acheived by adding support for a new header:   X-Image-Meta-Copy-From: URI where URI is a HTTP, S3, or Swift location that's accessible to the glance API service. The result would be that the image content is uploaded to the backend store currently configured for the glance API service. Project: horizon Series: essex Blueprint: reusable-table-component Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/reusable-table-component Spec URL: None Providing a suite of off-the-shelf components that encapsulate common UI features is the next step in Horizon extensibility. Horizon's most critical and frequently used UI feature is the table list view currently re-implemented in nearly every template in the project. This blueprint tracks adding a reusable table component to Horizon and converting all existing table list views. Project: horizon Series: essex Blueprint: reusable-tabs Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/reusable-tabs Spec URL: None We need a reusable Tab component much like DataTables, as tabs are an essential part of Horizon's interface and UX/design goals. Project: keystone Series: essex Blueprint: s3token Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/s3token Spec URL: http://wiki.openstack.org/Keystone-BP-S3Token This capability has 3 parts: A keystone patch to add a new auth-n API for S3 API. A middleware s3_token.py to use 1. from Swift. A swift patch to use token and endpoint information from 2. 1 and 2 for Keystone, 3 for Swift. This blueprint has 1 and 2. Related bug: #874280 Project: nova Series: essex Blueprint: scaling-zones Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/scaling-zones Spec URL: http://wiki.openstack.org/EssexSchedulerImprovements Communicate with trusted zones via RPC vs API. Add Capacity DB table for use my scheduler in local zones. Implement pushing of events 'up' through zones to give an idea of capacity and capabilities. Implement a new table at the top level for the API to use in order for it to know about all instances in all zones. Project: nova Series: essex Blueprint: separate-nova-adminapi Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/separate-nova-adminapi Spec URL: None Having the admin apis running with regular apis is a bit confusing. The flag to allow admin functions is ugly as well. Project: nova Series: essex Blueprint: separate-nova-metadata Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/separate-nova-metadata Spec URL: None The metadata server currently runs with the ec2 api. This should be broken out into a separate service. It should: a) run on its own port b) still be run automatically with nova-api but also have a nova- metadata worker c) have updated forward rule and flags (instead of using ec2_dmz_ip) Project: nova Series: essex Blueprint: separate-nova-volumeapi Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/separate-nova-volumeapi Spec URL: None The volume api is implemented as an extension to nova compute. It needs to run as its own endpoint and have its own extensions. Project: horizon Series: essex Blueprint: snapshot-volume Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/snapshot-volume Spec URL: None UI to manage volume snapshots. Project: nova Series: essex Blueprint: solidfire-san-iscsidriver Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/solidfire-san-iscsidriver Spec URL: http://wiki.openstack.org/SolidFireVolumeDriver I would like to add support for SolidFire ISCSI devices in the existing SanISCSIDriver. This would add the ability to create and attach SolidFire block device volumes similar to how Solaris and LeftHand are currently implemented. Project: horizon Series: essex Blueprint: sphinx-docs Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/sphinx-docs Spec URL: http://etherpad.openstack.org/HorizonDocs Add rich documentation using sphinx and match the nova, glance, swift style and coordinate with Anne Gentle on making the documentation available online. Project: nova Series: essex Blueprint: start-stop-methods-support-in-os-servers-xapi Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/start-stop-methods-support-in-os-servers-xapi Spec URL: None This blueprint proposes to add APIs for start/stop instances to servers resource as extension APIs. Currently compute api has start/stop methods for ebs boot and EC2 has those APIs. However they are missing in openstack API. Project: nova Series: essex Blueprint: support-kvm-boot-from-iso Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/support-kvm-boot-from-iso Spec URL: None just as xenapi support boot from iso image ,we need to add the same feature for kvm Project: keystone Series: essex Blueprint: support-multiple-credentials Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/support-multiple-credentials Spec URL: https://github.com/rackspace/keystone/issues/132 Support additional credentials such as EC2, username/password, username/APIkey, etc. Project: glance Series: essex Blueprint: support-sendfile Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/support-sendfile Spec URL: None Support sendfile(2) to remove userspace copying of image file data As recommended by Reynolds Chin, we should add support for using the sendfile(2) system call to bypass userspace copying of an image file during uploads. The pysendfile library (http://code.google.com/p/pysendfile/) can be used for this purpose. Add support for sendfile(2) without changing the existing iterator logic in the Glance client Project: glance Series: essex Blueprint: support-ssl Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/support-ssl Spec URL: None Add a use_ssl argument to the client constructor to support HTTPS connections to Glance... Project: horizon Series: essex Blueprint: suspend-instance Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/suspend-instance Spec URL: None UI to support suspending instances in instance list. Project: glance Series: essex Blueprint: swift-location-credentials Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/swift-location-credentials Spec URL: None When using swift as a backend store a request to the registry may display the swift user's credentials in plaintext. Change this to have the credentials encrypted. Project: neutron Series: essex Blueprint: test-coverage Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/neutron/+spec/test-coverage Spec URL: None As with every project, our code test run/coverage numbers could certainly be improved. We should identify the offenders and either prune unnecessary code or add more tests to increase the coverage. Project: horizon Series: essex Blueprint: toggle-features Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/toggle-features Spec URL: None When a user logs in, keystone returns a catalog. Based on the components / extensions in the catalog, dashboard should expose UI based on what is actually available. Project: horizon Series: essex Blueprint: unified-packaging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/unified-packaging Spec URL: None Our current strategy of shipping two modules in one repository with separate setup.py files is messy and detrimental. The new version of manage.py that will ship with Django 1.4 (but works perfectly right now) is meant to live one directory up from the "project" directory (e.g. one dir up from where it lives in horizon now). This cleans up some path import ugliness, but it was also done to promote the separation between projects and apps. In short, it makes it trivial to ship an app with a "sample project" next to it. What we would need to do: 1. Move the horizon/horizon/horizon and horizon/openstack- dashboard/dashboard each up one level, eliminating the extra layer of directories. 2. Move manage.py up one more directory from horizon/dashboard/manage.py to horizon/manage.py 3. Create a new, unified setup.py in at horizon/setup.py and delete the other two setup.py files. 4. Adjust hardcoded paths in files like run_tests.sh and the Sphinx conf. 5. Notify external projects (e.g. devstack) of the change. Project: horizon Series: essex Blueprint: unified-test-data Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/unified-test-data Spec URL: None Test data is defined in dozens of places throughout the codebase, in extremely inconsistent ways. A single place for test data makes the code more DRY, more reusable and makes writing tests massively easier in the future. Project: nova Series: essex Blueprint: untie-nova-network-models Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/untie-nova-network-models Spec URL: None There are several places in nova where network information has been foreign key tied together or to instance structures. These ties are incompatible with external network services. Take for example an instance that instance has a backref to fixed_ips. As a result instance['fixed_ips'] can be used all throughout the code base. If those fixed_ips live in an external service this causes issues. The structures that I see are Instance, virtual_interface, fixed_ip, floating_ip, and network. These tables need to have foreign keys pointing to each other removed and the code that uses these references needs to be updated to either request information through the network api, or to refer to the instance network_info cache (there is another blueprint regarding this cache). Project: horizon Series: essex Blueprint: update-localization Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/update-localization Spec URL: None The localization has fallen behind changes in the dashboard, and there are two issues that I came across that I'd like to discuss before preparing a pull request: (1) compatibility with the _page_header.html partial template call and (2) where to put the language selector in the UI. Project: glance Series: essex Blueprint: uuid-image-identifiers Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/uuid-image-identifiers Spec URL: None Based on the mailing list thread (https://lists.launchpad.net/openstack/msg02601.html), it looks like the consensus is to move to using UUIDs as identifiers for resources in OpenStack projects. Project: nova Series: essex Blueprint: vnc-console-cleanup Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/vnc-console-cleanup Spec URL: http://wiki.openstack.org/VNCConsoleCleanup At present, different code paths are used to create vnc consoles for xen and kvm implementations. Cleanup needs to be done to unify to a common path. Project: nova Series: essex Blueprint: volume-cleanup Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/volume-cleanup Spec URL: None Volume code needs to be cleaned up to ease integration with other schedulers and backends. The following steps are necessary: 1. Remove aoe (no one is using it) 2. Store ip addresses for iscsi targets instead of discovering 3. Change discover volume to prepare_attach, sending in ip that will attach to volume 4. Return credentials from prepare (CHAP credentials to begin with) 5. Similar change to undiscover volume Project: horizon Series: essex Blueprint: volumes-interface Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/volumes-interface Spec URL: None Currently the Openstack Dashboard does not provide an interface to manage Nova volumes. This blueprint proposes adding an interface for users to manage volumes similar to how Amazon EC2's interface works. Project: nova Series: essex Blueprint: x509-cert-crud Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/x509-cert-crud Spec URL: http://wiki.openstack.org/x509-proposal Expose X509 certs to an admin extension so that we can generate an rc file for euca-upload-bundle and euca-register to work again Project: nova Series: essex Blueprint: xenapi-ha-nova-network Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-ha-nova-network Spec URL: None Nova Network supports an HA mode which conflicts a bit with the model used by XenServer of deploying in a DomU. It is possible for it to work if we don't mind routing traffic through the DomU. This blueprint is primarily a spike to discover if this method is sufficient, or if some additional work needs to be done to move the HA stuff into dom0. Output of this blueprint should be a set of instructions for HA mode in XenServer. Project: nova Series: essex Blueprint: xenapi-provider-firewall Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-provider-firewall Spec URL: None The libvirt security group driver code allows for specification of provider firewall rules, which are rules defined by a service provider. These can be used to quarantine compromised vms. Support needs to be added to XenApi for this use case. Project: nova Series: essex Blueprint: xenapi-security-groups Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-security-groups Spec URL: None The goal of this blueprint is to provide support for security groups on the XenAPI driver as well. The implementation will be basically a porting og the current libvirt implementation, with the only exception that it will provide the IPTables driver only (and VIF isolation rules will be enforced through XenAPI plugins as they are enforced now). In the future we might provide an Open vSwitch drivers, but this work item is not in the scope of this blueprint. A full specification and implementation plan will follow soon. Project: nova Series: essex Blueprint: xenapi-sm-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-sm-support Spec URL: http://wiki.openstack.org/xenapi-sm-volume-driver Write a new volume driver for nova-volume to handle storage using XenAPI/SM (Storage Manager) and more advanced iSCSI systems like filers etc. For more information, read also this blueprint: http://wiki.openstack.org/iSCSISupportXenAPI. Project: nova Series: essex Blueprint: xml-templates Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xml-templates Spec URL: http://wiki.openstack.org/XMLTemplates Currently, request extensions have to deserialize data, manipulate it, and reserialize it. This happens for each extension. This is generally not much of a problem for JSON data, but XML is expensive to deserialize and reserialize, and it is currently impossible to extend the XML without directly editing the serializer or writing an independent serializer. This proposal is to establish new middleware which performs the XML serialization, and to also establish a means of creating XML templates, which can be extended by attaching slave templates to describe the extra data that an extension may wish to include.