This patch refactors the sample files of server_group notifications to
use a common ServerGroupPayload sample data.
Change-Id: I4e7531c180484a7b430d267153d185f1006543f0
When a security group is removed from a port nova
incorrectly logs this as a security group addition
Change-Id: If525313c63c4553abe8bea6f2bfaf75431ed18ea
Closes-bug: 1731889
This patch adds `key_name` param to instance rebuild
API. Then the user could reset the instance keypair
when rebuilding. If set key_name to None, the API
will unset the keypair of the instance.
APIImpact
Implements blueprint: rebuild-keypair-reset
Change-Id: I23886a89c25f811cfbe7e2500ce7ff52f9162966
This change set contains a functional test demonstrating broken-ness
in AllocationCandidates.get_by_filters when all the providers in the
database are sharing providers.
Change-Id: Ifc5f0b11e54d937d960d5dd9102e6287ee7320d8
Related-Bug: #1730730
This change set adds a couple of failing test cases that demonstrate
holes in the design of GET /allocation_candidates when inventory from
the same resource class is present on both the compute node (the "main"
resource provider) and a shared resource provider.
The example being used is where the compute node has some local disk,
and is also associated with a shared storage pool. Both the compute
node RP and the shared storage RP will provide inventory of DISK_GB.
Test case test_common_rc demonstrates bug #1724613: when I ask for
DISK_GB in this setup, the shared storage pool is ignored. I expect to
get two candidates back: one with the storage from the compute node; the
other with the storage from the shared storage pool. But I actually
only get the former candidate back.
Test case test_common_rc_traits_split shows bug #1724633: that placement
can't tell which traits are supposed to apply to which resources. In
the above scenario, if the local storage is SSD and the shared storage
is RAID, and I ask for SSD + RAID, I "expect" to get back no hits. But
I would in fact get back a candidate with the storage from the shared
storage pool, because the cumulative set of traits would satisfy my
requested SSD + RAID.
Note that the two tests are functionally identical (traits are ignored
entirely) until https://review.openstack.org/#/c/479766/ lands. At that
point, depending on how we decide to implement the code that would deal
with this scenario, the test may fail *differently* until bug #1724613
is fixed.
Related-Bug: #1724613
Related-Bug: #1724633
Change-Id: I42edf102379cf329aa2252ab779a9f945f5fc155
This reverts commit ee7858ffca.
Looks like heat gate is broken with this change, and the
revert fixes it. Tested with https://review.openstack.org/#/c/518834/
Change-Id: I3fefcda93e496e97474bd419d50bd9753a4d1fed
Closes-Bug: #1731395
For the sake of code deduplication, LOC reduction, and readability
(improved signal:noise ratio), this change set implements some
convenience methods in AllocationCandidatesTestCase for creation of
placement artifacts such as resource providers, inventory, and
allocations, as well as for extracting and comparing results of
get_allocation_candidates.
This only changes test code; and is just a refactor - no tests are
added, removed, or substantively changed.
Change-Id: I34527a3b2ac33ec3b1c6cce2c4a2163eea1ada4d
Currently when providing existing direct port, nova-compute
will overwrite the binding-profile information with pci_vendor_info
and pci_slot. The binding-profile will be used to request
NIC capabilities for SR-IOV ports [1]. This also allows to distinguish
which neutron mechanism driver will bind the port [2].
This patch updates the behaviour that on update port it will update,
rather than overwrite, the binding-profile information with
pci_vendor_info and pci_slot. And on unbind port it will remove
only the pci_vendor_info and pci_slot from the port binding-profile
rather than unsetting the entire field.
[1] https://review.openstack.org/#/c/435954/
[2] https://review.openstack.org/#/c/499203/
Closes-Bug: #1719327
Change-Id: I80106707a037d567d0f690570f2cf9cfcd30d594
This change set pulls AllocationCandidatesTestCase out of
test_resource_provider and into its own test_allocation_candidates
module.
There is no change to the code. This is just a refactor. We're going
to add a bunch more test cases for allocation candidates, and the
test_resource_provider module was already getting out of hand.
Change-Id: Iedfb712d4668a2d34112449aa6ef0263d02e24a4
This patch refactors the sample files of instance.reboot notifications
to use the previously introduced common sample data.
Change-Id: I6a9e8af79153a9b7825aef0838b60a8d1f97a421
This patch refactors the sample files of instance.live_migration_rollback
notification samples to use the previously introduced common sample
data. This patch is small as the other live migration notification
transformations haven't been merged yet.
Change-Id: I834c2d5ce0257b053f7023eae55d4c9e6c9a47e1
This patch refactors the sample files of instance.interface_attach and
interface_detach notifications to use the previously introduced common
sample data.
Change-Id: I74396b680f35290e32f667d2ddba227e1cbbab2f
This patch refactors the sample files of instance.power-off and
power-on notifications to use the previously introduced common sample
data.
Change-Id: Ifead36ba0dcef86e98e82819c48255d2d9f06d37
Co-Authored-By: Gábor Antal <antal@inf.u-szeged.hu>
Change-Id: I27608f60dd5f8458e476286c6991c47dba7852b1
Implements: bp versioned-notification-transformation-queens
This patch refactors the sample files of instance.pause and unpause
notifications to use the previously introduced common sample data
Change-Id: I767f082ca244b9f4f940244ab83f69c6e995a442
To remove duplicated data this patch introduce common json fragments for
the instance related notifications and refactors the sample file of
instance.delete.start and instance.delete.end.
The common sample fragments define an active instance as that is the
most common state in the instance action notifications. This way
we can minimize the difference between the common sample and the
generated notification. Still there will be differences. For example
instance.delete.end notification will contain different instance status
and some other deletion related fields are also set. To make sure
the the sample matches with the generated notification we have to
override some of the fields coming from the common sample fragment.
Such overrides could be added in the test case directly to the
_verify_notification() call as it is done in case of dynamic values
like instance uuid. However the sample files not only used in the
functional tests but also during the generation of the notification
dev-ref. To have meaningful samples in the doc we have to do such
overrides during the reference resolving and not directly in the
test case.
Change-Id: I0669a075c94ba2a435116791e3391d8d745bc639
Előd Illés