Enable users to define the policy rules on server group policy
to meet more advanced policy requirement. This microversion
brings the following changes in server group APIs:
* Add ``policy`` and ``rules`` fields in the request of POST
``/os-server-groups``.
* The ``policy`` and ``rules`` fields will be
returned in response body of POST, GET ``/os-server-groups``
API and GET ``/os-server-groups/{server_group_id}`` API.
* The ``policies`` and ``metadata`` fields have been removed
from the response body of POST, GET ``/os-server-groups`` API
and GET ``/os-server-groups/{server_group_id}`` API.
Part of blueprint: complex-anti-affinity-policies
Change-Id: I6911e97bd7f8df92511e90518dba21c127e106a5
To solve the race condition problem, we do anti-affinity policy
sanity check in the instance build code of compute manager, but
this check is only valid in original policy.
Specifically, this change adds validation of the new
max_server_per_host policy rule which can be used to allow >1
anti-affinity group member on the same host.
blueprint: complex-anti-affinity-policies
Change-Id: I755b6fdddc9d754326cd9c81b6880581641f73e8
In this patch, the anti-affinity filter will get the
max_server_per_host limit from policy rules, and compare it
against the number of servers within the same group on a given
host. If the filter finds the number is not satisfied with the
limit, it will filter out this host.
The default ``max_server_per_host`` for the anti-affinity filter
is 1 for backward compatibility.
Change-Id: I4b67ec9dd4ce846a704d0f75ad64c41e693de0fb
blueprint: complex-anti-affinity-policies
In this patch, the ServerGroupPayload is updated to include
the new ``policy`` field; the ``policies`` field is deprecated
for removal but still put into the notification payload for
backward compatibility.
Related to blueprint complex-anti-affinity-policies
Change-Id: Ie739ee8dec4685cd70e735ff83f7f30bc7e95a57
The change items in this patch as below:
1. Add policy and rules to InstanceGroup, deprecate
the policies field.
2. Also, make _from_db_object and _create_in_db method to
support new "policy" field.
The internal usage of InstanceGroup.policies is converted to
use the new model in the REST API and RequestSpec compat code.
Related to blueprint complex-anti-affinity-policies
Change-Id: Ib33719a4b9599d86848c618a6e142c71ece79ca5
A group can only have 1 policy associated it, but now we have
ONE to MANY model in group model, this patch change it to ONE
to ONE Model.
We also adapt create method to new model, and remove policy
update support in group.save because now we don't support to
update a policy of the group.
Related to blueprint complex-anti-affinity-policies
Change-Id: I95eb1c8470a567408696132ae656305be53dc5bb
This adds the rules column to instance_group_policy table.
The ''Text'' column "rules" which is a dict, it can be
applied to the policy, and represents the rules for
specific policy.
Related to blueprint complex-anti-affinity-policies
Change-Id: I61ffb5ddb2d808bfef4e60088f4524bd98e0474e
It seems gabbi does not resolve yaml refs in the URL part of a REST
call. This causes that the tests in ensure-consumer.yaml uses invalid
consumer id '*consumer_id'
This patches replace the *consumer_id with a fixture ref that works.
Change-Id: I0576f282b1801340db6827fb4c9520a0d48ad7f0
Related-Bug: #1780238
Now that we have the long_rpc_timeout setting for
pre_live_migration rpc calls from the source to
destination host, timing that operation is a bit more
interesting so this adds a timer and log message
for how long that round-trip takes.
Change-Id: I88d1a5fb2576ff7ac81981798d300a27030f74f7
The instance action notifications contain the user id and the
project id of the owner of the instance. However an instance
action might be initiated by another user. It could be another
user from the same project or can be an admin from the admin project.
To be able to distinguish between the user who initiated the instance
action from the user owning the instance we need to add two new
fields to the instance action notifications, action_initiator_user
and action_initiator_project
Change-Id: I649d8a27baa8840bc1bb567fef027c749c663432
Closes-bug: #1744658
Blueprint: add-action-initiator-to-instance-action-notifications
Before we stored flavors in instance_extra, certain fields, defined
in nova.compute.flavors.system_metadata_flavor_props, were stored
in the instance.system_metadata for the embedded instance.flavor.
The "disabled" field wasn't one of those keys, however, so really
old instances that had their embedded flavor converted to the
serialized instance_extra form won't have the disabled attribute
set and we need to default those here so callers, like the
versioned notfication FlavorPayload, don't explode trying to load
instance.flavor.disabled.
Change-Id: I72f8c11b8b2df1416dec8e2d9250eac0693a30e9
Closes-Bug: #1739325
As we found multiple bugs in the server moving cases this patch adds
test to cover the migrate confirm and migrate revert cases as well.
It seems that these two cases work as expected.
Change-Id: I40a244601e1612a87bd41cd6ad652202035a1ce4
RequestSpec._get_update_primitives() tried to return the unitialized
db_updates field when the object has no changes. This patch initalizes
that local to None and handles that None in create() and save() where
the RequestSpec._get_update_primitives() is called.
Change-Id: Iad256079945bf8b5745ebdcc393c55115dbcab75
Closes-Bug: #1775863
Placement had RP loop detection for RP creation but if an RP is created
without a parent (e.g. root RP) then the parent can be set later with a
PUT /resource_providers/{uuid} request by providing the UUID of the
parent. In this code path the loop detection was missing from the
validation. Moreover there are different loop cases for create than for
set. For create the only possible loop is when the RP being created is
points to itself as a parent. However when the parent is provided later
in a PUT the RP being updated can have descendant RPs. Setting a parent
to a descendant also creates a loop.
This patch adds the missing check and returns HTTP 400 if loop is detected.
Closes-Bug: #1779635
Change-Id: I42c91f5f752f0a4fba8b1d95489fc3f87a1c5b6e
test_pre_live_migration_volume_backed* tests are comparing
primitive versions of LibvirtLiveMigrateData objects which
nest primitive LibvirtLiveMigrateBDMInfo which have
serialized connection_info_json fields in them, which can
have a random key order when comparing which makes the tests
fail. This changes assertJsonEqual to try and deserialize
nested json strings like it does for the top level expected
and observed variables, and updates the test to use
assertJsonEqual.
Change-Id: Ief1634f7e31c473b226e9f19240ecd21840ebdb3
Closes-Bug: #1779711
This adds a QEMU check when configuring MTU for ethernet and bridge
interface types. When creating and configuring tap devices, libvirt is
setting MTU but also configures the virtio-net devices to let it
discovers the MTU used. This QEMU 'host_mtu' option is supported by
QEMU version 2.9 and more.
Closes-Bug: 1779626
Change-Id: I55cf259c715ba129fa8479d1e8a0d11ec15aaa43
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@redhat.com>
This resolves all the warnings currently emitted by oslo.config for nova
and makes the output nicer looking to boot. There are still some issues
but these lie without other projects (osprofiler, oslo.db) and will be
resolved in a future update of those packages.
Change-Id: Ie4eddda36439e6746cb2d97e43b91f63d835877b
Yikun Jiang