Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-18
15:56:55 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
15:56:55 openstackgerrit Dan Smith proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658
15:56:56 openstackgerrit Dan Smith proposed openstack/nova master: Make CellDatabases fixture reentrant https://review.openstack.org/611665
15:57:21 dansmith mriedem: that last one there is the fixture change.. would appreciate careful scrutiny
15:57:36 dansmith seems to pass all existing tests and fix the (related) ones in the down cell stuff
16:02:00 dansmith mriedem: on that compute node uuid backport,
16:02:03 dansmith I wanted to go think about it a little
16:02:55 dansmith I thought there were some assumptions that the ironic node uuid was the same as the compute node uuid, so you could correlate the resource provider
16:02:56 dansmith but I also know we use the name (which is the ironic uuid)
16:03:01 dansmith was that all worked out on the original?
16:03:47 mriedem "I thought there were some assumptions that the ironic node uuid was the same as the compute node uuid" has never been the case
16:04:00 mriedem before that change, the compute node uuid was always randomly generated when we created the record
16:04:07 mriedem the compute node hypervisor_hostname is the ironic uuid
16:05:14 mriedem https://github.com/openstack/nova/blob/stable/queens/nova/compute/resource_tracker.py#L585
16:05:27 mriedem https://github.com/openstack/nova/blob/stable/queens/nova/objects/compute_node.py#L312
16:05:27 dansmith right
16:05:40 dansmith okay I see the breaking change was just a "it would be nice" so.. okay
16:05:45 mriedem yeah
16:05:49 dansmith there was that rebalance bug that was fixed,
16:05:59 dansmith so I wanted to make sure it wasn't related to that,
16:06:08 dansmith but I was deep in that fixture debug so I didn't chase
16:06:11 dansmith so cool enough
16:07:07 mdbooth cfriesen: Fun
16:07:43 mdbooth cfriesen: I haven't looked at the code, but I'm imagining it's probably going to be reasonably well confined to the libvirt driver.
16:08:07 mdbooth IIRC the address assignment code is a bit janky
16:11:27 melwitt mriedem_lunch: I didn't send a reminder email about specs in runways but I updated the text on the etherpad to say "Queue of Approved blueprints"
16:14:28 sean-k-mooney melwitt: by the way im planning to rebase my sriov livemigration spec and add it to next weeks nova team open discussion but i was wondering what i should do with the blueprint. its still pending review/approval. should i add that also?
16:14:58 melwitt sean-k-mooney: add it to open discussion? if you have the spec linked, I think that's enough
16:15:57 sean-k-mooney ok cool. i have some rework to do for the spec but it should be ready for more review by then
16:43:47 melwitt cfriesen: do you know if 'virtio-scsi' is the same thing as having the disk_info['bus'] == 'scsi' or are they not necessarily the same thing? I added a comment to the lp bug
16:46:00 cfriesen melwitt: not sure. not my area of expertise.
16:46:49 melwitt oops, sorry. mdbooth maybe then ^
16:48:34 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779
16:52:00 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Add spec for libvirt driver launching AMD SEV-encrypted instances https://review.openstack.org/609779
16:53:21 imacdonn melwitt: not a specialty area for me either, but it looks like it might also want the controller model to be specified: https://ovirt.org/develop/release-management/features/storage/virtio-scsi/
16:54:17 imacdonn melwitt: also https://libvirt.org/formatdomain.html#elementsControllers
16:54:28 melwitt thanks imacdonn. I'm also reading through the original RFE that added the virtio-scsi disk numbering to the libvirt driver
16:55:14 openstack bugzilla.redhat.com bug 1269577 in openstack-nova "[RFE] Support more than six Virtio SCSI disks on a single bus controller" [Medium,Closed: errata] - Assigned to sferdjao
16:55:14 melwitt https://bugzilla.redhat.com/show_bug.cgi?id=1269577
16:56:28 dansmith melwitt: you can expose disks to a guest via scsi in multiple ways, virtio-scsi being one
16:56:40 dansmith there's a sym5cxx model as well, IIRC
16:57:00 dansmith probably not likely to be common these days, but it should still be supported AFAIK
16:57:13 imacdonn "A scsi controller has an optional attribute model, which is one of 'auto', 'buslogic', 'ibmvscsi', 'lsilogic', 'lsisas1068', 'lsisas1078', 'virtio-scsi' or 'vmpvscsi'."
16:57:24 dansmith yeah
16:57:33 melwitt ok, yeah. the idea of that RFE was to have nova control the disk unit numbers only if using the virtio-scsi controller type
17:03:12 melwitt incremented but was never initialized
17:03:12 melwitt AFAICT, the scsi controller type is only gettable from the image meta, so we're running into a problem if no image has been specified in the boot request. we initialize the disk numbering if model == 'virtio-scsi' there are other conditionals in the libvirt driver which are incrementing disk unit numbers only if 'bus' == 'scsi' (and not checking the controller model). so we're getting behavior where the disk unit number is being
17:04:17 melwitt and guest creation failing with duplicate drive address if more than one bus=scsi devices
17:05:13 melwitt I'm wondering if there's a way to get the scsi controller model without the image meta
17:08:44 melwitt hm, but we are checking if 'unit' is in the disk mapping before incrementing, so you'd think that we're safely not incrementing unless initialized
17:13:12 sean-k-mooney if i remember correctly there used to be a recomendation to use virtio-scsi over virtio block when you volumes were backed by ceph be cause of trim support in virtio scsi that was missing from virtio block
17:15:29 sean-k-mooney so i would not assume its that unlikely to want 6+ scsis but that said perhaps dansmith's comment was in relation to sym5cxx being uncommon not virtio-scsi
17:15:57 dansmith sean-k-mooney: right, the emulation of a real device being the uncommon thing
17:16:07 dansmith it's for unsupported or older guest operating systems at this point
17:16:21 sean-k-mooney like centos 5
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: Modify get_by_cell_and_project() to get_not_deleted_by_cell_and_project() https://review.openstack.org/607663
18:38:06 openstackgerrit Dan Smith proposed openstack/nova master: Make CellDatabases fixture reentrant https://review.openstack.org/611665
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: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: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: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: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

Earlier   Later