Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-12
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
19:22:40 sdague mriedem: honestly, it's a really small straight forward change. I'll just approve
19:22:45 mriedem sc68cal: you know you're my favorite person in the world right? https://review.openstack.org/#/c/416585/
19:22:46 jaypipes mriedem: was it really just a matter of the expected and actual being reversed in the console.log test output and that confusing us?
19:22:56 mriedem jaypipes: no that wasn't it
19:23:15 dansmith sdague: plus it's me, so it's obviously bug-free
19:23:20 jaypipes hehe
19:23:20 mriedem jaypipes: it was in the expected because the nova test put it in there explicitly
19:23:29 mriedem jaypipes: it was'nt in the actual because the field wasn't set on the actual object
19:23:31 jaypipes mriedem: gotcha.
19:23:34 mriedem so it was omitted from the actual primitive
19:23:36 mriedem and kablammo
19:23:50 jaypipes mriedem: strange about the version being 1.1 in both actual and expected, though, no?
19:24:07 jaypipes or do I just need to re-caffeinate?
19:24:07 mriedem jaypipes: in this case it was using the latest object so i think 1.1 is expected,
19:24:49 mriedem jaypipes: no it was this https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L554
19:24:55 mriedem nothing in nova was setting that field yet
19:25:07 mriedem so ovo didn't include it in the actual primitive
19:25:46 mriedem sdague: if you're feeling saucy you could hit the dependent nova change too https://review.openstack.org/#/c/418141/
19:27:26 jaypipes saucy.
19:28:15 sean-k-mooney jaypipes: it was a sutble bug but mriedem fix resolves it. the nova tests should not have been setting the vif_name when it was not a field in the ovo
19:29:53 sean-k-mooney jaypipes: mriedem i just opend the reviews for adding gate-tempest-dsvm-nova-os-vif-ubuntu-xenial-nv to the experimental and then check pipelines for os-vif
19:30:14 sean-k-mooney jaypipes: mriedem https://review.openstack.org/419618 and https://review.openstack.org/419619
19:30:34 sean-k-mooney ill set the workflow to - one on moveing it to check untill i have tested it.

Earlier   Later