Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-25
19:34:27 efried all birthdays are suspended pending RC1
19:34:30 sean-k-mooney efried: ya as i said i have one nit that i noted on ps3 were its not quite correct but its better then it was and it can be fixed up later
19:34:37 ozzzo I watched kashyap's video last week when I was figuring out which cpu_mode I wanted. Unless I missed something, he doesn't specifically address what will happen when microcode updates
19:35:01 ozzzo if microcode updates won't ruin live migration, then I definitely want to use host-passthrough
19:35:14 sean-k-mooney the check is done by libvirt not nova
19:35:20 ozzzo even if they will, I still want to use it, if I can disable upgrade
19:35:26 sean-k-mooney for host-passthough i belive libvirt will require they are the same
19:35:38 sean-k-mooney for host model i am not sure
19:36:05 ozzzo I guess I should do an experiment
19:37:15 sean-k-mooney mriedem: i have a beer chilling in the fridge and im about to go play a game on my other monitors so im not really working at the momemt other then chating on irc
19:37:39 sean-k-mooney but i also wont really be paying attention to irc shortly either
19:38:06 ozzzo oic kashyap is here, nice
19:38:27 ozzzo I'll ask him tomorrow morning
19:54:40 dustinc mriedem: Thanks for heads up regarding bp, the spec was reintroduced but with same/old bp. (https://review.opendev.org/#/c/680471/). How do I find the old bp to use it for reference? I search here and it does not show up: https://blueprints.launchpad.net/openstack?searchtext=openstacksdk-in-nova
19:55:11 dustinc oops ignore that, I was mixing links
19:55:35 dustinc been bouncing back and forth between two things, found the bp
19:58:18 mriedem rps
19:58:22 mriedem oops
19:58:25 mriedem https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova
19:58:42 mriedem yeah so the spec should be re-proposed for ussuri with the new openstack-sdk-in-nova-ussuri blueprint
19:59:20 mriedem https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications
20:05:58 dustinc ok i will check that out, basically I just want to update the bp with what has already been done and clarify what is still left?
20:06:42 dustinc and then reintroduce spec per the readme link you posted?
20:06:52 mriedem efried: ok i think i have a recreate on that ironic rebalance race bug, it's pretty hairy but it does the job i think
20:13:37 efried mriedem: we can do "previously approved" with continuation bps?
20:14:41 mriedem i don't really see why not
20:14:56 dustinc mriedem: I am reading this but still a bit confused regarding what I need to do with the bp itself, do I need to register a new bp as well? https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications
20:16:05 dustinc https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle
20:23:14 mriedem dustinc: yes
20:23:27 dustinc thanks
20:23:54 mriedem dustinc: register a new blueprint called openstacksdk-in-nova-ussuri, the description should just link to https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova and say something to the effect of it's continuing the work started in the train release
20:24:28 mriedem as for re-proposing the spec, you'll copy specs/train/approved/openstacksdk-in-nova.rst to specs/ussuri/approved/openstacksdk-in-nova-ussuri.rst
20:25:04 mriedem that's a bit different from https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications because the name changes - i think this is the first time we've had a multi-release continuation blueprint thing like this for specs
20:25:07 mriedem so it's different and weird
20:25:25 mriedem when efried did the ksa-ification there was a spec so i don't remember what he did between releases
20:25:35 mriedem we might have just never completed the blueprint until that work was done, idk
20:26:29 efried Personally I really don't care how we track it. We already marked the current bp complete for Train, but... is it possible to un-mark it and instead push it to ussuri?
20:27:08 efried I marked it complete because we completed part of the work, and I figured we would want a new proposal for ussuri that describes what we got done, what we're going to do next, and what, if anything, has changed about the roadmap.
20:27:27 efried but that's more a statement of the spec than the bp
20:29:36 efried dustinc, mriedem: yeah, that seemed to work fine https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova
20:29:41 efried so just reuse the same bp dustinc ^
20:30:26 efried but I think the new spec should differ as noted, so probably not a fast-approval thing.
20:30:35 efried but still should be fairly trivial.
20:31:41 openstack bug 1841481 in OpenStack Compute (nova) "Race during ironic re-balance corrupts local RT ProviderTree and compute_nodes cache" [Medium,In progress] https://launchpad.net/bugs/1841481 - Assigned to Eric Fried (efried)
20:31:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1841481 https://review.opendev.org/684840
20:31:42 mriedem efried: ^ hopefully with all of the comments that is clear enough
20:31:54 efried ack
20:32:08 mriedem efried: for multi-release things we usually mark the bp as partially complete
20:32:15 mriedem and then create a new bp with the -<new release>
20:32:18 mriedem like with mox removal
20:32:24 efried yeah
20:32:41 efried Where/how/why does it matter which way we do it?
20:32:49 efried aka "who cares?"
20:33:02 mriedem idk that it does all that much, you'll just be carrying that spec forward for a long time potentially
20:33:17 mriedem but that's what you did with ksa-ification i think
20:33:33 efried which still isn't complete, really :(
20:33:49 mriedem cinder was the only one not done wasn't it? or also barbican/castellan?
20:34:01 efried cinder yes. I think we decided barbican was a no-op.
20:35:36 mriedem ah crap need to add the test
20:36:06 openstack bug 1841481 in OpenStack Compute (nova) "Race during ironic re-balance corrupts local RT ProviderTree and compute_nodes cache" [Medium,In progress] https://launchpad.net/bugs/1841481 - Assigned to Eric Fried (efried)
20:36:06 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1841481 https://review.opendev.org/684840
20:49:00 efried I will pay attention to this after RC1
20:49:10 efried noting that I'm going to look for an opportunity to take some pto soon.
21:03:55 openstackgerrit Eric Fried proposed openstack/nova master: doc: attaching virtual persistent memory to guests https://review.opendev.org/680300
21:07:22 efried alex_xu, stephenfin: Please merge this ^ asap assuming you're happy.
21:21:20 efried mriedem, stephenfin: Can one/both of you +A the prelude patch https://review.opendev.org/#/c/683327/ at this point so it gets in line after the deps?
21:22:34 mriedem done
21:22:50 efried thx
21:23:45 mriedem zzzeek: if you're about, i have a test which keeps failing trying to insert a resource to the db with this:
21:23:46 mriedem sqlalchemy.exc.InvalidRequestError: This session is in 'inactive' state, due to the SQL transaction being rolled back; no further SQL can be emitted within this transaction.
21:24:01 mriedem it's using a transaction factory context manager thing from oslo.db,
21:24:05 zzzeek mriedem: that woudl suggest someting went wrong prior to the thing you are trying t do
21:24:23 zzzeek like, youre in an exception handler or something like that
21:24:24 mriedem i would think if there was a problem with the insert, like a unique constraint failure or something, it'd be logged but i'm not seeing that
21:24:30 mriedem ah...
21:24:38 mriedem yes there is one of those in play
21:24:59 zzzeek mriedem: so, say you're in an exception throw, then you try to do somethign with an object, and something on it isn't loaded
21:25:03 zzzeek mriedem: that would cause this
21:25:24 zzzeek err inside a catch, that is
21:26:14 mriedem yeah it's blowing up from the transaction context manager added here: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L691
21:26:25 mriedem and likely from something in https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L703
21:26:56 mriedem the weird thing is i'm hitting this https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L716
21:26:59 mriedem so it shouldn't be re-raising
21:29:44 mriedem oh maybe this is failing https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L745
21:29:50 mriedem adding some try/except/log
21:30:20 mriedem nope not hitting that
21:30:33 mriedem i'm definitely getting here https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L716
21:39:34 openstackgerrit Eric Fried proposed openstack/nova master: Conf option cross-reference in config docs https://review.opendev.org/583025
21:41:12 zzzeek mriedem: these are hard to debug
21:41:50 mriedem so we have another test that does this same thing but only within 1 nova-compute service, so i'm wondering if it's something with the thread local context stuff in oslo.db
21:41:55 mriedem b/c this test has 2 services using the same context
21:42:30 mriedem the other one was https://review.opendev.org/#/c/675496/ and things worked like a charm there
21:42:48 mriedem we hit DBDuplicateEntry, then do a get-and-update and squash the re-raise
21:42:52 mriedem but that's not working this time
21:47:38 efried dustinc: It looks like the ironic CI is failing again on service discovery, but I'm not sure why...
21:51:29 efried maybe not discovery
22:09:38 openstackgerrit Matt Riedemann proposed openstack/nova master: Clear RT.compute_nodes entry if re-balance update fails https://review.opendev.org/684849
23:10:57 openstackgerrit Merged openstack/nova master: Ignore sqla-migrate inspect.getargspec deprecation warnings on py36 https://review.opendev.org/684781
23:11:04 openstackgerrit Merged openstack/nova master: Ignore warning from sqlalchemy-migrate https://review.opendev.org/684772
23:11:10 openstackgerrit Merged openstack/nova master: docs: Clarify everything CPU pinning https://review.opendev.org/683437

Earlier   Later