openstack/neutron-tempest-plugin
Code Issues Proposed changes
ab63e6e6f3
neutron-tempest-plugin/neutron/tests/tempest/api/test_revisions.py

265 lines
14 KiB
Python
Raw Normal View History

Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
Add missing revision number altercations This adds revises_on_change for the following models and API tests to ensure the correct behavior: * port security (network and port) * DNS domain (network and port) * extra dhcp opts (port) * extra routes (router) * subnet service type (subnet) Additionally, it configures the DNS extension to be loaded in the gate since the extension is enabled for tempest. Closes-Bug: #1627649 Change-Id: Ifa969c8c2582f8f41d42df07652f259781a36bb5
2016-09-22 17:52:25 -07:00
import netaddr
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
from tempest import test
from neutron.tests.tempest.api import base
from neutron.tests.tempest.api import base_security_groups as bsg
from neutron.tests.tempest import config
class TestRevisions(base.BaseAdminNetworkTest, bsg.BaseSecGroupTest):
@classmethod
Add common way to extend standard attribute models This adds a way for standard attribute models to declare the API resources they show up in. It then adds a utility function to the standard_attr module to grab a map of all API resources and their corresponding models. This can be used by any processing code that wants to add fields to standard attribute resources. This also adjusts the existing extensions to leverage this new functionality. Partially-Implements: blueprint add-neutron-extension-resource-timestamp Change-Id: Idc8923d0e983fcb0690f8cb5b55a5aff8690154f
2016-09-02 00:26:42 -06:00
@test.requires_ext(extension="standard-attr-revisions", service="network")
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
def skip_checks(cls):
super(TestRevisions, cls).skip_checks()
@test.idempotent_id('4a26a4be-9c53-483c-bc50-b53f1db10ac6')
def test_update_network_bumps_revision(self):
net = self.create_network()
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', net)
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
updated = self.client.update_network(net['id'], name='newnet')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['network']['revision_number'],
net['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('cac7ecde-12d5-4331-9a03-420899dea077')
def test_update_port_bumps_revision(self):
net = self.create_network()
port = self.create_port(net)
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', port)
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
updated = self.client.update_port(port['id'], name='newport')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['port']['revision_number'],
port['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('c1c4fa41-8e89-44d0-9bfc-409f3b66dc57')
def test_update_subnet_bumps_revision(self):
net = self.create_network()
subnet = self.create_subnet(net)
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', subnet)
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
updated = self.client.update_subnet(subnet['id'], name='newsub')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['subnet']['revision_number'],
subnet['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('e8c5d7db-2b8d-4615-a476-6e537437c4f2')
def test_update_subnetpool_bumps_revision(self):
sp = self.create_subnetpool('subnetpool', default_prefixlen=24,
prefixes=['10.0.0.0/8'])
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', sp)
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
updated = self.admin_client.update_subnetpool(sp['id'], name='sp2')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['subnetpool']['revision_number'],
sp['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
Using revision_number to ensure no overlap in *one* network This patch uses revision_number in database. When creating a subnet in a network, the revision_number of the network will be increased. That will prevent overlapping CIDR (overlapping CIDR means some subnets' cidrs are overlapping) on *one* network. Basically, in case of concurrent requests creating subnets on *one* network, only one request successes, other requests needs retrying request. Change-Id: Id6548535075bed87a4b36e1462db546ab9163f29 Closes-Bug: #1532695
2016-08-05 09:46:43 +07:00
@test.idempotent_id('e8c5d7db-2b8d-4567-a326-6e123437c4d1')
def test_update_subnet_bumps_network_revision(self):
net = self.create_network()
subnet = self.create_subnet(net)
updated = self.client.show_network(net['id'])
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['network']['revision_number'],
net['revision_number'])
Using revision_number to ensure no overlap in *one* network This patch uses revision_number in database. When creating a subnet in a network, the revision_number of the network will be increased. That will prevent overlapping CIDR (overlapping CIDR means some subnets' cidrs are overlapping) on *one* network. Basically, in case of concurrent requests creating subnets on *one* network, only one request successes, other requests needs retrying request. Change-Id: Id6548535075bed87a4b36e1462db546ab9163f29 Closes-Bug: #1532695
2016-08-05 09:46:43 +07:00
self.client.delete_subnet(subnet['id'])
updated2 = self.client.show_network(net['id'])
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated2['network']['revision_number'],
updated['network']['revision_number'])
Using revision_number to ensure no overlap in *one* network This patch uses revision_number in database. When creating a subnet in a network, the revision_number of the network will be increased. That will prevent overlapping CIDR (overlapping CIDR means some subnets' cidrs are overlapping) on *one* network. Basically, in case of concurrent requests creating subnets on *one* network, only one request successes, other requests needs retrying request. Change-Id: Id6548535075bed87a4b36e1462db546ab9163f29 Closes-Bug: #1532695
2016-08-05 09:46:43 +07:00
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('6c256f71-c929-4200-b3dc-4e1843506be5')
@test.requires_ext(extension="security-group", service="network")
def test_update_sg_group_bumps_revision(self):
sg, name = self._create_security_group()
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', sg['security_group'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
update_body = self.client.update_security_group(
sg['security_group']['id'], name='new_sg_name')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(update_body['security_group']['revision_number'],
sg['security_group']['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('6489632f-8550-4453-a674-c98849742967')
@test.requires_ext(extension="security-group", service="network")
def test_update_port_sg_binding_bumps_revision(self):
net = self.create_network()
port = self.create_port(net)
sg = self._create_security_group()[0]
self.client.update_port(
port['id'], security_groups=[sg['security_group']['id']])
updated = self.client.show_port(port['id'])
Fix ML2 revision_number handling in port updates The revision number is bumped on the flush that changes the port or a resource that bumps the port. However, in ML2 we create the dict that is used for after_update events, mech driver calls, and the API response before all resource modifications are complete so the dict may not reflect the correct revision number. This adjusts the update_port_status to flush changes to the DB before constructing the dictionary response to give the event listener a chance to bump the revision. It also adjusts ML2 to update the 'updated_port' dict with the latest result from make_port_dict after all of the related objects have been processed to ensure the result has the latest info from extensions. The API test for allowed address pairs was adjusted to stop checking for order on update since no order is stored in the DB. The API test for revision numbers and ports was updated to expect the correct behavior. Closes-Bug: #1625981 Change-Id: I49d2d79a57d484fd98b8969f511895e607b7f128
2016-09-19 20:05:25 -07:00
updated2 = self.client.update_port(port['id'], security_groups=[])
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['port']['revision_number'],
port['revision_number'])
self.assertGreater(updated2['port']['revision_number'],
updated['port']['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('29c7ab2b-d1d8-425d-8cec-fcf632960f22')
@test.requires_ext(extension="security-group", service="network")
def test_update_sg_rule_bumps_sg_revision(self):
sg, name = self._create_security_group()
rule = self.client.create_security_group_rule(
security_group_id=sg['security_group']['id'],
protocol='tcp', direction='ingress', ethertype=self.ethertype,
port_range_min=60, port_range_max=70)
updated = self.client.show_security_group(sg['security_group']['id'])
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['security_group']['revision_number'],
sg['security_group']['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
self.client.delete_security_group_rule(
rule['security_group_rule']['id'])
updated2 = self.client.show_security_group(sg['security_group']['id'])
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated2['security_group']['revision_number'],
updated['security_group']['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
Add missing revision number altercations This adds revises_on_change for the following models and API tests to ensure the correct behavior: * port security (network and port) * DNS domain (network and port) * extra dhcp opts (port) * extra routes (router) * subnet service type (subnet) Additionally, it configures the DNS extension to be loaded in the gate since the extension is enabled for tempest. Closes-Bug: #1627649 Change-Id: Ifa969c8c2582f8f41d42df07652f259781a36bb5
2016-09-22 17:52:25 -07:00
@test.idempotent_id('db70c285-0365-4fac-9f55-2a0ad8cf55a8')
@test.requires_ext(extension="allowed-address-pairs", service="network")
def test_update_allowed_address_pairs_bumps_revision(self):
net = self.create_network()
port = self.create_port(net)
updated = self.client.update_port(
port['id'], allowed_address_pairs=[{'ip_address': '1.1.1.1/32'}])
self.assertGreater(updated['port']['revision_number'],
port['revision_number'])
updated2 = self.client.update_port(
port['id'], allowed_address_pairs=[])
self.assertGreater(updated2['port']['revision_number'],
updated['port']['revision_number'])
@test.idempotent_id('a21ec3b4-3569-4b77-bf29-4177edaa2df5')
@test.requires_ext(extension="extra_dhcp_opt", service="network")
def test_update_extra_dhcp_opt_bumps_revision(self):
net = self.create_network()
port = self.create_port(net)
opts = [{'opt_value': 'pxelinux.0', 'opt_name': 'bootfile-name'}]
updated = self.client.update_port(port['id'], extra_dhcp_opts=opts)
self.assertGreater(updated['port']['revision_number'],
port['revision_number'])
opts[0]['opt_value'] = 'pxelinux.77'
updated2 = self.client.update_port(
port['id'], extra_dhcp_opts=opts)
self.assertGreater(updated2['port']['revision_number'],
updated['port']['revision_number'])
@test.idempotent_id('40ba648f-f374-4c29-a5b7-489dd5a38a4e')
@test.requires_ext(extension="dns-integration", service="network")
def test_update_dns_domain_bumps_revision(self):
net = self.create_network(dns_domain='example.test.')
Refetch subnet/network from DB in ML2 update ops This ensures that any extensions run in the ML2 extension framework that bump the revision number of the subnet or network result in the altered revision number being returned to the API caller and passed into the ML2 mech drivers and callback handlers. Closes-Bug: #1627628 Change-Id: Ieb37a3833ee52c671419c6dc981cf91c2366ae94
2016-09-24 23:07:45 -07:00
updated = self.client.update_network(net['id'], dns_domain='exa.test.')
Add missing revision number altercations This adds revises_on_change for the following models and API tests to ensure the correct behavior: * port security (network and port) * DNS domain (network and port) * extra dhcp opts (port) * extra routes (router) * subnet service type (subnet) Additionally, it configures the DNS extension to be loaded in the gate since the extension is enabled for tempest. Closes-Bug: #1627649 Change-Id: Ifa969c8c2582f8f41d42df07652f259781a36bb5
2016-09-22 17:52:25 -07:00
self.assertGreater(updated['network']['revision_number'],
net['revision_number'])
port = self.create_port(net)
updated = self.client.update_port(port['id'], dns_name='port1')
if not updated['port']['dns_name']:
self.skipTest("Server does not have DNS domain configured.")
self.assertGreater(updated['port']['revision_number'],
port['revision_number'])
updated2 = self.client.update_port(port['id'], dns_name='')
self.assertGreater(updated2['port']['revision_number'],
updated['port']['revision_number'])
@test.idempotent_id('8482324f-cf59-4d73-b98e-d37119255300')
@test.requires_ext(extension="router", service="network")
@test.requires_ext(extension="extraroute", service="network")
def test_update_router_extra_routes_bumps_revision(self):
subnet = self.create_subnet(self.create_network())
subgateway = netaddr.IPAddress(subnet['gateway_ip'])
router = self.create_router(router_name='test')
self.create_router_interface(router['id'], subnet['id'])
router = self.client.show_router(router['id'])['router']
updated = self.client.update_router(
router['id'], routes=[{'destination': '2.0.0.0/24',
'nexthop': str(subgateway + 1)}])
self.assertGreater(updated['router']['revision_number'],
router['revision_number'])
updated2 = self.client.update_router(router['id'], routes=[])
self.assertGreater(updated2['router']['revision_number'],
updated['router']['revision_number'])
@test.idempotent_id('6bd18702-e25a-4b4b-8c0c-680113533511')
@test.requires_ext(extension="subnet-service-types", service="network")
def test_update_subnet_service_types_bumps_revisions(self):
subnet = self.create_subnet(self.create_network())
updated = self.client.update_subnet(
subnet['id'], service_types=['compute:'])
self.assertGreater(updated['subnet']['revision_number'],
subnet['revision_number'])
updated2 = self.client.update_subnet(
subnet['id'], service_types=[])
self.assertGreater(updated2['subnet']['revision_number'],
updated['subnet']['revision_number'])
@test.idempotent_id('9c83105c-9973-45ff-9ca2-e66d64700abe')
@test.requires_ext(extension="port-security", service="network")
def test_update_port_security_bumps_revisions(self):
net = self.create_network(port_security_enabled=False)
Refetch subnet/network from DB in ML2 update ops This ensures that any extensions run in the ML2 extension framework that bump the revision number of the subnet or network result in the altered revision number being returned to the API caller and passed into the ML2 mech drivers and callback handlers. Closes-Bug: #1627628 Change-Id: Ieb37a3833ee52c671419c6dc981cf91c2366ae94
2016-09-24 23:07:45 -07:00
updated = self.client.update_network(net['id'],
port_security_enabled=True)
Add missing revision number altercations This adds revises_on_change for the following models and API tests to ensure the correct behavior: * port security (network and port) * DNS domain (network and port) * extra dhcp opts (port) * extra routes (router) * subnet service type (subnet) Additionally, it configures the DNS extension to be loaded in the gate since the extension is enabled for tempest. Closes-Bug: #1627649 Change-Id: Ifa969c8c2582f8f41d42df07652f259781a36bb5
2016-09-22 17:52:25 -07:00
self.assertGreater(updated['network']['revision_number'],
net['revision_number'])
Refetch subnet/network from DB in ML2 update ops This ensures that any extensions run in the ML2 extension framework that bump the revision number of the subnet or network result in the altered revision number being returned to the API caller and passed into the ML2 mech drivers and callback handlers. Closes-Bug: #1627628 Change-Id: Ieb37a3833ee52c671419c6dc981cf91c2366ae94
2016-09-24 23:07:45 -07:00
updated2 = self.client.update_network(net['id'],
port_security_enabled=False)
Add missing revision number altercations This adds revises_on_change for the following models and API tests to ensure the correct behavior: * port security (network and port) * DNS domain (network and port) * extra dhcp opts (port) * extra routes (router) * subnet service type (subnet) Additionally, it configures the DNS extension to be loaded in the gate since the extension is enabled for tempest. Closes-Bug: #1627649 Change-Id: Ifa969c8c2582f8f41d42df07652f259781a36bb5
2016-09-22 17:52:25 -07:00
self.assertGreater(updated2['network']['revision_number'],
updated['network']['revision_number'])
port = self.create_port(net, port_security_enabled=False)
updated = self.client.update_port(port['id'],
port_security_enabled=True)
self.assertGreater(updated['port']['revision_number'],
port['revision_number'])
updated2 = self.client.update_port(port['id'],
port_security_enabled=False)
self.assertGreater(updated2['port']['revision_number'],
updated['port']['revision_number'])
@test.idempotent_id('68d5ac3a-11a1-4847-8e2e-5843c043d89b')
@test.requires_ext(extension="binding", service="network")
def test_portbinding_bumps_revision(self):
port = self.create_port(self.create_network())
port = self.admin_client.update_port(
port['id'], **{'binding:host_id': 'badhost1'})['port']
updated = self.admin_client.update_port(
port['id'], **{'binding:host_id': 'badhost2'})['port']
self.assertGreater(updated['revision_number'],
port['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('4a37bde9-1975-47e0-9b8c-2c9ca36415b0')
@test.requires_ext(extension="router", service="network")
def test_update_router_bumps_revision(self):
subnet = self.create_subnet(self.create_network())
router = self.create_router(router_name='test')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', router)
rev1 = router['revision_number']
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
router = self.client.update_router(router['id'],
name='test2')['router']
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(router['revision_number'], rev1)
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
self.create_router_interface(router['id'], subnet['id'])
updated = self.client.show_router(router['id'])['router']
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(updated['revision_number'],
router['revision_number'])
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
@test.idempotent_id('9de71ebc-f5df-4cd0-80bc-60299fce3ce9')
@test.requires_ext(extension="router", service="network")
@test.requires_ext(extension="standard-attr-description",
service="network")
def test_update_floatingip_bumps_revision(self):
ext_id = config.CONF.network.public_network_id
network = self.create_network()
subnet = self.create_subnet(network)
router = self.create_router('test', external_network_id=ext_id)
self.create_router_interface(router['id'], subnet['id'])
port = self.create_port(network)
body = self.client.create_floatingip(
floating_network_id=ext_id,
port_id=port['id'],
description='d1'
)['floatingip']
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertIn('revision_number', body)
Increment revision numbers on object changes This adds the logic to increment the revision numbers for objects whenever there are changes and it exposes the revision number via a field in the API. This is handled with a new default service plugin that subscribes to DB events and bumps revision numbers for any objects that were modified. It also handles the logic for bumping the revision number of a parent in a relationship where the children aren't top-level neutron objects that would be tracked individually. This is accomplished with a 'revises_on_change' attribute on the child models that the service plugin will use to find the parent and bump its revision. API tests are included to test the revision numbers added to each standard attribute enabled object. Partially-Implements: bp/push-notifications Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
2016-03-24 22:14:58 -07:00
b2 = self.client.update_floatingip(body['id'], description='d2')
Change 'revision' to 'revision_number' The DB model uses 'revision_number' so we should keep the API consistent with that to avoid the hassle of writing translation logic as we transition to OVO. This is an API change, but the revision plugin didn't exist in the last cycle so we don't need to worry about backward compatibility or an API impact. Change-Id: I445974b0e0dabb762807c6f318b1b44f51b3fe15
2016-09-02 17:14:37 -07:00
self.assertGreater(b2['floatingip']['revision_number'],
body['revision_number'])
Correct floating IP extra attributes updating issues Updating floating IP extra attributes, for instance description, will unexpectedly disassociate it. This behavior will interrupt the user's service traffic. And this is because that user can submit an empty request dict (without port_id parameter) for the floating IP updating API, and then it will be disassociated by default. So there is no way to update the floating IP extra attributes without changing it's association. This patch will make updating floating IP extra attributes API works properly. Closes-Bug: #1607746 Change-Id: I036e473118431856550249359a22445380ef9ece
2016-05-05 14:52:26 +08:00
# disassociate
self.client.update_floatingip(b2['floatingip']['id'], port_id=None)
Copy Permalink