a80eb82f67
In the instance_create DB API method, it ensures the (legacy) default security group gets created for the specified project_id if it does not already exist. If the security group does not exist, it is created in a separate transaction. Later in the instance_create method, it reads the default security group back that it wrote earlier (via the same ensure default security group code). But since it was written in a separate transaction, the current transaction will not be able to see it and will get back 0 rows. So, it creates a duplicate default security group record if project_id=NULL (which it will be, if running nova-manage db online_data_migrations, which uses an anonymous RequestContext with project_id=NULL). This succeeds despite the unique constraint on project_id because in MySQL, unique constraints are only enforced on non-NULL values [1]. To avoid creation of a duplicate default security group for project_id=NULL, we can use the default security group object that was returned from the first security_group_ensure_default call earlier in instance_create method and remove the second, redundant call. This also breaks out the security groups setup code from a nested method as it was causing confusion during code review and is not being used for any particular purpose. Inspection of the original commit where it was added in 2012 [2] did not contain any comments about the nested method and it appeared to either be a way to organize the code or a way to reuse the 'models' module name as a local variable name. Closes-Bug: #1824435 [1] https://dev.mysql.com/doc/refman/8.0/en/create-index.html#create-index-unique [2] https://review.opendev.org/#/c/8973/2/nova/db/sqlalchemy/api.py@1339 Conflicts: gate/post_test_hook.sh NOTE(melwitt): The conflict is because of the difference from Train in the patch below this one where we need to pass the cell1 config to the archive command because change If133b12bf02d708c099504a88b474dce0bdb0f00 is not in Stein. Change-Id: Idb205ab5b16bbf96965418cd544016fa9cc92de9 (cherry picked from commit |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| playbooks/legacy | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
OpenStack Nova
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.
Use the following resources to learn more.
API
To learn how to use Nova's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
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
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.
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:
Other Information
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: