Yeah, it sounds like maybe there is a bug in the extension processing for port bindings if the VNIC type isn't returned for a get. Does ML2 exhibit the same behavior? On Mar 7, 2016 02:08, "Salvatore Orlando" <[email protected]> wrote:
> > > On 7 March 2016 at 10:54, Gary Kotton <[email protected]> wrote: > >> There are a number of issues here: >> >> 1. The create returns additional values, for example the >> binding:vnic_type, >> whilst the get does not >> >> This is probably a consequence of fixing the behaviour mismatch between > create and get. > > >> >> 1. We have some unit tests that we need to change (I guess), that >> check function parameters. An example for this is the network passed to a >> method. With the extra extensions this is now changed. In addition to this >> the create and the get order of the parameters is different >> >> Fixing those unit tests should not be a big deal. We can assert only on > the key we wants to validate and not on the whole call. > > > >> Thanks >> Gary >> >> From: Kevin Benton <[email protected]> >> Reply-To: OpenStack List <[email protected]> >> Date: Monday, March 7, 2016 at 11:45 AM >> >> To: OpenStack List <[email protected]> >> Subject: Re: [openstack-dev] [Neutron][tempest] Timestamp service >> extension breaks CI >> >> 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" <[email protected]> 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 <[email protected]> >>> Reply-To: OpenStack List <[email protected]> >>> Date: Monday, March 7, 2016 at 11:23 AM >>> To: OpenStack List <[email protected]> >>> 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" <[email protected]> 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 <[email protected]> >>>> Reply-To: OpenStack List <[email protected]> >>>> Date: Sunday, March 6, 2016 at 11:27 PM >>>> To: OpenStack List <[email protected]> >>>> 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 <[email protected]> >>>> Reply-To: OpenStack List <[email protected]> >>>> Date: Sunday, March 6, 2016 at 4:04 PM >>>> To: OpenStack List <[email protected]> >>>> 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: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
