Another issue that we have with the read at create is that the dictionary returned is not the same as the one returned when the is a get for the specific resource. The dictionary is also not in the same order.
This is currently breaking our unit tests… By that is just another side issue From: Kevin Benton <ke...@benton.pub<mailto:ke...@benton.pub>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, March 7, 2016 at 11:23 AM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][tempest] Timestamp service extension breaks CI Right, it can't be done in the base right now because core plugins make DB changes after the base plugin has been called. These changes include the initial create processing of many of the extensions so we can't call the extend_dict functions before the data many of the registered hooks are looking for even exists. So unfortunately right now it is the responsibility of the plugin to extend the result after all of the DB work is done, not just the base plugin stuff. If a plugin doesn't do it, the responses from that plugin's create calls will not be correct. It was only recently when we started adding API tests that check create responses for extensions that this bug became apparent. I agree that the extra read right now sucks and it will be worth fixing in Newton. Calling the dictionary extension processing outside of the plugin and placing it somewhere in the core before returning the API response may be possible, but the difficult part is getting the DB object to pass to the hooks without an additional read since plugins only return dicts. On Mar 7, 2016 01:06, "Gary Kotton" <gkot...@vmware.com<mailto:gkot...@vmware.com>> wrote: I do not think that this is a bug in the plugin. Why are we not doing the changes in the base class (unless that is not possible). Having an extra read when a resources is created seems like a little of an overkill. I understand that it is what is done at the moment. I think that at the summit we should try and discuss how we can manage extensions better. Maybe the time has even come for us to consider the V3 neutron API and to make all of the ‘default core services’ as part of the official API. So we will not have to do certain hacks to get the plugins to work. From: Kevin Benton <ke...@benton.pub<mailto:ke...@benton.pub>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Sunday, March 6, 2016 at 11:27 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron][tempest] Timestamp service extension breaks CI Keep in mind that fix for ML2 is the correct behavior, not a workaround. It was not including extension data in create calls so there was an API difference between a create and a get/update of the same object. It's now calling the extensions to let them populate their fields of the dict. If you're plugin does not exhibit the correct behavior in this case, I would just disable the test in question because it sounds like a bug in the plugin, not the test. It's reasonable to expect the timestamps that will be visible on every other API call to also be visible in create calls. Hi, Gal Sagie pointed me to patch in ML2 and OVN that address this by re-reading the networks and ports to ensure that the information is read. For those interested and whom it affects please see: ML2 - https://review.openstack.org/#/c/276219/ OVN - https://review.openstack.org/#/c/277844/ Thanks Gary From: Gary Kotton <gkot...@vmware.com<mailto:gkot...@vmware.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Sunday, March 6, 2016 at 4:04 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Neutron][tempest] Timestamp service extension breaks CI Hi, The commit https://review.openstack.org/#q,4c2c983618ddb7a528c9005b0d7aaf5322bd198d,n,z causes the CI to fail. This is due to the fact that the port creation does not return the created_at and updated_at keys. The tempest test that the keys are the same. Please see [I] I posted patch https://review.openstack.org/289017 to address this. I am not sure if this is the correct way to go. There are far too many API changes that should not be breaking things at this very stage in the cycle. Thanks Gary [I] ft29.11: tempest.api.network.test_ports.PortsTestJSON.test_show_port[id-c9a685bd-e83f-499c-939f-9f7863ca259f,smoke]_StringException: Empty attachments: stderr stdout pythonlogging:'': {{{ 2016-03-06 01:05:00,301 27371 INFO [tempest.lib.common.rest_client] Request (PortsTestJSON:test_show_port): 200 GET http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.254.234-3A9696_v2.0_ports_f00d5dcc-2D4143-2D4f63-2D8c7c-2D0ea8d566c87b&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=TBTX0tiLXDShe3C9FIjjokzI-EnITvgOP23rd9HVi34&s=GQmpShCOo9jxGVEQsLHe2G4yxNLnpl6XvkQjnUxhQfc&e=> 0.245s 2016-03-06 01:05:00,302 27371 DEBUG [tempest.lib.common.rest_client] Request - Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 'X-Auth-Token': '<omitted>'} Body: None Response - Headers: {'status': '200', 'content-length': '532', 'content-location': 'http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.168.254.234-3A9696_v2.0_ports_f00d5dcc-2D4143-2D4f63-2D8c7c-2D0ea8d566c87b&d=BQMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=TBTX0tiLXDShe3C9FIjjokzI-EnITvgOP23rd9HVi34&s=GQmpShCOo9jxGVEQsLHe2G4yxNLnpl6XvkQjnUxhQfc&e=>', 'connection': 'close', 'date': 'Sun, 06 Mar 2016 09:05:00 GMT', 'content-type': 'application/json; charset=UTF-8', 'x-openstack-request-id': 'req-2825ed72-1417-4cf9-b37f-4894fa5b0b0f'} Body: {"port": {"status": "ACTIVE", "description": "", "allowed_address_pairs": [], "admin_state_up": true, "network_id": "4545014d-1e11-4b73-a5e3-bcdcd992478e", "name": "", "created_at": "2016-03-06T09:01:56", "mac_address": "fa:16:3e:08:a4:90", "updated_at": "2016-03-06T09:01:56", "vnic_index": null, "device_owner": "", "tenant_id": "e66f0c1efb664b05b34afc3d51903a1e", "port_security_enabled": true, "binding:vnic_type": "normal", "fixed_ips": [], "id": "f00d5dcc-4143-4f63-8c7c-0ea8d566c87b", "security_groups": [], "device_id": ""}} }}} Traceback (most recent call last): File "/opt/stack/tempest/tempest/api/network/test_ports.py", line 139, in test_show_port (port, excluded_keys=['extra_dhcp_opts'])) File "/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py", line 447, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: Only in expected: {'created_at': 2016-03-06T09:01:56, 'updated_at': 2016-03-06T09:01:56} __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
