Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-12
17:19:08 mriedem when this test was added to nova https://review.openstack.org/#/c/334048/11/nova/tests/unit/network/test_os_vif_util.py@575
17:19:13 jaypipes mriedem: we aren't yet sending osvif objects over the wire, though, so it may be we could do a hack of the object manifests with dansmith's help?
17:19:31 mriedem it's setting the vif_name which passed even though vif_name wasn't a field on that type in os-vif 1.3.0 which is what we were testing against
17:19:51 mriedem so...i guess when the test converts it to a primitive,
17:19:59 mriedem because vif_name wasn't a 'registered' field it just excluded it?
17:20:05 mriedem so the equality check was ok?
17:20:50 mriedem if that's the case, i'm not sure why vif_name isn't showing up on the actual object when we do the compare with os-vif 1.4.0 http://logs.openstack.org/21/418421/4/check/gate-cross-nova-python27-db-ubuntu-xenial/376a0f3/console.html#_2017-01-11_10_21_37_885392
17:21:34 jaypipes mriedem: vif_name is a field: https://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py#L65
17:21:37 mriedem jaypipes: these have obj_make_compatible methods
17:21:43 dansmith jaypipes: obj_relationships should not be used anymore
17:21:48 jaypipes https://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py#L77
17:21:53 mriedem jaypipes: vif_name wasn't a field in VIFHostUser until 1.1
17:22:04 jaypipes dansmith: yeah, I know, but I found no other way to fix that bug.
17:22:05 mriedem and ^ was just released in os-vif 1.4.0
17:22:07 jaypipes mriedem: ah.'
17:22:20 mriedem https://review.openstack.org/#/c/390225/7/os_vif/objects/vif.py
17:22:53 jaypipes mriedem: you sure about that? https://github.com/openstack/os-vif/commit/11af752a5af8a58a4f8fd5af196d1fce7729463d
17:22:59 jaypipes mriedem: shows added in 2015.
17:23:26 mriedem jaypipes: on which object?
17:23:34 mriedem we're not dealing with vif generic or bridge,
17:23:37 mriedem it's VIFHostUser
17:23:44 mriedem see https://review.openstack.org/#/c/390225/7/os_vif/objects/vif.py
17:24:07 mriedem that adds the vif_name field to VIFHostUser and bumps it's version to 1.1, and that change is released in os-vif 1.4.0, which is now breaking nova unit tests
17:24:17 mriedem http://logs.openstack.org/21/418421/4/check/gate-cross-nova-python27-db-ubuntu-xenial/376a0f3/console.html#_2017-01-11_10_21_37_885392
17:24:33 mriedem because vif_name is in our expected object on the nova side, but it's not in the actual obj we're getting from os-vif for some reason
17:25:27 jaypipes mriedem: hmm, yes, you're totally correct.
17:25:47 mriedem even though both primitives are showing
17:25:48 mriedem 'versioned_object.name': 'VIFVHostUser',
17:25:52 mriedem 'versioned_object.version': '1.1'}
17:25:54 jaypipes yup you're right.
17:26:32 jaypipes mriedem: weird... I wonder how https://github.com/openstack/os-vif/commit/345ff074b5dadc965b2298583124f32fc29dd2e4#diff-a2fd3d05a3b0a72438d0399e19c04469R152 ever worked then?
17:27:06 mriedem well that seems straight forward
17:28:09 jaypipes mriedem: sorry, I mean how the nova side didn't break when that was merged...
17:28:24 mriedem you mean when vif_name didn't exist in VIFHostUser?
17:28:38 mriedem i assume because it's not a registered field so the obj_to_primitive() ignored the field
17:28:42 mriedem so it wasn't in the primitive
17:28:47 mriedem you can set random attributes on versioned objects
17:28:58 dansmith correct
17:29:06 mriedem but the only thing that goes into the primitive is the fields
17:29:17 mriedem which in VIFHostUser 1.0 when that test was written didn't have a vif_name field
17:29:24 mriedem so it wouldn't be in the primitive and the nova test passed
17:29:24 jaypipes that are in the manifest for that version, yes.
17:29:47 mriedem unless i'm mistaken there isn't a manifest used in any of these tests
17:33:35 mriedem i think i have an easier fix than what i was trying
17:33:41 jaypipes mriedem: so I'm looking at that output in the console log from the unit test failure. really weird that the actual object has a version of 1.1 but doesn't include the vif_name field...
17:34:14 jaypipes mriedem: I mean, version 1.1 added the vif_name field and nothing else, no? so if it knows of the 1.1 object version, there should be a vif_name field.
17:34:32 mriedem jaypipes: right
17:34:38 mriedem i don't get that at all
17:35:11 mriedem unless it's somehow thinking it needs to backport to 1.0 for some reason
17:35:18 mriedem but i don't see anything telling it to do that
17:38:57 openstackgerrit Matt Riedemann proposed openstack/nova: Make unit tests work with os-vif 1.4.0 https://review.openstack.org/419558
17:39:00 mriedem so ^ should fix the nova test, but i'm kind of worried about what's actually going on on the os-vif side
17:40:59 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/415978
17:41:25 jaypipes mriedem: will try to look into this further in a bit. have meetings currently..
17:41:35 mriedem ok, i'm going to get some lunch
17:54:38 armax mriedem: hi
17:54:47 armax mriedem: do you happen to know if these types of errors are expected?
17:54:49 armax http://logs.openstack.org/08/418108/4/gate/gate-tempest-dsvm-neutron-src-neutron-lib-ubuntu-xenial/dafcfca/logs/screen-n-cpu.txt.gz?level=TRACE#_2017-01-12_16_59_40_818
17:55:06 armax or maybe jaypipes?
17:56:27 dansmith armax: they are early in the run yeah
17:56:38 dansmith I mean, they shouldn't be making a big fuss like they are, but...
17:56:46 armax dansmith: ok
17:57:07 dansmith armax: but
17:57:28 dansmith armax: a bit down, it says placement isn't responding, which should't be right unless placement isn't configured for this test, just a sec
17:58:01 dansmith armax: ah yeah no placement in that test, which is why you see the warnings
17:58:08 mriedem armax: it's because placement isn't up yet
17:58:09 armax dansmith: I haven’t looked much deeper than this log file
17:58:21 mriedem devstack starts n-cpu before placement
17:58:33 armax mriedem: I see
17:58:35 mriedem there is placement in this job http://logs.openstack.org/08/418108/4/gate/gate-tempest-dsvm-neutron-src-neutron-lib-ubuntu-xenial/dafcfca/logs/apache/placement-api.txt.gz
17:58:40 mriedem it's on by default in all jobs in master
17:58:45 mriedem it's just the startup order of the services
17:58:58 dansmith oh it's not in a screen, right
17:59:14 mriedem yeah
17:59:19 dansmith didn't see the log, but forgot it was under apache
17:59:21 mriedem armax: what i did notice yesterday was this http://logs.openstack.org/08/418108/4/gate/gate-tempest-dsvm-neutron-src-neutron-lib-ubuntu-xenial/dafcfca/logs/screen-n-cpu.txt.gz?level=TRACE#_2017-01-12_17_05_25_623
17:59:36 mriedem armax: ^ has started showing up a lot, it's not new either apparently
17:59:36 dansmith mriedem: but there are warnings much later in the run about not being able to contact placement
17:59:56 armax um
18:00:10 dansmith I guess it's only a minute later
18:00:37 mriedem http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22NeutronAdminCredentialConfigurationInvalid%3A%20Networking%20client%20is%20experiencing%20an%20unauthorized%20exception.%5C%22%20AND%20message%3A%5C%22deallocate_for_instance%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22%20AND%20voting%3A1&from=7d
18:01:53 mriedem http://logs.openstack.org/08/418108/4/gate/gate-tempest-dsvm-neutron-src-neutron-lib-ubuntu-xenial/dafcfca/logs/screen-n-cpu.txt.gz?level=TRACE#_2017-01-12_17_05_25_061
18:01:57 openstackgerrit John Garbutt proposed openstack/nova: Extract preallocate_for_instance https://review.openstack.org/418876
18:01:57 openstackgerrit John Garbutt proposed openstack/nova: Pass objects into _update_ports_for_instance https://review.openstack.org/418513
18:01:58 openstackgerrit John Garbutt proposed openstack/nova: Stop passing network when you only need dns_domain https://review.openstack.org/419577
18:02:00 mriedem Neutron client was not able to generate a valid admin token, please verify Neutron admin credential located in nova.conf
18:02:18 armax mriedem: let me look into that
18:02:24 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: [WIP][py35] Trying to get cinder+rally working https://review.openstack.org/419476
18:02:58 mriedem armax: ok i'll report a bug for it too just to track it
18:03:05 armax mriedem: cool
18:06:05 mriedem https://bugs.launchpad.net/nova/+bug/1656056
18:06:05 openstack Launchpad bug 1656056 in OpenStack Compute (nova) "NeutronAdminCredentialConfigurationInvalid all over n-cpu logs in successful gate runs during network teardown" [High,Confirmed]
18:08:37 mriedem armax: https://review.openstack.org/#/q/b8a05333ddc4e248e18080750e3cfa9cbedbca53 ?
18:10:07 mriedem nvm that's not released yet
18:13:27 mriedem could also be this https://review.openstack.org/#/c/407147/
18:14:39 openstackgerrit Rafael Folco proposed openstack/nova: DELETE all inventory for a resource provider https://review.openstack.org/416669
18:18:46 openstackgerrit John Garbutt proposed openstack/nova: WIP: Call preallocate_for_instance before scheduler https://review.openstack.org/413124
18:18:46 openstackgerrit John Garbutt proposed openstack/nova: WIP: introduce preallocate_for_instance method. https://review.openstack.org/418881
18:30:53 openstackgerrit Dan Smith proposed openstack/nova: WIP: Make api_samples tests use simple cell environment https://review.openstack.org/410473
18:30:57 openstackgerrit Dan Smith proposed openstack/nova: WIP Move instance creation to conductor https://review.openstack.org/319379

Earlier   Later