Starting the macvtap agent without specifying at least one
physical_interface_mappings does not make sense. As it only
supports layer2 networks (flat, vlan) an interface mapping is
mandatory. An existing agent deployment without an interface
mapping can not serve any networks to instances!
This patch terminates the agent when no mapping is
provided. As without this mapping the agent cannot serve any networks
for instances, this patch can't really break existing deployments.
UpgradeImpact Agent terminates when no physical_interface_mapping
configuration is provided.
Change-Id: I647cf4da55fda54e32b7047b84e0d7f671629fa7
Closes-Bug: #1587444
This patch adds 'unique_keys' to NeutronDbObject and allows get_object
to lookup objects by unique keys in addition to primary keys.
Change-Id: I31f5603c116892390d1f8025d3c1893355ad0bac
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
- Changes RULE_TYPE_DSCP_MARK to RULE_TYPE_DSCP_MARKING to conform
with the rules name.
- Added object versioning to qos related objects.
- qos/rule: Throws a QosRuleVersionUnavailable exception when
the QosDscpMarkingRule version is < '1.1'.
- removed test object version incrementation TODO from test_policy.py
- Object versioning can not be used to increment the object version.
Change-Id: I4f10ef3c1cbaa2a868de2b8e3abc4c39eb1f44c7
Partial-Bug: #1468353
Function used in alembic database migration script to
remove foreign keys from table doesn't remove unique constraint
created for such fk in table.
Sometimes there is need to remove also such unique constraint during
database upgrade.
Removing unique constraint is little bit different in mysql and
postgresql databases because names of such constraints are different.
This patch introduces function to remove constraints from table
during migration.
It is also used in remove_fks_from_table() function to allow removal
unique constraints when fk is removed.
Change-Id: I7e7732560984b1c1e45230434ddc4be8cf5ab630
Closes-Bug: #1599840
String interpolation should be delayed to be handled
by the logging code, rather than being done
at the point of the logging call.
So add a hacking rule for it.
See the oslo i18n guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
Change-Id: I91e8d59d508c594256d5f74514e62f8f928d1df5
Closes-Bug: #1596829
The case when floating IP is reassociated from one VM to another
on the same host without doing disassociation, was not properly handled:
l3 dvr agent only checked that the floating address was present on the
device in router namespace and considered floating IP confiigured correctly.
This patch adds fip_mapping to router object so fixed IP change can be
detected and handled.
Closes-Bug: #1599089
Change-Id: I25c23bb9ad7b9a9b90f225f37417142e2304deb8
There is a race we need to check for where a port is created and
then updated with binding information via another API shortly
afterward that causes the bug referenced in this message.
* The port is created and a DHCP provisioning block is added.
* The DHCP agent finishes setting up the reservation and emits a
message to clear the block.
* The _port_provisioned callback in ML2 is triggered.
* A port update comes in that binds the port and adds new blocks.
* The _port_provisioned callback now does a get_port and sees
that the port is bound so it assumes everything is done and
the port can be marked ACTIVE.
* The port is now ACTIVE before the L2 agent has had a chance to
do its wiring and the VM boots.
* The L2 agent requests the details and the port flaps back to
BUILD.
* The L2 agent finishes and clears the provisioning block a second
time so the port goes back to ACTIVE.
This will randomly cause failures because the VM is booting before the
L2 agent is done and tempest may see the port in the BUILD state after
the agent grabs port details.
The fix is relatively simple. Just check for any new provisioning blocks
added *after* doing a get_port in the _port_provisioned callback to make
sure we don't update to ACTIVE if there are newly added blocks.
Closes-Bug: #1600396
Change-Id: I14f41a5fda0707e8bba064c5cd952553686c30cd
As part of making DVR portbinding implementation generic, we rename
dvr portbinding functions as distributed portbinding functions.
In next patch we make dvr logic for port binding generic,
to be useful for all distributed router ports(for example, HA).
Partial-Bug: #1595043
Partial-Bug: #1522980
Change-Id: I402df76c64299156d4ed48ac92ede1e8e9f28f23
When a list of subports has been added or removed from a trunk, the
registry should emit a corresponding event and pass the list of added or
removed SubPort objects as the payload.
Trunk agent RPC callbacks can then be subscribed to these events in
order to relay subport information to the agents.
Partially-implements: blueprint vlan-aware-vms
Change-Id: Icb8da23cdd2244da5183058c31d8acef22d78eaa
This formalizes that an IP will be allocated when host binding is
provided on port update or IpAddressGenerationFailure is generated and
the port update fails. This was always the intent but no test was
added to cover the failure case.
Change-Id: Ice0cf2f88eefb15700b1385817e09db489a3bac4
Partially-Implements: blueprint routed-networks
This extension exists mainly to let Nova know when deferred port
binding is in effect and its okay for the port to not have any IP
addresses.
The extension is implemented by the segments service plugin with a
very simple implementation to begin with. This implementation is
likely to evolve.
Change-Id: I591d32df512712e4de36fe20e389b3a14d58157f
Partially-Implements: blueprint routed-networks
As was discussed in [1], we should not only allow setting
min_l3_agents_per_router to one [2], but deprecate this option
completely.
[1] https://bugs.launchpad.net/bugs/1555042
[2] https://review.openstack.org/289925
Related-Bug: 1555042
Closes-Bug: 1599275
Change-Id: I518e12edd4bfb7a036b278d5f108cf0fc3de0353
The tox.ini has some unicode characters that cannot be
decoded, so just executing tox will immediately cause an error
because the tox.ini cannot be parsed.
Closes-Bug: #1600068
Change-Id: Ia01ae80d9321584845bb06c3f6673d13027bd2db