| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-18 | |||
| 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 | |
| 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 | |