|
Looks like the update coming after the delete may be a networking-odl journal issue. Here are some lines from the neutron logs for build 78:
1) neutron executes an update on the network, line 108342:
Mar 11 17:29:12 releng-45483-78-1-devstack-pike-0.vexxhost.net neutron-server[19011]: INFO neutron.tests.unit.plugins.ml2.drivers.mechanism_logger [None req-48ecbd9b-7166-4ee2-a70b-68512ba04bd4 tempest-BulkNetworkOpsTest-924910474 tempest-BulkNetworkOpsTest-924910474] update_network_precommit called with network settings {'provider:physical_network': None, 'ipv6_address_scope': None, 'revision_number': 3, 'port_security_enabled': True, 'provider:network_type': None, 'id': u'c828ffd6-bb52-4073-b738-f099316c2c31', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': [], 'ipv4_address_scope': None, 'shared': False, 'project_id': u'88fb4bf8685c433f91f2ecd6c8c76f30', 'status': u'ACTIVE', 'subnets': [], 'description': u'', 'tags': [], 'updated_at': '2018-03-11T17:29:12Z', 'provider:segmentation_id': None, 'name': u'tempest-network-1459092092', 'admin_state_up': True, 'tenant_id': u'88fb4bf8685c433f91f2ecd6c8c76f30', 'created_at': '2018-03-11T17:29:11Z', 'mtu': 1408, 'vlan_transparent': None} (original settings {'provider:physical_network': None, 'ipv6_address_scope': None, 'revision_number': 3, 'port_security_enabled': True, 'provider:network_type': None, 'id': u'c828ffd6-bb52-4073-b738-f099316c2c31', 'router:external': False, 'availability_zone_hints': [], 'availability_zones': [], 'ipv4_address_scope': None, 'shared': False, 'project_id': u'88fb4bf8685c433f91f2ecd6c8c76f30', 'status': u'ACTIVE', 'subnets': [], 'description': u'', 'tags': [], 'updated_at': '2018-03-11T17:29:12Z', 'provider:segmentation_id': None, 'name': u'tempest-network-1459092092', 'admin_state_up': True, 'tenant_id': u'88fb4bf8685c433f91f2ecd6c8c76f30', 'created_at': '2018-03-11T17:29:11Z', 'mtu': 1408, 'vlan_transparent': None}) and network segments []
2) REST call to neutron to delete the network, line 108487:
Mar 11 17:29:12 releng-45483-78-1-devstack-pike-0.vexxhost.net neutron-server[19011]: INFO neutron.wsgi [None req-48ecbd9b-7166-4ee2-a70b-68512ba04bd4 tempest-BulkNetworkOpsTest-924910474 tempest-BulkNetworkOpsTest-924910474] 10.30.170.12 "DELETE /v2.0/networks/c828ffd6-bb52-4073-b738-f099316c2c31 HTTP/1.1" status: 204 len: 168 time: 0.8570170
3) networking-odl REST calls odl to delete the network, line 108492:
Mar 11 17:29:12 releng-45483-78-1-devstack-pike-0.vexxhost.net neutron-server[19011]: DEBUG networking_odl.common.client [None req-1afdbd9a-a31d-470e-9983-3259040dd939 None None] Sending METHOD (delete) URL (http://10.30.170.92:8181/controller/nb/v2/neutron/networks/c828ffd6-bb52-4073-b738-f099316c2c31) JSON (None) (pid=19600) request /opt/stack/networking-odl/networking_odl/common/client.py:89
4) networking odl REST calls odl to update the network, line 108509:
Mar 11 17:29:13 releng-45483-78-1-devstack-pike-0.vexxhost.net neutron-server[19011]: DEBUG networking_odl.common.client [None req-8321e7b2-acc5-4860-8a13-8f988edbaf05 None None] Sending METHOD (put) URL (http://10.30.170.92:8181/controller/nb/v2/neutron/networks/c828ffd6-bb52-4073-b738-f099316c2c31) JSON ({
Uploading the journalctl.log
|
|
> the bug is that networking-odl is sending events in the wrong order. ODL can't do anything with this since the required resources aren't there when the request is made.
well now that is of course the bigger more general problem we're after solving under NEUTRON-158... but aren't you mixing up 2 not directly related problems here? This bug is not (directly) about that, from what is written above, I thought. But if you think it is, then just make this Jira have a requires/depends on link to NEUTRON-158 - fine for me.
> BUt, if we don't log this exception, how will we know if the root problem is fixed?
c/72735 makes Neutron actually return a HTTP 500 error in case of an OptimisticLockFailedException to the driver (instead of logging an error on ODL side but return 201 to the driver, which is the current behaviour, which IMHO is completely wrong), so the driver will log it as a failed operation - and, I guess (not sure), eventually retry.
|
journalctl.log.xz
