[openstack-dev] [Neutron][tempest] Timestamp service extension breaks CI

Kevin Benton kevin at benton.pub
Mon Mar 7 09:45:36 UTC 2016


But that's the whole point of doing the read after the create in the
plugin. As long as you read after all db changes and call the dict extend
function, it should be the same.

As far as order goes, python doesn't guarantee order on dictionary keys. Or
did I misinterpret what you meant by order?
On Mar 7, 2016 01:41, "Gary Kotton" <gkotton at vmware.com> wrote:

> 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 <kevin at benton.pub>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Monday, March 7, 2016 at 11:23 AM
> To: OpenStack List <openstack-dev at 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" <gkotton at 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 <kevin at benton.pub>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: Sunday, March 6, 2016 at 11:27 PM
>> To: OpenStack List <openstack-dev at 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/
>> <https://review.openstack.org/#/c/277844/>*
>>
>> Thanks
>> Gary
>>
>> From: Gary Kotton <gkotton at vmware.com>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: Sunday, March 6, 2016 at 4:04 PM
>> To: OpenStack List <openstack-dev at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160307/e2c1f40c/attachment.html>


More information about the OpenStack-dev mailing list