Project: neutron Series: folsom Blueprint: agent-db-ha Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/agent-db-ha Spec URL: None In the event that a Quantum agent loses connectivity to the Quantum database then it should continue to try to access the database. The failures should be logged. In the event of failure to access the database the network topology should not be changed. Project: neutron Series: folsom Blueprint: agent-logging Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/agent-logging Spec URL: None Add logging support to the agents. This can make use of the following: 1. common agent directory 2. cfg from open stack common With the above we can have configurable logging support Project: glance Series: folsom Blueprint: api-2 Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-2 Spec URL: None Super-blueprint for tracking progress on OpenStack Images API v2 The spec that actually got implemented is being documented and will be made available here complete. Project: glance Series: folsom Blueprint: api-v2-anonymous-access Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-anonymous-access Spec URL: None We should grant access by anonymous users to public images. Project: glance Series: folsom Blueprint: api-v2-image-access Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-image-access Spec URL: None Implement the /images//access resource according to the v2 API spec. Project: glance Series: folsom Blueprint: api-v2-image-caching Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-image-caching Spec URL: None We need support for caching image files in the v2 API. Project: glance Series: folsom Blueprint: api-v2-image-tags Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-image-tags Spec URL: None Implement the /images//tags resource according to the v2 spec Project: glance Series: folsom Blueprint: api-v2-image-upload Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-image-upload Spec URL: None Users need to be able to upload image data! Project: glance Series: folsom Blueprint: api-v2-image-visibility Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-image-visibility Spec URL: None The spec describes what should control the visibility of images. Make sure our implementation matches. Project: glance Series: folsom Blueprint: api-v2-images Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-images Spec URL: None We need to be able to manage image records in the /images resource of the v2 API. Don't worry about getting everything working exactly to spec (links, pagination, etc), just get it functional. Project: glance Series: folsom Blueprint: api-v2-images-filtering Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-images-filtering Spec URL: None We need to provide filtering on the /images resource for the v2 API. See the spec for interface details. This should also tie into the schemas to determine what attributes we allow a user to request filtering on. Project: glance Series: folsom Blueprint: api-v2-images-pagination Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-images-pagination Spec URL: None We need to provide pagination for the v2 images api. See the spec for interface details. Project: glance Series: folsom Blueprint: api-v2-images-sorting Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-images-sorting Spec URL: None We need to allow clients to sort the /images container by specific attributes. This needs to tie in to the schema definition to communicate what fields are sortable. Project: glance Series: folsom Blueprint: api-v2-links Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-links Spec URL: http://wiki.openstack.org/glance-api-v2-links The jsonschema draft document specifies link description objects as part of a schema document. A link description object defines a format for inferring link relations from the attributes of a document that is an instance of such a schema. Instead of following this format, the present glance v2 api follows the openstack compute api example of embedding link description objects directly in non-schema documents. This blueprint proposes changing version two of the glance api to adopt the jsonschema canonical approach. Project: glance Series: folsom Blueprint: api-v2-refactor-schemas Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-refactor-schemas Spec URL: http://wiki.openstack.org/glance-api-v2-refactor-schemas In the glance v2 api, schemas are used to communicate the expected format and attributes of image objects, access record objects, and image tags. These schemas are specific to v2. They are not used by v1 and would likely be changed in any future version. However, they presently live in project-global namespace. And they are served up by a single monolithic API object which is therefore required to know about all schemas. This blueprint proposes to refactor schemas to individual objects and move them under the glance/api/v2 library umbrella. To make room, other libraries in glance.api.v2 may need to be moved around as well. Project: glance Series: folsom Blueprint: api-v2-schemas Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-schemas Spec URL: None The v2 API provides JSON schemas for clients to consume. They need to be dynamically generated from deployment-specific configuration. These custom attributes should also be stored in such a way that they can be enabled and disabled. Project: glance Series: folsom Blueprint: api-v2-store-access Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-store-access Spec URL: None Create a config option (show_image_direct_url=True/False) that represents whether or not the API should communicate an image's backend location (direct_url) back to HTTP clients. Project: glance Series: folsom Blueprint: api-v2-user-properties Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/api-v2-user-properties Spec URL: None Users should be able to store arbitrary attributes on images. Determine the best way to do this and implement it! One idea would be to use additonalProperties as catchall string schema. Project: horizon Series: folsom Blueprint: asset-compression Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/asset-compression Spec URL: None Currently there are ~25 js/css/etc assets which need to be loaded. We should implement a asset compression solution which loads a single js and single css asset. Project: neutron Series: folsom Blueprint: authorization-support-for-quantum Design: Discussion Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/authorization-support-for-quantum Spec URL: http://wiki.openstack.org/QuantumAuthZ The goal of this blueprint is to provide basic authorization in Quantum by levearging keystone. Note: the linked spec below is somewhat out-dated, but I believe still had the same general goals of introducing a simple authn/authz model based on keystone, so I will leave it to the new BP owner to modify or remove this link. Etherpad notes from Folsom Summit:   AuthN/AuthZ and RBAC for Quantum   - goal is simple first model for Authn/Authz, just to expose Quantum API at all (currently, we can't expose Quantum to tenants without completing this item).   - Need to do basic keystone integration for middleware on server, and on client library.   - basic model is "tenant" or "admin". can grow over time.   - Need to circle back with keystone team on this...   - delegation of port ownership, very narrow rights. Example is letting tenant plug into a port on a public switch owned by the service provider.   - can we do this integration in a way that it is not tighly-coupled with keystone? Might want to use quantum with other systesm. Maru says that swapping out wsgi middleware should be doable.   - we should look at how Nova does this. They define capabilities in JSON file.   - can we define capabilities for what we need in quantum? How would you represent ownership of a single port?   - Keystone does not target per "instance" capabilities. - networks are a different type of resources. Networks can be shared resources, hence the need for delegation.   - Key question: how do you give tenant control over a subset of the attributes on a network port? For example, service provider wants to prevent tenant from disabling anti-spoofing protections on a port, but does want to give the tenant control over security groups on that port.   - Where is this implemented? Authn wsgi middleware seems pretty straightforward. Authz is trickier. Does plugin need to be able to do Authz, or this a generic component in the API layer. Additional Questions: - We will also need to update python-quantumclient and the CLI to be keystone aware. jkoelker seems to be reworking the client, so may be best to coordinate with him. Project: horizon Series: folsom Blueprint: automatic-secure-key-generation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/automatic-secure-key-generation Spec URL: None The SECURE_KEY of every Django installation should be set to a unique value upon deployment. Currently, it is the system administrators responsibility to change this to a secure (i.e. unique) value. He has several ways to achieve this: - Do it manually (current state) - Use a (Linux) distribution-specific package that generates a key in a post-installation step - Deploy via crowbar with a modified dashboard barclamp that generates the key The first option is tedious and error-prone (and easily forgotten). The second option fails if the package is part of a pre-generated appliance (thus installed only once but deployed multiple times) and the latter is beyond our control. Instead, we should allow dashboard instances to generate the secret key automatically once upon first start. However, this can be rather tricky, as the typical Apache+mod_wsgi+daemonized deployment involves several Python interpreters accessing the code, so there's some kind of locking needed. Here's a possible implementation: https://github.com/saschpe/horizon/compare/bp/automatic-secure-key- generation It has the advantage that SECRET_KEY doesn't have to be part of local_settings.py anymore and thus is one thing less one needs to care for. It has an additional dependency on the 'lockfile' Python module, but I don't see this as an issue, as it is also pulled in by nova (as a transitive dependency of python-daemon). Project: horizon Series: folsom Blueprint: bootstrap-progress-bars Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/bootstrap-progress-bars Spec URL: None Currently in the launch instance modal window we use our own styled progress bars to display quotas. I propose that we switch over to the bootstrap progress bar components. Proposed look: * Success state: http://stsh.me/1zc * Error state: http://stsh.me/1zb Project: cinder Series: folsom Blueprint: cinder-notifications Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/cinder-notifications Spec URL: None Add basic notifications in cinder for create/delete/attach/detach volumes. The notifications could be used for billing and event notifications. Project: neutron Series: folsom Blueprint: cisco-nxos-enables-multiple-ports Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/cisco-nxos-enables-multiple-ports Spec URL: None Currently, Cisco NXOS plugin only handles two ports for the physical switch configuration. It should be able to configure "n" number of ports Project: neutron Series: folsom Blueprint: cisco-plugin-v2-api-support Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/cisco-plugin-v2-api-support Spec URL: None We will need to update the Cisco L2 network plugin to work with the new v2 plugin API. Project: neutron Series: folsom Blueprint: cisco-v2-meta-plugin Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/cisco-v2-meta-plugin Spec URL: None These enhancements will allow a stand alone plugin to configured as a device sub-plugin. In such a case, the meta-plugin will not manage the state of the logical resources, but will delegate it to this stand alone plugin. Additional device sub-plugins can be configured as before. Project: cinder Series: folsom Blueprint: command-options Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/cinder/+spec/command-options Spec URL: None Update the keystone cli client by changing all options to use '-' (dash) in long names rather than '_' (underscore). The previous underscore option name will be maintained for backward compatibility for a release or two but not show up in help output or documentation, or me clearly marked 'DEPRECATED' if they do appear. Project: keystone Series: folsom Blueprint: command-options Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/command-options Spec URL: None Update the keystone cli client by changing all options to use '-' (dash) in long names rather than '_' (underscore). The previous underscore option name will be maintained for backward compatibility for a release or two but not show up in help output or documentation, or me clearly marked 'DEPRECATED' if they do appear. Project: nova Series: folsom Blueprint: common-rpc Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/common-rpc Spec URL: None The nova.rpc code would be useful to other projects. Dependencies on nova code should be pulled out and the code should get moved to openstack-common. The openstack-common side: https://blueprints.launchpad.net/openstack-common/+spec/common-rpc Project: nova Series: folsom Blueprint: config-drive-v2 Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/config-drive-v2 Spec URL: None At folsom design summit [1,2], we discussed improvements for config drive, with the basic goal of a.) basically dumping the metadata service data into a file/directory structure on the config drive b.) adding an 'openstack/' metadata directory, that would at this point have network information (possibly in netcf format) -- [1] http://summit.openstack.org/sessions/view/100 [2] http://etherpad.openstack.org/FolsomNovaConfigDriveImprovements Project: cinder Series: folsom Blueprint: create-volume-from-image Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/create-volume-from-image Spec URL: http://wiki.openstack.org/CreateVolumeFromImage Allow creating volumes based on images stored by Glance. This could be done at boot time to make booting from a volume easy, or at any other time to pre-create volumes. Project: neutron Series: folsom Blueprint: database-common Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/database-common Spec URL: None The purpose of the blueprint is to provide a common database interface to quantum that can be used by the plugins and agents. The interface will provide the following: 1. Common configuration interface (plugin.ini file):     i. Database string - similar to those in OpenStack     ii. Reconnect timeout - in the event that there are connectivity issues with the database (for example, the plugin starts prior to the SQL service, the controller where the SQL service is running is down for maintenance or has been rebooted) Project: nova Series: folsom Blueprint: db-migration-cleanup Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/db-migration-cleanup Spec URL: None As of Essex we have 82 database migrations. It would be nice to compact these to reduce the codebase size and minimize database manipulation when creating new installations and/or running unit tests. Goals: -single migration to upgrade to Essex -continue to support upgrades from Essex (Diablo or early would have to upgrade to Essex first...) -migrations added during Folsom release cycle will be compacted during "E" release cycle. -cleanup instance_types table maintenance/population Project: nova Series: folsom Blueprint: delete-in-any-state Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/delete-in-any-state Spec URL: None Deletes are allowed in most states right now, but because of various failure scenarios, there are situations where an instance cannot be fully deleted. Users will want to delete an instance at anytime, for management and billing reasons. If an instance is not in a state that does not safely allow for deletes, then the instance should be hidden from the user (effectively deleted from their perspective) by either moving to another tenant, masking through the database or another means. Project: nova Series: folsom Blueprint: deprecate-root-helper Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/deprecate-root-helper Spec URL: None Replace root_helper option with rootwrap-specific options. root_helper (which allows to use pure "sudo" to run commands as root in Nova/Cinder/Quantum) will be marked deprecated in Folsom, so that it can be removed in Grizzly. Project: neutron Series: folsom Blueprint: dhcp-overlapping-ips Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/dhcp-overlapping-ips Spec URL: None Currently, Quantum supports different networks with overlapping IP addresses, but the Quantum DHCP implementation has an agent that if run on a single device would not support overlapping IPs (due to the fact that there's a single linux IP stack). We could use something like linux namespaces Project: nova Series: folsom Blueprint: disable-server-extensions Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/disable-server-extensions Spec URL: http://wiki.openstack.org/DisableServerExtensions Some server extensions allow extra parameters to be posted along with the server entity. There is currently no way for these extensions to be disabled, which creates confusion about the core api spec. This blueprint encompasses adding a simple set of checks for enabled extensions before handling this post data. Project: keystone Series: folsom Blueprint: draft-v3-api Design: Drafting Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/draft-v3-api Spec URL: None Draft out a blueprint for feedback on updating the keystone v3 Core API Project: nova Series: folsom Blueprint: ec2-id-compatibilty Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/ec2-id-compatibilty Spec URL: None Switching to UUIDs will break most ec2 clients. We therefore need some data in the ec2 layer that will map UUIDs to friendly ec2 ids. Project: horizon Series: folsom Blueprint: edit-flavor-ui Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/edit-flavor-ui Spec URL: None Nova's paradigm is that in order to "change" a flavor you delete it (which really just marks it as "deleted" in the DB) and create a new flavor with the same user-facing ID. Horizon can greatly improve the experience here by simulating an "edit". Essentially, we present an "edit" dialog without the ID, and on the backend we manually do the deletion and creation with the same ID, entirely hidden from the user. Project: cinder Series: folsom Blueprint: effecient-volumes-from-images Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/effecient-volumes-from-images Spec URL: None If Glance and Nova volumes are storing images and volumes in the same storage system, copy-on-write or deduplication and other features can be used to make instance and volume creation faster and use less space. Project: nova Series: folsom Blueprint: efficient-limiting Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/efficient-limiting Spec URL: None Currently API limits are done after all results are returned from SQL. For example if the request was http://localhost:8774/v1.0/servers/detail?limit=50 and there were 10,000 servers to be returned, the API would request all 10,000 servers from the database, buffer them all in memory, and return only the first 50. This can be better handled by passing the limits down to the SQL layer and doing more efficient queries. Project: neutron Series: folsom Blueprint: expose-dhcp-server-ip Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/expose-dhcp-server-ip Spec URL: None in order for firewall logic to be able to poke a hole allowing traffic to/from a DHCP server, we need to expose the IP being used for DHCP in a subnet to external entities. This could be done by introduce device_owner attribute to the port. Project: nova Series: folsom Blueprint: extract-nova-volumes Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/extract-nova-volumes Spec URL: None Use "cinder" as the default volume service in place of nova-volumes. Project: neutron Series: folsom Blueprint: f-3-cli-usability-improvments Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/f-3-cli-usability-improvments Spec URL: None There are a few things worth doing to make the v2-compatible quantum CLI easier to use (feel free to add more, or to split individual items out into separate bugs): - rename binary to quantum from quantumv2, and eliminate old binary - eliminate "cliff.app" text from error messages. - allow specifying networks by name, not UUID, as long as name is unambiguous for that tenant (similar to how nova let's you refer to a VM by name). This actually makes the flow much more smooth, and probably even eliminates the need to have a single command to create both network and subnet (since there's no longer a need for users/scripts to parse the UUID returned by the first call and include it in the second). Project: nova Series: folsom Blueprint: finish-uuid-conversion Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/finish-uuid-conversion Spec URL: None There are a few remaining places that haven't been converted to use UUIDs that still need to move. This blueprint is to track all of them. 1. Volume and Snapshot ids need to be converted to UUIDs 2. Instance ids in Block Device Mapping need to be converted to UUIDS 3. Instance ids in volumes table need to be converted to uuids (and the foreign key removed) 4. Instance ids in instance_metadata need to be converted 5. Security group instance association needs to be converted Project: nova Series: folsom Blueprint: floating-ip-notification-event Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/floating-ip-notification-event Spec URL: None we need to send the floating ip alloate and release notifications for billing cases. Project: horizon Series: folsom Blueprint: floating-ips-workflow Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/floating-ips-workflow Spec URL: None The floating IP associatin experience could be greatly improved by using workflows to allow entry into the workflow from either the instances table or the floating ips table with appropriately prefilled values and better handling of redirects, etc. upon completion. Project: nova Series: folsom Blueprint: formalized-message-structures Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/formalized-message-structures Spec URL: http://etherpad.openstack.org/formalized-message-structure Documenting the messages passed through the rpc layer to improve modularity and scalability. Project: nova Series: folsom Blueprint: general-host-aggregates Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/general-host-aggregates Spec URL: None Durring the summit we discussed improving host aggregates in the following ways: Decouple xen pool additon from host aggreggate Ensure multi-membership works Decouple availability zone (either a specific tag or a specific aggregate) Expose aggregate data to scheduler Discussion on the etherpad here: http://etherpad.openstack.org/FolsomNovaHostAggregates-v2 Project: glance Series: folsom Blueprint: glance-deprecate-client Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/glance-deprecate-client Spec URL: None The bin/glance CLI tool has been deprecated in favor of python- glanceclient. Update the code to signify this. Project: glance Series: folsom Blueprint: glance-folsom-docs-cleanup Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/glance-folsom-docs-cleanup Spec URL: None There are a ton of docs that need to get written and several things can be cleaned up. This is a large blueprint to cover whatever work gets done before Folsom is released. Project: glance Series: folsom Blueprint: glance-request-tracking Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/glance-request-tracking Spec URL: None Based on a mailing list discussion (http://markmail.org/message/etyyrked6s6gvdb5) we should add support for a request id. Project: neutron Series: folsom Blueprint: global-config-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/global-config-support Spec URL: None Add support to the agent and plugins that will enable them to make us of the global configuration data structure cfg.CONF. This is a prerequisite for the RPC and other common library support. Project: nova Series: folsom Blueprint: host-topic-matchmaking Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/host-topic-matchmaking Spec URL: None The ZeroMQ RPC driver introduces a concept of pluggable matchmaking for bare topics providing a "get_workers" method. This can be used to find a peer to communicate with, a la "compute.host" rather than sending to a bare topic such as "compute". A similar requirement exists in the scheduler when it pulls a list of all hosts from the database (which feeds from RPC). This code should be broken out of the ZeroMQ driver and available to other components. Project: nova Series: folsom Blueprint: hyper-v-revival Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/hyper-v-revival Spec URL: None Base feature parity for the hyper-v driver, with a fake-driver for testing to get hyper-v re-integrated in to openstack for the Folsom release. I also want to add in the WiX scripts needed to create the MSI based installer for the services. Project: horizon Series: folsom Blueprint: image-copy-from Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/image-copy-from Spec URL: None Using glance, Horizon should be able to take a URL for an image located online, and pass that to Glance to then create an image from. Project: nova Series: folsom Blueprint: image-guest-parity Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/image-guest-parity Spec URL: http://wiki.openstack.org/GuestFilesystemParity We propose a blueprint to help openstack perform actions with/on images in a uniform manner. This would mean unifying (or abstracting) the different methods via ephemeral volumes are created, mounted, and modified (ie network injection). This is useful since not all methods are available on all operating systems (most importantly rhel6 lacks qemu-nbd but has guestfs and vice versa). We would also like to propose a possible solution to the long term problem of unifying all image modification and introspection methods into one utility, if this makes sense for the community. Project: glance Series: folsom Blueprint: image-replication Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/image-replication Spec URL: None The first run at this should just be a script that can be used to copy images from one glance deployment to another. Super simple. Project: cinder Series: folsom Blueprint: implement-availability-zones Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/implement-availability-zones Spec URL: None With Cinder being a separate service having it's own database a new implementations of availability zones is needed. Project: glance Series: folsom Blueprint: import-dynamic-stores Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/import-dynamic-stores Spec URL: None Instead of having to list out all the stores in the api/v1/images.py in the import list there we should be able to provide the list of stores in config and then have glance itself dynamically load those stores and register there schemes with its own internal registry. Project: nova Series: folsom Blueprint: improve-external-locking Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/improve-external-locking Spec URL: None Make sure locks do not need implementation-specific cleanup. This should be helpful in case of multiple services on the same host sharing a lock, where it's almost impossible to cleanup properly and automatically without stopping all components first. Project: neutron Series: folsom Blueprint: improved-nova-quantum-integration Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/improved-nova-quantum-integration Spec URL: None This is a "proxy" blueprint to track work Trey is doing in Nova to remove the need for running nova-network in Nova with Quantum. We have this BP so that it shows up in our list of items to track for Quantum. https://blueprints.launchpad.net/nova/+spec/quantum-nova-network-api Instead, nova-compute will directly call Quantum. This means that DHCP and L3 + NAT forwarding will be Quantum's responsibility, as we will no longer be using the nova-network implementations. Note: included in this work would be making sure that nova uses the python- quantumclient library to contact Quantum (rather than a copy of the client code) and making sure that Nova uses new keystone authn capabilities that will be added to python-quantumclient (this may require the nova config file to contain a credential that should be used to access the Quantum API). Project: cinder Series: folsom Blueprint: initial-db-cleanup Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/initial-db-cleanup Spec URL: None All of the migrations carried over into cinder should be compacted, just create an initial DB at the appropriate migration level and with only the tables we need and use it as the starting point for Folsom. Project: horizon Series: folsom Blueprint: inline-object-creation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/inline-object-creation Spec URL: None In many cases, you find yourself in the middle of some workflow/form and realize you need to go somewhere else in order to create the prerequisite keypair, floating ip, etc. This is extremely annoying. Instead, we could simply have a little "add" button next to the select widget that allows you to create a new whatever-it-may-be. Project: nova Series: folsom Blueprint: instance-system-metadata Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/instance-system-metadata Spec URL: None Nova already has the concept of instance-metadata, however, this is used for *user-provided* metadata. Nova doesn't have a way to store arbitrary key/value pairs on an instance that are used internally by the compute service. Such a mechanism would be useful in the development of compute and virt level-plugins that may need to persist state to the DB. In these cases, they could use the instance system metadata table without having to alter the schema using a DB migration. The proposal is to provide a new table, `instance_system_metdata` that, while almost exactly like `instance_metadata` will not be exposed outside of the compute layer. Project: nova Series: folsom Blueprint: instance-type-extra-specs-extension Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/instance-type-extra-specs-extension Spec URL: http://wiki.openstack.org/InstanceTypeExtraSpecsExtension Be able to indicate comparative operations for 'value' column in instance_type_extra_specs by putting the operations at the beginning of the 'value' column. Project: nova Series: folsom Blueprint: integrate-python-glanceclient Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/integrate-python-glanceclient Spec URL: None Nova should use the new python-glanceclient library in place of the old glance client. Project: horizon Series: folsom Blueprint: ip-validation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/ip-validation Spec URL: None When dealing with lots of IP, IP ranges, etc., it will be great to have some validation (some forms.widget or just a regex expression) to attach to IP form fields. Project: horizon Series: folsom Blueprint: javascript-i18n Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/javascript-i18n Spec URL: None We have a number of user-facing messages in our javascript. These need to be internationalized. We can do this by using Django's javascript i18n support. Project: neutron Series: folsom Blueprint: lb-api-v2-support Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/lb-api-v2-support Spec URL: None Update the link bridge plugin to work with the v2 api. Project: nova Series: folsom Blueprint: libvirt-base-images-on-shared-storage Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/libvirt-base-images-on-shared-storage Spec URL: None Make use of https://blueprints.launchpad.net/glance/+spec/api-v2 -store-access in the libvirt driver to create local Qcow2 COW image that refer to a base image on shared storage instead of having to download the image from glance first. Project: nova Series: folsom Blueprint: libvirt-xml-config-apis Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/libvirt-xml-config-apis Spec URL: http://wiki.openstack.org/LibvirtXMLConfigAPIs This replaces the current Cheetah template approach for generating XML documents, with a formal configuration object model & API which is capable of serializing itself to XML & deserializing itself from XML. The result will ensure correct XML escaping, centralize the logic for generating XML improving maintainence and mean no libvirt driver code needs to know about the XML documents directly. Project: nova Series: folsom Blueprint: libvirt-xml-cpu-model Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/libvirt-xml-cpu-model Spec URL: http://wiki.openstack.org/LibvirtXMLCPUModel This introduces the ability to specify a default KVM guest CPU model on a per-host basis, to allow performance of guest machines to be optimized. It further allows the CPU model to be overriden per-disk image when registering the image with glance Project: nova Series: folsom Blueprint: lvm-disk-images Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/lvm-disk-images Spec URL: None Rationale --------- `QEmu` allows several types of storages. For local storage it is possible to use regular block device, `raw` image file or special format called `qcow2`. OpenStack offers only `raw` or `qcow2` disks. Historically our (Grid Dynamics) infrastructure was based on `qemu-kvm` with `LVM` as disk storage. When we started moving it to OpenStack based infrastructure we measured performance of `qcow2` disks. In brief, our tests show performance degradation on `qcow2` disks comparing to `LVM` is 5-50% depending on operation. The biggest difference (50%) was archived in sequential IO of very big data. Proposal -------- Add ability for administrator to choose, which type of local storage he wants to use: `raw`, `LVM` or `qcow2`. We propose to introduce a new flag `libvirt_images_type` with possible values: `raw`, `lvm`, `qcow2`, `default`. Boolean flag `use_cow_images` should be ignored, if `libvirt_images_type` is set to one of possible values, but keep working, if `libvirt_images_type` flag is not set by user. New flag `libvirt_images_volume_group` should be introduced for specifying volume group name for disks storage. Boolean option `libvirt_sparse_logical_volumes` should select which type of logical volumes will be created (sparsed with virtualsize or usual logical volumes with full space allocation). Default value for this option is `False`. Project: neutron Series: folsom Blueprint: man-support Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/man-support Spec URL: None The documentation director should contain the support of man pages. This will be beneficial for the installation and support of quantum packages. Project: neutron Series: folsom Blueprint: metaplugin Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/metaplugin Spec URL: https://docs.google.com/presentation/d/1nYwbSSl_cQt5OqlWbp_8jXiXNCB2SHfW1I4yN_0j6qs/edit#slide=id.p This plugin supports multiple plugins at same time. This plugin is for L3 connectivility between networks which are realized by different plugins. This plugin add new attribute 'flavor:id'. flavor:id correspond to specific plugin. flavor-plugin mapping could be configureable by plugin_list config. This plugin also support extensions. We can map extension to plugin by using extension_map config. Code in Review https://review.openstack.org/#/c/10181/ Devstack for metaplugin https://github.com/nati/devstack/tree/meta nova branch which has MetaBridgeDriver https://github.com/nati/nova/tree/metadriver Project: cinder Series: folsom Blueprint: migrate-nova-volumes-to-cinder Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/migrate-nova-volumes-to-cinder Spec URL: None We need a migration path for existing nova-volume users to migrate their data to cinder. The goal is existing volumes should continue to work (only api downtime - not connectivity between VMs and storage exports) Project: horizon Series: folsom Blueprint: move-keystone-support-to-django-auth-backend Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/move-keystone-support-to-django-auth-backend Spec URL: None Keystone in Horizon is currently implemented as a middleware which hacks the user object into the request. This is occasionally buggy, and causes unexpected session behavior. It also bypasses some of the expectations that Django depends on for security. Django includes a good framework for writing authentication backends, and Horizon should use these for keystone integration. This will increase the flexibility of horizon to accommodate other auth backends, and improve forward compatibility as Django evolves. Project: neutron Series: folsom Blueprint: multi-node-quantum-devstack Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/multi-node-quantum-devstack Spec URL: https://github.com/davlaps/devstack This is very important to allow people to test with non-trivial setups, and to allow CI team to do the same. Project: nova Series: folsom Blueprint: multi-process-api-service Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/multi-process-api-service Spec URL: None Currently Nova API services only spawn green threads to handle different requests (OSAPI-Compute, OSAPI-Volume, OSAPI-metadata, EC2). All green threads are actually being scheduled within one system process, which results in only one processor core can be utilized. As API requests concurrency increase, the throughput doesn't increase because requests pile-up and the response time of each request goes-up very quickly. For example, for OSAPI-Compute, we have data showing current implementation can handle <10 operation/sec no matter how many current users are sending requests. We'd propose configurable multi- process (workers) API services to tackle this issue. Simliar implementation has been added to Swift and Glance. Our internal testing of multi-process model is promising: the throughput of API services has linear gain when # of process increases. Implementation: https://review.openstack.org/#change,5762 Project: keystone Series: folsom Blueprint: multiprocess-keystone-service Design: Obsolete Lifecycle: Complete Impl: Needs Code Review Link: https://blueprints.launchpad.net/keystone/+spec/multiprocess-keystone-service Spec URL: None Currently Keystone services only spawn green threads to handle auth requests. Due to python's limitation, all green threads are actually being scheduled within one system process, which results in only one processor core can be utilized. When requests concurrency increase, the throughput doesn't increase because requests pile-up and the response time of each request goes-up very quickly. This can be a serious problem since keystone is required for other OpenStack services, such as Nova, Glance, Swift. Therefore, keystone's performance(throughput) is critical to the whole solution's performance and user experience. I'd propose configurable multi- process (workers) keystone services to tackle this issue. Similar implementation has been added to Swift, Glance and proposed to Nova. Project: cinder Series: folsom Blueprint: netapp-nfs-cinder-driver Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/netapp-nfs-cinder-driver Spec URL: None This blueprint creates a Cinder extension to map guest volumes onto files located on the NFS shares exported by NetApp Filer and for nova to mount the shares onto the compute host. Cinder.conf will point to a separate file listing available shares. This file is updatable during run time, driver will reread the file if it notices that the file has been modified. The driver will load balance between shares, allocating the file on the share with most available space. An individual file per volume is created. This driver works with NetApp ONTAP V7. NetApp onCommand v5.0 will be used to manage the filer. The goal is to provide enterprise users with highly reliable volume storage solution offering support for backend snapshot and cloning capabilities. Proposed use-case : - user sends create-volume command - cinder-volume component selects the NFS share with the most free space - cinder- volume component mounts selected NFS share and creates a file for the volume (file name will match the volume name or index). - user sends attach-volume request - nova compute volume driver mounts NFS share and attaches given file to the VM as a disk storage. - user sends create snapshot command - cinder volume component creates a snapshot from the appropriate file on on-tap by calling appropriate API on OnCommand. - user sends create volume from snapshot command - cinder volume component creates clone from the snapshot created earlier. This blueprint adds a new storage driver to Cinder and modifies nova- compute volume driver: - new volume driver for cinder will support access to NetApp NFS storage. - nova-compute volume driver is updated to allow for dynamic mounting of NFS shares on compute hosts. Project: cinder Series: folsom Blueprint: netapp-volume-driver-cmode Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/netapp-volume-driver-cmode Spec URL: None The existing NetApp iSCSI driver supports Ontap 7-mode only. NetApp will provide a second driver that supports iSCSI on Ontap Cluster- mode. The feature set will be similar to the existing driver (see: netapp-volume-driver). Project: neutron Series: folsom Blueprint: new-cli Design: Review Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/new-cli Spec URL: None Obviously needs to be updated to work with new Quantum v2.0 API From Folsom Etherpad:   CLI / Client Rewrite   What sucks now:      Read env stuffs like from the stack.rc      go here yo: http://wiki.openstack.org/QuantumStarterBugs see quantum client improvements      list-extensions: see what is rocking on the server for extensions          auto discover args and display them so the user knows they be there.     Derp     Need to do some cleanup before the One CLI to Rule Them All project is going to be far enough long to be usable for Quantum commands     CLI should query Quantum to verify which servies are available and do prevalidation (possibly even turning off switches or features, or at least having the help report that the feature is not available)     How do extensions add new commands or options? Quantum auth support: https://blueprints.launchpad.net/quantum/+spec/authorization-support- for-quantum openstackclient project: https://github.com/openstack /python-openstackclient https://launchpad.net/python- openstackclient/trunk openstack-common project: https://github.com/openstack/openstack-common.git Project: cinder Series: folsom Blueprint: nfs-files-as-virtual-block-devices Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/nfs-files-as-virtual-block-devices Spec URL: None This blueprint creates a Cinder extension to allow guest volumes to be stored on NFS shares. Each volume maps to a single file on the NFS. Cinder config file will point to separate file which contains the list of the shares. List of shares can be updated at run time. Driver will reread the list of shares if the file is modified. Driver will load balance file creation, choosing the share with the most available space to create the new volume file. Using NFS as a storage for volume files gives users additional flexibility in selection a data storage solution. NFS servers can be built into a highly scalable and reliable storage pool. This driver will support generic Linux NFS server implementation. Proposed use-case: 1. user sends create-volume command 2. cinder-volume component selects the NFS with the most free space 3. cinder-volume component mounts selected NFS share and creates file for the volume (file name should match the volume name or index). 4. user sends attach-volume request 5. nova compute volume driver mounts NFS share and attaches given file to the VM as a disc storage. New volume driver is added to Cinder and nova- compute volume driver is modified: 1. new volume driver for cinder is added to support NFS Linux server. 2. nova-compute volume driver is updated to dynamically mount appropriate NFS shares on the compute host. Project: nova Series: folsom Blueprint: no-db-messaging Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/no-db-messaging Spec URL: http://wiki.openstack.org/NoDBMessaging Right now, the communication between components in Nova occurs through rpc.cast and rpc.call (which uses rabbitMQ to pass messages). In many cases we only pass the id of the object in the message, and the component on the other end looks up the object in the database. This means we are essentially using the database to pass data between components In preparation for separating the services into separate projects, it is important that we make sure that all relevant data is passed between components in the message. This will pave the way for the different components to have separate databases. Project: neutron Series: folsom Blueprint: non-polling-dhcp-impl Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/non-polling-dhcp-impl Spec URL: None We need to change the existing DHCP implementation to no longer use polling. Instead, it will need to get notifications/calls from the main quantum plugin when an IP is allocated/deallocated, or other dhcp relevant fields change. Ideally, this would use a generic notifications API for learning about changes to Quantum resources. Project: nova Series: folsom Blueprint: nova-notifications Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-notifications Spec URL: http://wiki.openstack.org/SystemUsageDataEvol Nova administrators want data on system usage for billing, chargeback, or monitoring purposes. We need notifications in the lifecycle of volumes, images and IPs Project: nova Series: folsom Blueprint: nova-orchestration Design: Obsolete Lifecycle: Complete Impl: Unknown Link: https://blueprints.launchpad.net/nova/+spec/nova-orchestration Spec URL: http://wiki.openstack.org/NovaOrchestrationSpecForFolsom Nova needs to be able to monitor and manage long-running transactions. For example, when creating 1,000 servers, it may be necessary to create a build plan, retry failed builds, refresh the plan, and possibly even roll back the entire transaction if it cannot be completed rapidly enough. To do this, an orchestration service is proposed that can monitor workflows around Nova events and transactions. Project: nova Series: folsom Blueprint: nova-rootwrap-pluggable-filters Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/nova-rootwrap-pluggable-filters Spec URL: None Move nova-rootwrap filter definition to configuration files. This will allow to plug new commands needed by plug-ins, and support other configuration options. Project: horizon Series: folsom Blueprint: nova-volume-optional Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/nova-volume-optional Spec URL: None Nova Volume is moving towards being a separate project/service, and since it's taken the first step of being a separate registered service in Keystone's catalog we can now incorporate its pieces in an optional fashion as we do with Swift and Quantum. Project: nova Series: folsom Blueprint: novaplugins Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/novaplugins Spec URL: http://wiki.openstack.org/novaplugin Tune up the interface for adding external features to Nova; add convenience classes to facilitate creation and packaging of same. Project: nova Series: folsom Blueprint: os-api-network-associate Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/os-api-network-associate Spec URL: None Nowadays networks are associated with projects automatically during launch of an instance. The network is chosen rather randomly. OS API should support association of given network and project. URI: v1.1/{tenant_id}/os-networks/add Method: POST Body: {     "id": "" } Response body: empty Response code: 202 If the given network UUID is None, a random free network will be chosen. Sample request: curl -X 'POST' 'http://main- node:8774/v1.1/45d2e66674b647c2bee1d1f18ae64e93/os-networks/add -H 'Content-Type: application/json' -H 'X-Auth-Token: b4be16290db84726bc71d10f0947aa13' -d '{"id": "44b6f3d2-ed5f-4711-b2fa- 96e29cf13ac0"}' Project: nova Series: folsom Blueprint: os-api-network-create Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/os-api-network-create Spec URL: None nova/api/openstack/compute/contrib/networks.py contains NetworkController class. It supports list, get, and delete operations for networks but `create` is not implemented:     def create(self, req, id, body=None):         raise exc.HTTPNotImplemented() This call could be implemented in the same way as in nova-manage CLI utility (get default arguments from configuration etc.). It should return a list of new networks. Supported arguments for the call should be passed in a dictionary: - string: "bridge", "bridge_interface", "cidr", "cidr_v6", "dns1", "dns2", "fixed_cidr", "gateway", "gateway_v6", "label", "multi_host", "priority", "project_id"; - integer: "network_size", "num_networks", "vlan_start", "vpn_start". Sample request: curl -X 'POST' 'http ://main-node:8774/v1.1/45d2e66674b647c2bee1d1f18ae64e93/os-networks' -H 'User-Agent: python-openstackclient-base' -H 'Content-Type: application/json' -H 'X-Auth-Token: b4be16290db84726bc71d10f0947aa13' -d '{"network": {"vlan_start": 234, "cidr": "10.70.105.0/24", "label": "net234"}}' Response: {"networks": [{"bridge": "br234", "vpn_public_port": 1000, "dhcp_start": "10.70.105.3", "bridge_interface": "eth0", "updated_at": null, "id": 66085e78-8f6-4a26-b16c-4b1f55901fbd", "cidr_v6": null, "deleted_at": null, "gateway": "10.70.105.1", "label": "net234", "project_id": null, "vpn_private_address": "10.70.105.2", "deleted": false, "vlan": 234, "broadcast": "10.70.105.255", "netmask": "255.255.255.0", "injected": false, "cidr": "10.70.105.0/24", "vpn_public_address": null, "multi_host": false, "dns1": null, "host": null, "gateway_v6": null, "netmask_v6": null, "created_at": "2012-07-11 07:42:06.155778"}]} Project: neutron Series: folsom Blueprint: ovs-api-v2-support Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/ovs-api-v2-support Spec URL: None We will need to update the OVS plugin to work with the new v2 plugin API. This will likely be done by subclasses the database Plugin base class, which does almost all of the non-agent work. We will likely only need to update the vlan_bindings table (and rename it to context?) Project: neutron Series: folsom Blueprint: per-net-dhcp-enable Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/per-net-dhcp-enable Spec URL: None Right now, DHCP is either run on every network in a deployment, or none of the networks. We woud like the owner of the network to be able to enable or disable DHCP on a per-network basis. This could take the form of an API extension that expose a 'enable-dhcp' attribute on a network. Project: keystone Series: folsom Blueprint: pki Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/pki Spec URL: http://wiki.openstack.org/PKI Thus, this blueprint describes an overall PKI approach for securing an OpenStack deployment. Authentication in OpenStack is a two part mechanism. The first stage is when the user makes the initial authentication to Keystone, which results in the issue of a token. The second is the use of the token to provide single sign on and delegated authentication throughout the OpenStack cluster. PKI can improve the security of the first stage. It can both help security and scalability of the second. Project: nova Series: folsom Blueprint: powervm-compute-driver Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/powervm-compute-driver Spec URL: None Enable IBM PowerVM virtualization on Openstack which is going allow Logical Partition (LPAR) deployment and management. PowerVM is the virtualization solution for AIX, IBM i and Linux environments on IBM POWER technology. For more information about PowerVM and features refer to: http://www-03.ibm.com/systems/power/software/virtualization/ features.html http://www.redbooks.ibm.com/abstracts/sg247940.html Project: horizon Series: folsom Blueprint: progress-bar-javascript Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/progress-bar-javascript Spec URL: None The progress bar javascript currently used in the instance modal should be abstracted and broken out to not heavily rely on that modal. Instead it should be usable any time someone might want progress bars that animate to user input in a form. Project: nova Series: folsom Blueprint: project-specific-flavors Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/project-specific-flavors Spec URL: None Currently flavor (instance type) settings in Nova are shared by all projects. However, there're cases in private cloud deployments that project specific flavor settings are necessary. In contrast to global flavor setting, project specific flavor is visible and available for specific project only. * flavor type is public by default, which is accessible to all projects * non-public flavor type (project specific flavor, or private flavor) is only accessible to those project on the access list, and invisible to all other projects * admin user is able to query all flavor types ( public flavor by default ) * project members could list all public flavor types and current project specific flavor types API Extension -- GET v2/{tenant_id}/flavors/{flavor_id}/os-flavor-access list of project with access to flavor POST v2/{tenant_id}/flavors/{flavor_id}/action add / remove project to flavor access list Also implements client bindings for project specific flavor management Command Use -- nova flavor- access-list --flavor flavorid return access list of specified flavorid nova flavor-access-add flavorid projectid add project to private flavor's access list nova flavor-access-remove flavorid projectid remove project from private flavor access list Project: neutron Series: folsom Blueprint: provider-networks Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/provider-networks Spec URL: None In addition to dynamically creating brand new virtual networks, there are use cases where Quantum needs to be told about existing L2 networks in the data center. Some plugins may already support this, but there should be a common API or extension allowing existing VLANs or other types of networks to be registered with Quantum, after which ports can be created, etc.. An extensible way to describe the existing network is needed, and an error should result if the plugin is not able to handle the described network. The first phase of this blueprint will implement provider VLANs in the linuxbridge and openvswitch plugins as follows: * Extend the plugins' create_network functions with an optional argument specifying the VLAN tag. * Extend the python-quantumclient CLI to allow this argument to be passed to create_network. * Extend the plugins' get_network_details functions to return VLAN tags that have been assigned either explicitly or dynamicly. * Add configurability of the range from which VLAN tags are dynamically allocated to the openvswitch plugin. The linuxbridge plugin already has this. * Since there is no authorization mechanism in quantum yet, comments in the above will indicate where admin priviledges need to be checked. * Make sure the plugins' delete_network functions properly handle deleting networks whose VLAN tags do not fall into the range from which VLAN tags are dynamically allocated. Once the support for provider VLANs has been reviewed and merged, support for provider flat networks will be added to the same plugins in a second phase following a similar approach. Since nova networking parity requires supporting multiple physical flat networks, the plugins will also be enhanced to support VLANs (and GRE tunnels for OVS?) over multiple distinct physical networks. Details will be forthcoming. Project: cinder Series: folsom Blueprint: python-cinder-client Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/python-cinder-client Spec URL: None Currently the volume feature is used via python-novaclient's volume code. Cinder will need a stand-alone client. Cinder client should work against Nova-Volume endpoint (that exists in essex) and Cinder endpoint (in folsom) Currently there aren't any changes in the API. Project: horizon Series: folsom Blueprint: python-glanceclient Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/python-glanceclient Spec URL: None Installing Glance (which in turn installs Swift and Keystone) just to use the client is terrible and needs to go away as soon as possible. Project: neutron Series: folsom Blueprint: quantum-agent-common Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-agent-common Spec URL: None Some Quantum plugins (including all current open source plugins) use "agents" that run on the compute host. In many cases, these agents need to do similar things even for different plugins (e.g., talk to open vswitch/linux-bridge, setup iptables rules, or invoke a DHCP server, access DB for information about security groups, etc.). We want to be able to leverage shared code for this. The idea is that this is a python library with only very basic dependencies that most/all agents will depend on. Project: neutron Series: folsom Blueprint: quantum-api-quotas Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-api-quotas Spec URL: None API Quotas. Service providers need to be able to limit the set of resources a tenant can consume in a flexible way. For example, it might limit each tenant to creating 10 networks by default, with the ability to increase this quota for select tenants who request it. Nova has a framework for Quotas, which we can leverage, ideally using code that is in openstack-common. Project: neutron Series: folsom Blueprint: quantum-client-l3-floating-ip Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-client-l3-floating-ip Spec URL: None Will need quantum client lib and CLI support for L3 and floating IPs. Project: neutron Series: folsom Blueprint: quantum-dhcp Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-dhcp Spec URL: None Tracks work to support DHCP in Quantum independent of nova (since nova-network will be going away when Quantum is in use). DHCP support in Quantum will implemented over F2 and F3. During F2 the focus will be on integrating with the new v2 API and delivering an implementation that works via a polling agent. The focus during F3 will be on optimization and making the implementation more resilient to failure. Project: neutron Series: folsom Blueprint: quantum-horizon Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-horizon Spec URL: None This is a proxy blueprint for work that will be done in Horizon to integrate with Quantum. This work has a dependency on the new v2.0 Quantum API. Folsom Summit Etherpad: http://etherpad.openstack.org/FolsomHorizonQuantumIntegration Project: neutron Series: folsom Blueprint: quantum-iptables-manager Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-iptables-manager Spec URL: http://wiki.openstack.org/quantum-iptables-manager The idea behind this blueprint is create a python iptables module implementing a generic iptables abstraction, this will be useful for every plugin based on iptables. This module works with ipv4 and ipv6, supporting use of stateless or stateful firewalls. Project: neutron Series: folsom Blueprint: quantum-l3-fwd-nat Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-l3-fwd-nat Spec URL: https://docs.google.com/document/d/1RqvZ50k60Dd19paKePHLHbk1x1lN2fXSXyWuC9OiJWI/edit Since nova-network is going away, for nova parity, we need a Quantum API to allow the basic L3 + NAT forwarding provided by the VlanManager in Nova, along with the floating IP capability that builds on top of this. Project: neutron Series: folsom Blueprint: quantum-nec-openflow-plugin Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-nec-openflow-plugin Spec URL: None NEC OpenFlow Plugin talks to OpenFlow Controller and create/modify/delete Layer-2 logical networks on an OpenFlow enabled network. The interface between the Quantum plugin and OpenFlow Controller is RESTful API. This API is supported by two implementations: Tream Sliceable Switch (OSS) and NEC ProgrammableFlow Controller (NEC Commercial Product). This plugin consists of two components: "Plugin" and "Agent". * Plugin: It processes Quantum API calls and controls OpenFlow controller to handle logical networks on OpenFlow enabled network. * agent: It runs on each compute node. It gathers a mapping beween a VIF and a switch port from local Open vSwitch and reports it to the plugin. http://wiki.openstack.org /Quantum-NEC-OpenFlow-Plugin Project: neutron Series: folsom Blueprint: quantum-notifications Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-notifications Spec URL: http://wiki.openstack.org/QuantumNotifications Quantum needs a notification system that will be used to push logging and usage information. It appears that openstack.common.notifier (https://github.com/openstack/openstack- common/tree/master/openstack/common/notifier) has a lot of the base code used by nova and other openstack services for notifications already. Would be great if we could leverage this. Project: nova Series: folsom Blueprint: quantum-nova-network-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/quantum-nova-network-api Spec URL: None Plan: When using Quantum with nova, network hosts/nodes are unnecessary. I propose making the network api configurable via flag (which already exists), and writing a quantum api (nova/network/quantum/api.py) which is able to take the place of both the existing network API and the quantum manager. In this case compute would be making calls directly to Quantum/Melange through the network API. Project: neutron Series: folsom Blueprint: quantum-nvp-plugin-v2 Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-nvp-plugin-v2 Spec URL: None Update the Nicira NVP plugin to support the v2 Quantum API. Project: horizon Series: folsom Blueprint: quantum-public-network Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/quantum-public-network Spec URL: None Quantum's public network management has finally reached a stable point and supporting it in Horizon would be great. Project: neutron Series: folsom Blueprint: quantum-system-functional-tests Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-system-functional-tests Spec URL: http://wiki.openstack.org/QuantumSystemAndFunctionalTesting Now using the requirement to track getting a basic exercise.sh script into devstack that could be run as part of basic SmokeTests. Project: neutron Series: folsom Blueprint: quantum-v2-public-networks Design: Pending Approval Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/quantum-v2-public-networks Spec URL: http://wiki.openstack.org/Quantum/v2-public-networks?action=AttachFile&do=view&target=QuantumPublicNetworks.pdf A common networking use case is that a service provider has a network that all tenants should have access to. for example, a network that provides access to the Internet. Thus, tenants must have the ability to view the set of available "public" networks, but not modify them (this is likely similar to glances notion of a "public image", so perhaps we should look at that for inspiration). Another twist is that service providers are likely to want to limit the set of things a tenant can do on this port, more so than what a tenant can do on a private network (where they can in many cases, only hurt themselves and don't ever conflict with other tenants). For example, it is likely that a tenant shouldn't be able to choose its own mac address on a shared network, or consume an arbitrary number of IP addresses from the subnet (in fact, one might be enough). However, the provider probably does want to let the tenant control the security groups on these ports, and view packet statistics. So we'll need some way to indicate which port attributes can be viewed and modified for such public ports. Another example is that while the tenant can see the existence of the public network, it should not be able to list the set of ports on that public network, except for its own ports. Note: it is likely that this blueprint will require changes to quantum-server, quantumclient, and nova. Project: horizon Series: folsom Blueprint: quantum-workflow-integration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/quantum-workflow-integration Spec URL: None Now that workflows exist, we can start adding optional capabilities. Quantum network configuration should be part of this. Project: nova Series: folsom Blueprint: quota-classes Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/quota-classes Spec URL: http://wiki.openstack.org/QuotaClass Creation of a "Quota Class" system to augment quotas. This would enable an entire class of quotas to be applied to a project, rather than having to individually set the applicable quotas for that project. Project: nova Series: folsom Blueprint: quota-refactor Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/quota-refactor Spec URL: None Refactor quotas to allow for resource registration; atomic updates; quota reservations; and plugability of quota backend storage. A Resource class is created for resource registration and a QuotaDriver class is created for plugability; quotas are managed via a global QUOTAS object (instance of class Quota) in parallel with the configuration object. (A global variable is not ideal here, but in the absence of a better alternative, it was the obvious choice.) Project: horizon Series: folsom Blueprint: readd-quantum-support Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/readd-quantum-support Spec URL: None Re-add support for Quantum to Horizon Project: glance Series: folsom Blueprint: refactor-db-layer Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/refactor-db-layer Spec URL: None The glance DB code has grown organically over time and could benefit from a comprehensive re-visit. Project: nova Series: folsom Blueprint: remove-deprecated-auth Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/remove-deprecated-auth Spec URL: None the old auth system was marked deprecated in diablo. We need to remove it for the folsom release Project: cinder Series: folsom Blueprint: remove-extra-dbapi-methods Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/remove-extra-dbapi-methods Spec URL: None Cinder was started by copying nova including the database. There's a lot of cleanup including removing unused tables, (blueprint initial- db-cleanup), and this is the follow on to remove associated db.api methods and associated test cleanup/removal. Project: horizon Series: folsom Blueprint: remove-horizon-time-module Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/remove-horizon-time-module Spec URL: None Horizon's time module should either go away or should use openstack.common.timeutils in place of the code in horizon/time.py. Project: nova Series: folsom Blueprint: remove-nova-direct-api Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/remove-nova-direct-api Spec URL: None Due to our policy checking and loading objects before sending them into compute.api, this no longer functions. Probably wouldn't be too hard to fix it, but clearly no one is using it so lets axe it. Project: nova Series: folsom Blueprint: remove-old-flagfile Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/remove-old-flagfile Spec URL: None Nova still uses flagfile internally (wrapping cfg), when glance and keystone move to new cfg options. Most of the code it's shared. Path: 1.- Remove flagfiles support for nova, and use cfg options 2.- Move cfg options code from nova, glance and keystone to openstack-common Project: neutron Series: folsom Blueprint: remove-v1-related-code Design: Discussion Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/remove-v1-related-code Spec URL: None We have decided to remove this code in F-3 Code that would be removed: - v1 API code (included) - v1 plugin code   * OVS (included) * LB (included)   * cisco (sumit doing this? or already done?)   * NVP (part of NVP v2 patch)   * RYU (included) - v1 db code (included) - v1 unit tests (included) - old QuantumManager in nova-network (included - separate review) - v1 in CLI + client lib. (done) - v1 code in devstack (done) Project: horizon Series: folsom Blueprint: scaffolding Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/scaffolding Spec URL: None Now that Horizon has a first-class extensibility model new users should be able to generate a default dashboard and/or panel within Horizon with a rails-like scaffold command that creates the necessary views/templates/folders/configs for creating a new dashboard or panel. Would be great to optionally specify a default tab group or table as well. Project: neutron Series: folsom Blueprint: scalable-agent-comms Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/scalable-agent-comms Spec URL: None The current openvswitch and linuxbridge plugins have agents on each compute node that periodically poll their DBs looking for relevant state changes. This requires a DB connection from each compute node, and polling results in significant average latency in responding to state changes. Nova's RPC mechanism, which is being moved to openstack-common and supports various messaging mechanisms (rabbitmq, qpid, zeromq), should be used for Quantum server<->agent communications in place of DB polling. Project: nova Series: folsom Blueprint: scheduler-resource-race Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/scheduler-resource-race Spec URL: http://wiki.openstack.org/SchedulerRaceReduction The scheduler is subject to a race condition which can cause it to incorrectly identify available resources on a particular compute host. The problem occurs if multiple scheduler instances/threads concurrently issue an instance build request (i.e. run_instance) to the same compute host. This situation may oversubscribe the given compute host and cause one or more run_instance requests to fail. Project: neutron Series: folsom Blueprint: simplify-ovs-tunnel-mgmt Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/simplify-ovs-tunnel-mgmt Spec URL: None Currently, the OVS plugin in tunnel mode requires that each compute host have a manually created file that contains all tunnel IPs in the deployment, and that all agents are restarted if that file needs to be updated. We'll change this so that each agent "registers" its IP address in the plugin database, and that all other agents feed off this centralized database, creating tunnels as new IPs appear in the database. Note: there's no good way to remove an IP if the the host goes away. We may need to consider having an admin utility that can purge values from the database. For the time being, items can be removed from the DB directly. Project: keystone Series: folsom Blueprint: start-keystone-i18n Design: Discussion Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/start-keystone-i18n Spec URL: None Start putting i18n effort into Keystone to get basic strings translated Project: horizon Series: folsom Blueprint: summation-row Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/summation-row Spec URL: None There are scenarios in which it's helpful to display a summation row on the datatable (such as when totaling storage). Having this option easily configurable in Horizon's core codebase makes it available to everyone rather than making it a one-off. Project: horizon Series: folsom Blueprint: swift-folders Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/swift-folders Spec URL: None Support for Swift nested objects (pseudo folders) within Dashboard. Project: keystone Series: folsom Blueprint: swift-middleware-add-overrides-feature Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/swift-middleware-add-overrides-feature Spec URL: None For tempauth or staticweb swift middleware the auth middleware needs to allow to bypass authorization if they are specified by those middlewares. Project: glance Series: folsom Blueprint: swift-tenant-specific-storage Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/swift-tenant-specific-storage Spec URL: http://wiki.openstack.org/GlanceSwiftTenantSpecificStorage We need to be able to store image data in the authenticated user's swift account. Project: horizon Series: folsom Blueprint: swift-ui-improvements Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/swift-ui-improvements Spec URL: None Implement Paul Tashima's design for Swfit objects and containers: https://speakerdeck.com/u/paultashima/p/openstack-dashboard- wireframes-11292011?slide=12 Project: horizon Series: folsom Blueprint: swiftclient Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/swiftclient Spec URL: None Now that there is an official python-swiftclient library we should make use of that instead of cloudfiles. Project: horizon Series: folsom Blueprint: switch-to-cinder-client Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/switch-to-cinder-client Spec URL: None Cinder-client should work against both nova-volumes and the new extracted cinder service. We should switch to using the cinder-client library for interaction with the volume services. Project: nova Series: folsom Blueprint: task-management Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/task-management Spec URL: http://wiki.openstack.org/TransactionalTaskManagement Tasks in Nova such as launching instances are complicated and error prone. Currently there is no systematic, reusable way to keep track of the distributed task executions. There is also no mechanism to know which tasks are currently using what resources. Task management is implicitly assumed to be VM state management. This blueprint proposes to build a highly available service to offer first-class APIs to task and resource lock management. Project: horizon Series: folsom Blueprint: tenant-creation-workflow Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/tenant-creation-workflow Spec URL: None There should be a workflow that allows the creation of a new tenant along with the addition of new users and assignment of roles for those users all in one place. Project: neutron Series: folsom Blueprint: test-agent Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/test-agent Spec URL: https://docs.google.com/document/d/1yQGb-GhNNeSzlMtsRW14AjaYaXM-iShaNJCcg0GJltQ/edit Agent for test This agent plugs network. Then check connection inside network. And also test-agent can be daemon to accept connection. Project: horizon Series: folsom Blueprint: timezones Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/timezones Spec URL: None As part of the L10n efforts and just in the name of good user experience, Horizon should be 100% timezone-aware. The support is built into Django. We just need to refactor to use it. Project: horizon Series: folsom Blueprint: transition-to-lesscss Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/transition-to-lesscss Spec URL: None We need to transition Horizon to LESS. This involves replacing all of the .css files with .less files, changing the selectors when necessary/desired, updating Devstack, and updating the CI to be able to run Horizon with LESS as a requirement. Project: horizon Series: folsom Blueprint: translation-documentation Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/translation-documentation Spec URL: None Now that the community is moving forwards with translation processes, there should be a strong core of information about how to do translation and internationalization, the tools we use, and our processes around it. See also: https://www.transifex.net/projects/p/openstack/ Project: nova Series: folsom Blueprint: trusted-computing-pools Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools Spec URL: http://wiki.openstack.org/TrustedComputingPools The feature will allow cloud hosting providers to build trusted computing pools based on H/W-based security features, such as Intel Trusted Execution Technology (TXT). Combining attestation done by a separate entity (i.e. "remote attestation"), the providers can ensure that verified measurement of software be running in the cloud, thus they can establish the foundation for the secure cloud stack. Such remote attestation services can be developed by using SDK that we plan to provide. Policy-based scheduling (in a separate blueprint) or a simpler one will be used to find "trusted" nodes. Project: nova Series: folsom Blueprint: update-flavor-key-value Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value Spec URL: http://wiki.openstack.org/FlavorKeys Enhance nova-manage so that it can add and delete key/value pairs for flavors. Project: neutron Series: folsom Blueprint: update-ryu-plugin-for-v2 Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/update-ryu-plugin-for-v2 Spec URL: None Update Ryu plugin for Quantu v2 API and Ryu update. This will include - Ryu plugin supports for Quantum v2 api (and Drop Qauntum v1 api support) - Ryu plugin supports for Ryu new feature. (GRE tunneling) The patch will come as several phases. Probably v2 support first, then gre support. dropping v1 support as last patch. Project: cinder Series: folsom Blueprint: update-solidfire-driver Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/update-solidfire-driver Spec URL: None Updated the SolidFire driver to include snapshot and qos functionality. QoS can now be set using metadata on volume creation either as a preset level (sf-qos:slow, sf-qos:medium, sf-qos:fast sf- qos: performant) Alternately specific values can be set by specifying each of the individual k/v pairs (minIOPS:500, maxIOPS:1000, burstIOPS:1000) Project: horizon Series: folsom Blueprint: upgrade-pep8 Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/upgrade-pep8 Spec URL: None Currently we have to force Horizon to use PEP8 1.1 in order to pass. We need to bite-the-bullet and go through and fix the few hundred whitespace complaints the newer PEP8 versions have (specifically, the newest one: 1.3) Project: neutron Series: folsom Blueprint: use-common-cfg Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/use-common-cfg Spec URL: None The Quantum server and agents should use openstack.common.cfg in place of the code in quantum/common/config.py. Other OpenStack services, including nova and glance, are using this. Also, the openstack-common rpc that will likely be used for the scalable-agent-comms BP is expected to depend on openstack.common.cfg. Note that introducing dependencies on openstack-common into quantum agents might have implications for running agents in XenServer dom0, where only python 2.4 is available. It may be necessary to investigate whether the openstack-common code can be made to run on python 2.4, or whether there are viable solutions to avoid running quantum agents in dom0. Project: glance Series: folsom Blueprint: use-common-importutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/use-common-importutils Spec URL: None Glance should use openstack.common.importutils in place of the code in glance/common/utils.py. Project: keystone Series: folsom Blueprint: use-common-importutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/use-common-importutils Spec URL: None Keystone should use openstack.common.importutils in place of the code in keystone/common/utils.py. Project: neutron Series: folsom Blueprint: use-common-importutils Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/use-common-importutils Spec URL: None Quantum should use openstack.common.importutils in place of the code in quantum/common/utils.py. Project: keystone Series: folsom Blueprint: use-common-jsonutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/use-common-jsonutils Spec URL: None Keystone should use openstack.common.jsonutils in place of the code in the standard json module. Project: nova Series: folsom Blueprint: use-common-jsonutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/use-common-jsonutils Spec URL: None Nova should use openstack.common.jsonutils in place of the code in nova/utils.py or the standard json module. Note that rpc/matchmaker.py and scheduler/scheduler_options.py uses json.load, therefore the json package needs to be imported in these modules. Project: horizon Series: folsom Blueprint: use-common-jsonutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/use-common-jsonutils Spec URL: None Horizon should use openstack.common.jsonutils in place of the code in the standard json module. Project: neutron Series: folsom Blueprint: use-common-jsonutils Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/use-common-jsonutils Spec URL: None Quantum should use openstack.common.jsonutils in place of the code in the standard json module. Project: glance Series: folsom Blueprint: use-common-timeutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/glance/+spec/use-common-timeutils Spec URL: None Glance should use openstack.common.timeutils in place of the code in glance/common/utils.py. Project: keystone Series: folsom Blueprint: use-common-timeutils Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/keystone/+spec/use-common-timeutils Spec URL: None Keystone should use openstack.common.timeutils in place of the code in keystone/common/utils.py. Project: horizon Series: folsom Blueprint: use-template-loader Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/use-template-loader Spec URL: None The horizon template loader can discover template directories in panels, allowing a much more logical grouping of template with their respective panels. This prevents us from duplicating the entire dashboard structure in the dashboard's templates directory, too. It's very nearly a clean move, too. Almost no code will need to be changed. Project: neutron Series: folsom Blueprint: v2-api-melange-integration Design: Review Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/v2-api-melange-integration Spec URL: http://etherpad.openstack.org/quantum-v2-melange-integration Fold melange and its IPAM into Quantum. Optionally turn it on/off and allow queries to be satisfied through the information it has to store anyway. Key deliverables: - Proposal for v2.0 Quantum API which is based on Quantum v1.1 API, but with enhancements to include basic IPAM constructs from Melange. - Port existing Melange code over to Quantum, with design for how it interacts with existing Quantum plugin model. - Update unit tests to use new v2.0 API - Update other functional tests to use v2.0 API. - Documentation of new API and workflow. Project: neutron Series: folsom Blueprint: v2-quantum-devstack-excercise-scripts Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/neutron/+spec/v2-quantum-devstack-excercise-scripts Spec URL: None devstack excercise scripts (quantum and otherwise) will need to be updated to use quantum v2. Project: nova Series: folsom Blueprint: versioned-rpc-apis Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/versioned-rpc-apis Spec URL: None The existing rpc API is pretty lightweight and seems to work quite well. One limitation is that there is nothing provided to help with different versions of services talking to each other. It may work … or it may not. If it doesn’t, the failure you get could be something obvious, or it could be something really bad and bizarre where an operation fails half-way through, leaving things in a bad state. The end goal with this effort will be to make sure that as you upgrade from Essex to Folsom, any messages originating from an Essex service can and will be correctly processed by a Folsom service. If that fails, then the failure should be immediate and obvious that a message was rejected due to a version issue. Project: nova Series: folsom Blueprint: virt-driver-cleanup Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/virt-driver-cleanup Spec URL: None The nova.virt drivers currently aren't fully dynamic and use the connection_type and a static list of known drivers in loading. We should clean this up so that drivers are fully dynamically loaded using the openstack commons importutils, and let users specify drivers by class name in nova.conf. Additional cleanup and refactoring of the virt drivers will be done to make driver class naming consistent and predictable. Project: nova Series: folsom Blueprint: volume-decoupling Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/volume-decoupling Spec URL: None Remove remaining coupling between nova-compute and nova-volumes so cinder can run stand-alone Project: horizon Series: folsom Blueprint: volume-types Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/volume-types Spec URL: None Cinder supports a "volume types" API that Horizon should expose when Cinder is available in the service catalog. Project: horizon Series: folsom Blueprint: workflows Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/horizon/+spec/workflows Spec URL: None Supporting multi-step workflows (e.g. select image -> create keypair -> launch) is going to be a key part of Horizon's usability. We need to create a reusable component with a simple, straightforward API that abstracts all the complexity involved in this and makes it not only easy to use from the end-user's standpoint, but easy to build for developers. This blueprint would likely be a significant milestone for the Folsom release cycle, and needs significant design work before any development is begun. Project: nova Series: folsom Blueprint: xenapi-boot-from-volume Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-boot-from-volume Spec URL: None The XenServer driver doesn't deal with block_device_mapping. In order to support boot_from_volumes, it needs to parse the block device mapping info and connect to the required volumes. It also needs to clean up the volumes properly on terminate. Project: nova Series: folsom Blueprint: xenapi-live-block-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-live-block-migration Spec URL: None Look at support live migration, with "block migration". This means local EXT -> local EXT (i.e. without the need for shared storage). This depends on Stroage XenMotion feature of XCP 1.6 (not yet released) Project: nova Series: folsom Blueprint: xenapi-live-migration Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-live-migration Spec URL: http://wiki.openstack.org/xenapi-live-migration libvirt/KVM has support for live-migration between hosts. XenApi support needs to be added. This excludes block migration. Project: nova Series: folsom Blueprint: xenapi-network-info-model Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenapi-network-info-model Spec URL: None There is a network info model which nova uses to pass network info around. This model is currently not being used by the virt layer. This causes certain problems due to the limitations of the original network_info format and related expectations for ipv4 subnet information always being included. This blueprint specifies that the xenapi should be improved to work with the network info model. Project: nova Series: folsom Blueprint: xenstore-metadata Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/xenstore-metadata Spec URL: None Provide support for placing instance metadata—both user and system—into xenstore. The interesting piece is notifying hypervisors of changes to the user metadata. Project: cinder Series: folsom Blueprint: zadara-volume-driver Design: New Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/cinder/+spec/zadara-volume-driver Spec URL: None Add support for using VPSA arrays as a backend for Cinder volume service Project: nova Series: folsom Blueprint: zeromq-rpc-driver Design: Approved Lifecycle: Complete Impl: Implemented Link: https://blueprints.launchpad.net/nova/+spec/zeromq-rpc-driver Spec URL: http://wiki.openstack.org/Nova/ZeroMQIntegrationSpec Now that there is a clean abstraction for different RPC drivers, we need to implement a few alternatives. The first proposed additional RPC driver will be one to work against a ZeroMQ based server that can replace RabbitMQ. I have a working prototype of this which I'll polish off and post as a branch for this blueprint. The ZeroMQ client will faithfully replicate the way the RabbitMQ semantics work for the client, but they'll speak to a different server. The initial cut of the server will be *very* simple and *not* for production. A subsequent blueprint can then turn into a small server for this purpose based on the initial prototype.