Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-12
18:47:16 dansmith mriedem: it passes in a manifest of what it wants the system to think the remote looks like
18:47:24 mriedem sean-k-mooney: it's a chicken and egg, we can't merge https://review.openstack.org/#/c/418421/
18:47:30 mriedem because the nova unit tests are failing in that chnage
18:47:44 dansmith mriedem: in that test it mocks get_versions or whatever, but there are others in there that just pass a manifest with one or two object versions
18:49:53 sean-k-mooney your right hum ok im just trying to figure out what is different between them.
18:50:24 sean-k-mooney ah the 'vif_name': u'nicdc065497-3c'
18:50:29 mriedem sean-k-mooney: yeah :)
18:50:49 mriedem it's in the expected object from the nova test, but not in the actual object from the os-vif side
18:50:57 mriedem which is weird because it's version on the object is 1.1
18:51:02 mriedem which was the version when vif_name was added to VIFHostUser
18:51:09 mriedem oh but you said,
18:51:13 sean-k-mooney the expect result is incorrect as before os-vif 1.4 that field did not exist
18:51:15 mriedem we don't use that yet?
18:51:23 mriedem sean-k-mooney: yeah that's another thing i noted earlier
18:51:26 mriedem and removed in my fix patch,
18:51:29 mriedem but maybe that's just the fix?
18:52:05 mriedem i'll try that out as i have a recreate locally
18:52:15 sean-k-mooney https://review.openstack.org/#/c/410737/2 is the change that should add the vif_name to the unit test
18:52:35 mriedem farq
18:52:40 mriedem ok, well just removing vif_name makes it work
18:52:44 mriedem so i'll cleanup my patch
18:52:44 sean-k-mooney yes
18:53:17 sean-k-mooney so if you remove it now it can be reintoduce in https://review.openstack.org/#/c/410737/2 when the filed actully exists in the os-vif object
18:54:51 sean-k-mooney this is related to a previous conversation i had with danile berange about the fact that oslo versioned objects allows you to set filds in objecst that are not in the defined set of fields
18:56:25 mriedem yeah...i remember that
18:56:32 mriedem we use it to our advantage at times in nova,
18:56:51 mriedem for fields we want to set in the nova-net layer for example and then those are used in the nova-api layer, but aren't persisted in the nova db
18:57:14 mriedem i think i had mentioned at some point about changing ovo to add a flag to be strict about which attributes can be set
18:57:43 openstackgerrit Matt Riedemann proposed openstack/nova: Make unit tests work with os-vif 1.4.0 https://review.openstack.org/419558
18:57:52 sean-k-mooney yes you had. by the way i just book my ptg flights/hotel. one thing i would like to add to os-vif is a dsvm gate to increase the level of testing.
18:58:20 mriedem want to throw that in https://etherpad.openstack.org/p/nova-ptg-pike ?
18:58:29 sean-k-mooney im not sure it would have caught this but it would be better to have some intergration testing of os-vif
18:59:08 sean-k-mooney am sure. should i add a generic os-vif section or just os-vif gateing
18:59:23 sean-k-mooney there is also the topic of neutron intergration
18:59:33 sean-k-mooney i would like to complete that in pike also
19:00:14 mriedem sean-k-mooney: i think there is a job in the nova experimental queue that already does that
19:00:59 mriedem sean-k-mooney: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L12513
19:01:14 sean-k-mooney mriedem: perhaps. i would like to add a job to os-vif though that tested with the head of nova/neutron master too with the os-vif change
19:01:28 mriedem i think that's what that job does
19:02:00 mriedem https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L462
19:02:11 mriedem export PROJECTS="openstack/os-vif $PROJECTS" export DEVSTACK_LOCAL_CONFIG+=$'\n'"LIBS_FROM_GIT=os-vif"
19:02:14 sean-k-mooney yes but that only runs on chnage to nova
19:02:35 mriedem sean-k-mooney: you just have to add that job to the os-vif template in layouts.yaml then
19:02:37 sean-k-mooney i would like to basically add that jobe to the check pipeline for os-vif
19:02:38 mriedem if you want to run that job on os-vif
19:02:43 mriedem then make it so :)
19:02:44 sean-k-mooney yep
19:02:54 mriedem honestly i don't know why danpb didn't do that originally
19:03:16 mriedem you can cancel your PTG flight and hotel now, problem solved :)
19:03:36 sean-k-mooney ok i will, should i add it to check experimental first to make sure it works.
19:03:52 mriedem in os-vif? that's probably not a bad idea
19:03:58 sean-k-mooney mriedem: i have some other things to adress too :) but that is one less item
19:04:16 mriedem goes in here somewhere https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L13748
19:04:39 sean-k-mooney mriedem: ok ill submit a patch to add it to check experimental and then do some testing. if it works ill move it to the main check pipeline for os-vif
19:04:49 mriedem cool
19:06:44 mriedem jroll: i just remembered https://review.openstack.org/#/c/247904/
19:06:59 mriedem you might want to get that in before you request an ironicclient release, or just know you'll have to do two
19:07:44 jroll mriedem: yep, it's on my list
19:07:59 mriedem sean-k-mooney: http://logs.openstack.org/21/418421/5/check/gate-cross-nova-python27-db-ubuntu-xenial/a12bd2b/ is happy now
19:08:02 mriedem so u-c should be good soon
19:08:37 sean-k-mooney cool glad the solution was found before any of the requirements go bumped.
19:11:56 mriedem melwitt: i'm +2 on dan's bottom change now for cells v1 glory https://review.openstack.org/#/c/418141/
19:12:14 EmilienM dansmith, mriedem: I have a good news
19:12:15 mriedem there is a nit in one of the code comments that could be addressed on top of that change
19:12:30 EmilienM the patch in nova that fixed the placement retry thing, works very well
19:12:34 mriedem 0 days without a TripleO incident?!
19:12:36 EmilienM you can see it in the logs
19:12:41 EmilienM first it fails http://logs.openstack.org/04/419604/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/5d95a8c/logs/nova/nova-compute.txt.gz#_2017-01-12_18_54_42_715
19:12:51 EmilienM then it works http://logs.openstack.org/04/419604/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/5d95a8c/logs/nova/nova-compute.txt.gz#_2017-01-12_18_55_46_155
19:12:57 EmilienM (thx again)
19:13:42 mriedem cool
19:13:50 mriedem on a side note, http://logs.openstack.org/04/419604/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/5d95a8c/logs/nova/nova-compute.txt.gz#_2017-01-12_18_53_43_459
19:15:42 EmilienM mriedem: mhh, is it placement endpoint not reachable from creds in [placement] ?
19:15:53 EmilienM oh no I know
19:15:58 EmilienM let me confirm, a sec
19:16:01 mriedem my guess is bad auth_plugin?
19:16:41 mriedem placement.auth_type = password
19:16:44 mriedem i guess i don't know
19:16:47 EmilienM mriedem: http://logs.openstack.org/04/419604/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/5d95a8c/logs/puppet-20170112_185646.txt.gz#_2017-01-12_18_55_40
19:16:58 EmilienM the keystone stuff were created *after* starting nova compute
19:17:04 EmilienM but thanks to the retry, we don't care
19:17:11 EmilienM because it retries and works a few min later
19:17:31 mriedem yeah we just don't want the stacktrace
19:17:41 mriedem anyway it's a low-priority bug for nova to handle that https://bugs.launchpad.net/nova/+bug/1656075
19:17:42 openstack Launchpad bug 1656075 in OpenStack Compute (nova) "DiscoveryFailure when trying to get resource providers from the scheduler report client" [Low,Confirmed]
19:17:50 EmilienM mriedem: "Created resource provider record via placement API for resource provider with UUID 5c4bb2d9-60bd-46e3-bb2a-eb6730932c63 and name centos-7-osic-cloud1-s3500-6631948."
19:18:00 EmilienM mriedem: I think this ^ means keystone auth worked at some point
19:18:07 mriedem EmilienM: yes it did
19:18:14 EmilienM cool
19:18:32 mriedem we handle some known KSA failures when trying to make a connection to the placement endpoint,
19:18:41 mriedem but there are many ways KSA can fail and we don't handle them all apparently
19:19:21 mriedem jaypipes: dansmith: https://review.openstack.org/#/c/419558/ is good to go
19:19:34 mriedem the upper-constraints job passed on that http://logs.openstack.org/21/418421/5/check/gate-cross-nova-python27-db-ubuntu-xenial/a12bd2b/
19:20:52 dansmith nice
19:21:38 mriedem sdague: you said mtreinish is en route to AU?
19:21:45 mriedem sdague: because we're good with https://review.openstack.org/#/c/416585/ now
19:21:46 sdague mriedem: yeh
19:21:54 mriedem time to rassle up some other devstack cores
19:22:16 jaypipes mriedem: wallaby'd. amazing how simple a fix was in the end..
19:22:31 mriedem jaypipes: yeah, plus stepping away for lunch helped

Earlier   Later