Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-18
17:16:32 dansmith or windows 98
17:16:53 sean-k-mooney centos 5 hates virtio block devices for root disks...
17:17:17 sean-k-mooney i think anything pre windows 7 did not ship virtio driver by default
17:17:29 sean-k-mooney well vista might have
17:20:01 dansmith I didn't know any did
17:20:03 dansmith that's major progress
17:20:38 imacdonn yeah, I didn't think Windows came with any VirtIO drivers either
17:21:45 imacdonn I do know that the drivers have a vendor ID associated with them, and that matters for Windows Update .. because Oracle has our version, which has a different vendor ID than the Red Hat / Fedora ones
17:21:52 sean-k-mooney windows 10 does i belive 7 and 8 both require installation duuring install time either from an iso or a web share but i was under teh impression you could donwloading from windows update during install
17:23:15 sean-k-mooney imacdonn: the vendor id and prodoct id for virtio devices is an oasis standard now as far as i am aware
17:23:45 sean-k-mooney imacdonn: yep https://www.oasis-open.org/committees/virtio/
17:29:02 cfriesen does anyone know how we handle UEFI NVRAM over shelve/unshelve? I'm guessing it's currently lost, the same way it's lost over cold migration and resize.
18:02:38 openstackgerrit Chris Friesen proposed openstack/nova-specs master: Add support for emulated virtual TPM https://review.openstack.org/571111
18:16:21 imacdonn mriedem: re backporting https://review.openstack.org/608091 ... I'd like to... I wonder if we need to do anything special, like a further release note that says that this changed after the initial release, or something....
18:17:48 mriedem there is already an upgrade release note on it saying there is a new return code
18:18:33 imacdonn yeah. I'm just pondering that it wasn't part of the original release ... I may be overthinking it
18:19:32 mriedem original release...being whenever online_data_migrations was added?
18:19:53 mriedem i think you're overthinking it
18:20:12 imacdonn no, I mean, when Rocky was released, this change was not part of it .. but it's going to magically appear in an update release
18:20:55 mriedem idk, we could just signal that by bumping the minor version on the release rather than the patch version
18:23:02 imacdonn that seems like a reasonable idea ... probably won't make much difference in reality, but trying to do the right thing
18:24:59 imacdonn it looks like a clean CP for Rocky ... a couple of easy conflicts for Queens .. haven't tried to go further than that yet
18:32:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Document each libvirt.sysinfo_serial choice https://review.openstack.org/611426
18:32:28 openstackgerrit Artom Lifshitz proposed openstack/nova stable/pike: Handle volume API failure in _post_live_migration https://review.openstack.org/611093
18:38:06 openstackgerrit Dan Smith proposed openstack/nova master: Make CellDatabases fixture reentrant https://review.openstack.org/611665
18:38:06 openstackgerrit Dan Smith proposed openstack/nova master: Modify get_by_cell_and_project() to get_not_deleted_by_cell_and_project() https://review.openstack.org/607663
18:38:07 openstackgerrit Dan Smith proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785
18:38:07 openstackgerrit Dan Smith proposed openstack/nova master: Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934
18:38:08 openstackgerrit Dan Smith proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658
18:38:08 openstackgerrit Dan Smith proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829
18:39:15 dansmith I don't think that fixes all the tests, but a bunch, and figure it'll be quicker to let zuul have a crack at it
18:40:44 melwitt what a slacker
18:57:59 mriedem dansmith: thinking out loud on how to break up my cross-cell-resize patch, i'm thinking: db model changes, versioned objects, compute (manager/rpc), compute API and then conductor at the end. API before conductor because conductor is what will set the Migration.cross_cell_move flag that makes the flow change. sound sane? everything else in the API is keyed off that migration.cross_cell_move flag.
19:18:25 openstackgerrit sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116
19:18:40 dansmith mriedem: sure
19:20:28 mriedem artom: can you just fix the comment nit in https://review.openstack.org/#/c/587439/ and then i'm +2
19:23:31 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Cross-cell resize https://review.openstack.org/603930
19:26:35 openstackgerrit iain MacDonnell proposed openstack/nova stable/rocky: Handle online_data_migrations exceptions https://review.openstack.org/611701
19:26:54 eandersson Why is the api version part of the endpoint in keystone? Is this a requirement or just a best practice?
19:27:04 eandersson > "$nova_api_url/v2.1"
19:27:23 artom mriedem, yep, thank you :) Who can we pester for your patch below mine? (This is another downstream pressure type situation)
19:27:48 mriedem probably one of the many red hat cores
19:28:03 melwitt haha, yeah. I was gonna say, you can pester me
19:28:09 mriedem eandersson: good question for mordred
19:28:41 mordred I didn't do it
19:28:45 eandersson :D
19:29:05 artom melwitt, consider yourself pestered :D
19:29:14 melwitt :)
19:29:28 mordred eandersson: either $nova_api_url/v2.1 or $nova_api_url should totally work with keystoneauth/openstacksdk/shade
19:29:46 mordred eandersson: I think there are some older things out there that assume the thing in the catalog has the version appended
19:30:29 mordred but for nova I believe most of them do the right thing either way
19:30:41 eandersson So there might be an edge case that does not handle it properly
19:30:58 mordred I *personally* prefer unversioned endpoint in catalog because putting versioned endpoint in catalog is what got us into the wole volumev2 volumev3 service-type mess
19:31:41 mordred but I'm pretty sure nova isn't going to have a new major version in the new future, so putting a versioned nova endpoint in the catalog should be fine
19:31:56 mordred hopefully you're enjoying how I'm not giving you an answer at all
19:33:40 eandersson Yea I agree on unversioned
19:33:50 eandersson It's also causing minor issues for us with a api proxy
19:34:00 eandersson but might just be my lack of knowledge on nginx
19:34:46 eandersson hehe
19:49:54 openstackgerrit melanie witt proposed openstack/nova master: Add nova-status upgrade check for consoles https://review.openstack.org/611214
19:49:55 openstackgerrit melanie witt proposed openstack/nova master: Add rolling upgrade info to enable_consoleauth workaround reno https://review.openstack.org/611218
20:10:30 openstackgerrit Artom Lifshitz proposed openstack/nova master: Ensure attachment cleanup on failure in driver.pre_live_migration https://review.openstack.org/587439
20:10:35 artom mriedem, ^^
20:15:05 artom Cheerio :)
20:36:48 mriedem efried: gibi: hoowee i just went through https://review.openstack.org/#/c/606050/
20:36:50 mriedem kind of a doozy
20:37:29 mriedem dansmith: i believe ^ will mean that if we ever go down the non-migration-based allocation cleanup route on a same-host resize, we'll wipe out all allocations for the instance, including for the old_flavor
20:37:44 mriedem but, i'm not sure how possible that is today unless you have <queens computes in a cell
20:37:49 mriedem which shouldn't happen if you're running stein
20:37:53 tonyb mriedem: Oh gosh that's a question ... I'll research it and see
20:38:04 mriedem tonyb: i forgot the question
20:38:37 tonyb mriedem: is emulatedTPM supported on kvm on power
20:38:44 mriedem oh
20:39:04 tonyb I have the spec open and I'll go read some code when I get off this meeting
20:40:28 mriedem i'm going to shift gears and do something fun like delete the caching scheduler
20:57:26 efried mriedem: Left responses to some of your queries. The main one I can't answer, though.
20:57:49 mriedem where do babies come from?
20:57:50 mriedem that one?
21:03:49 openstackgerrit Merged openstack/nova master: Merge image_size extension response into image view builder https://review.openstack.org/606845
21:12:30 cdent mriedem: do you recall if somebody already thought about postgresql with regard to https://review.openstack.org/#/c/611115/ ? Since it is a group by it might cause the "must appear in the GROUP BY" error. But I can't remember if that only happens if you use an agg function.
21:13:07 cdent So I started a check experimental on it, but then realized the tempest-pg-full won't run the functional tests that exercise the problem. Is there anything else that will?
21:13:26 mriedem nope
21:13:44 mriedem the only mysql/pg-specific stuff that runs in func/unit tests are the schema migration tests
21:14:18 mriedem the alternative is using DISTINCT in there as efried pointed out
21:15:07 efried I tried ^ locally and it worked, but no idea what that means.
21:15:18 efried I've been wanting to ask jay what the difference is.
21:15:39 efried He +2d the change, so he must've thought GROUP BY was fine, but...
21:16:13 cdent it's perfectly fine as is for mysql, but _might_ be a problem for pg
21:17:35 cdent I can poke at it (/me looks at queue ... ) Monday if nobody else wants/needs to. mriedem do you think this will tickle the problem?
21:18:02 cdent as in: do we need to care about this?
21:18:47 mriedem what will tickle the problem?
21:19:11 mriedem i don't know enough about group by rules for pg
21:19:41 mriedem you could probably recreate it with just placement and a pg db,
21:20:05 mriedem by having a consumer with >1 allocation against a resource provider and there not being any consumers table record for the allocations
21:20:09 mriedem so just hack it up manually
21:22:23 cdent What I meant was: is this the type of group by that postgresql will wail at? It will be easy enough to mess with manually. But for me, I won't have time before Monday
21:23:20 mriedem i don't know the answer to that
21:23:38 mriedem zzzeek_ might know off the top of his head
21:26:33 cdent i've left a note on the review, if nothing happens before next week, I'll dig
22:02:32 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove the CachingScheduler https://review.openstack.org/611723

Earlier   Later