09f2d4d5ec
In Mitaka, we began to create and persist a RequestSpec object every time a new instance was requested. Given that instances that were created before that commit do not have a related RequestSpec, we needed to check every time in the conductor methods whether the instance had a request spec associated with it. Now that we are in Newton, we can provide an online data migration script that iterates over all the instances (using a marker), verify if the RequestSpec object is created, and if not, try to persist into that object the legacy fields we already know. The marker uses the request_specs table for persisting itself, and yes this is a hack, but that's the only solution we agreed for making sure we were not looping every time on all the instances (which would be a performance problem). When we finish looping over the instances, we keep that marker so that the next call to that migration script would not again iterate over all the instances (using the limit). Change-Id: I61b9b50436d8bdb8ff06259cc2f876502d688b91 Partially-Implements: blueprint check-destination-on-migrations-newton |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| nova | ||
| plugins/xenserver | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| babel.cfg | ||
| bandit.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tests-py3.txt | ||
| tox.ini | ||
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