| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-12 | |||
| 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 | mriedem | jaypipes: it was in the expected because the nova test put it in there explicitly | |
| 19:23:20 | jaypipes | hehe | |
| 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 | mriedem | jaypipes: in this case it was using the latest object so i think 1.1 is expected, | |
| 19:24:07 | jaypipes | or do I just need to re-caffeinate? | |
| 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. | |
| 19:36:49 | bauzas | jaypipes: given https://review.openstack.org/#/c/392569/25..26/nova/api/openstack/placement/handlers/resource_provider.py maybe you could just +2/+W ? | |
| 19:39:59 | mriedem | bauzas: i'm going to get that one this afternoon | |
| 19:40:10 | mriedem | sorry it's taking awhile, i keep getting distracted | |
| 19:40:17 | bauzas | mriedem: <3 | |
| 19:42:35 | sdague | mriedem: done | |
| 19:45:12 | openstackgerrit | Claudiu Belu proposed openstack/nova: hyper-v: Adds support for VMs with nested virtualization https://review.openstack.org/398509 | |
| 19:45:13 | mriedem | sdague: thanks | |
| 19:56:36 | jaypipes | bauzas: I told mriedem yesterday I didn't feel comfortable +2/W'ing that one because I co-authored it... | |
| 19:56:48 | jaypipes | bauzas: was hoping either mriedem or dansmith might have a chance to review it. | |
| 19:56:49 | bauzas | ack | |
| 19:56:58 | bauzas | no worries | |
| 20:05:49 | mriedem | i've got a fresh cup of coffee | |
| 20:05:50 | mriedem | so it's time | |
| 20:10:16 | mriedem | ha saved by the project rename bell | |
| 20:13:28 | openstackgerrit | Mario Villaplana proposed openstack/nova: Add ironic security group support to support matrix doc https://review.openstack.org/419634 | |
| 20:15:46 | melwitt | dansmith: thanks for reviewing the quota objects migration. I hadn't seen an online migration done in a transaction before. how is it done? by passing a session to the methods? | |
| 20:25:49 | mriedem | melwitt: i believe he's en route | |
| 20:25:51 | mriedem | to the great white north | |
| 20:27:10 | mriedem | melwitt: can't that be done by using the @db_api.pick_context_manager_writer decorator? | |
| 20:27:16 | melwitt | mriedem: oh, thanks. I didn't know he left already | |
| 20:30:29 | melwitt | mriedem: I think so, if all the calls stay under one decorator. I have a loop that calls a method that is already decorated, so I guess if I break that out into a separate undecorated function, I could decorate the loop one and a non-loop one separately | |
| 20:30:47 | cfriesen | I'm in the great white north, it's -18F right now. Looking forward to Atlanta. | |
| 20:32:15 | melwitt | yikes -18F | |
| 20:32:54 | sean-k-mooney | melwitt: you can have multple decorators on the same fuction/class | |
| 20:33:13 | sean-k-mooney | melwitt: unless you ment it is allready decoated with @db_api.pick_context_manager_writer | |
| 20:36:53 | melwitt | sean-k-mooney: yeah, I mean the "create in db" method is already decorated with @db_api.pick_context_manager_writer and there's a loop doing several "create in db". so to do all of them in one transaction, I thought I have to move the decorator, or can they be nested? I hadn't seen nesting before | |
| 20:38:17 | sean-k-mooney | i dont know. if the decorate is opening the transation then it will do so when you enter the fucntion so all the actions in the loop should be in one transation | |
| 20:38:33 | sean-k-mooney | that said i have not read the code you are refering too | |
| 20:38:48 | sean-k-mooney | and gerrit is currently down so that is just a guess | |
| 20:40:47 | melwitt | sean-k-mooney: yeah, that's my understanding. I was thinking I can't just slap another decorator on the outside of the loop when there's one already on the method I'm calling (so that they nest). I'm not sure though | |
| 20:41:33 | sean-k-mooney | ah ok can you apply decoratos to loops directly? i have never tried that before | |
| 20:41:37 | melwitt | so I was thinking I would have to create a small wrapper function with the decorator for when I want to call it non-loop and move the decorator there | |
| 20:42:10 | melwitt | no, sorry, I meant apply the decorator to the outer function. the one that is doing a loop | |
| 20:42:58 | mriedem | melwitt: i'd ask rpodolyaka | |
| 20:43:03 | sean-k-mooney | ah ok. ya without seeing the code or trying it im not sure either | |
| 20:43:15 | mriedem | i see some stuff in the transaction factory code that looks like it can pull an existing session from the context | |
| 20:44:42 | melwitt | this is what it looks like, snippet http://paste.openstack.org/show/594765/ | |
| 20:45:34 | openstackgerrit | Sarafraj Singh proposed openstack/nova: Add service_token for nova-neutron interaction https://review.openstack.org/410394 | |
| 20:45:58 | melwitt | I haven't seen any nesting in db/sqlalchemy/api before, so I thought it wasn't a thing | |