2ae10ce522
The placement API will initially host resource provider information and then will grow to provide a full placement service. Eventually it will be fully extracted from Nova. To facilitate that extraction, this service is being developed with few ties to existing nova.wsgi structures. Instead it uses relatively plain WSGI apps that are: * uses the Routes library with declarative mapping defined in ROUTE_DECLARATIONS * basic wsgi apps, with webob and the request class, for each handler define as functions * does not use a paste-ini file to compose middleware, instead code which minimally inspects the oslo config to know how to adjust middleware (in the initial case choosing an auth_strategy) Many of these "features" will be demonstrated in commits that follow this one that enable specific behaviors for resource providers and their inventories. In order to ensure that this change can be merged in an atomic fashion it includes microversion support that was previously in its own commit. The microversion_parse library is used in a WSGI middleware to parse incoming microversion headers and place the determined value into the WSGI environment at the 'placement.microversion' key. Response headers are adjusted to add the required outgoing headers as described in: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html If a client requests an invalid microversion, they will receive a 400 response. If the microversion is of a valid form but not available, they will received a 406 response. The format of that response is dependent on the accept header of the request. If it is JSON, the min and max available microversions are presented. A request to '/' will return version discovery information. Thus far nothing else is done with the microversion information. It is there for when we need it in the future. For now everything is version 1.0. The groundwork for using gabbi to test the API is in place in nova/tests/functional/api/openstack/placement. The gabbi tests are included in the functional target. To run just the placement tests it is possible to run 'tox -efunctional placement'. Change-Id: Icb9c8f7a1fa8a9eac66c2d72f4b7e4efd4e1944f Partially-Implements: blueprint generic-resource-pools |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| nova | ||
| plugins/xenserver | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bandit.yaml | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tests-py3.txt | ||
| tox.ini | ||
README.rst
OpenStack Nova README
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of virtualization technologies, including KVM, Xen, LXC, VMware, and more. In addition to its native API, it includes compatibility with the commonly encountered Amazon EC2 and S3 APIs.
OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.
Nova primarily consists of a set of Python daemons, though it requires and integrates with a number of native system components for databases, messaging and virtualization capabilities.
To keep updated with new developments in the OpenStack project follow @openstack on Twitter.
To learn how to deploy OpenStack Nova, consult the documentation available online at:
For information about the different compute (hypervisor) drivers supported by Nova, read this page on the wiki:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers wishing to work on the OpenStack Nova project should always base their work on the latest Nova code, available from the master GIT repository at:
Developers should also join the discussion on the mailing list, at:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests. Further developer focused documentation is available at:
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst file.
-- End of broadcast