| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-18 | |||
| 14:13:37 | mriedem | slow but powerful | |
| 14:13:50 | tssurya | I couldn't.. have been at it for some time, then I got busy with some other stuff downstream | |
| 14:13:54 | mriedem | that was our AS400 build process name when i started at ibm... | |
| 14:13:54 | dansmith | we're racing to double-lock a lock | |
| 14:14:21 | dansmith | so I need to make that safe for recursion somehow | |
| 14:16:38 | tssurya | just to be sure dansmith, you are talking abotu these tests right ? http://logs.openstack.org/58/591658/10/check/nova-tox-functional-py35/ab65888/testr_results.html.gz | |
| 14:17:07 | dansmith | tssurya: yep | |
| 14:17:49 | tssurya | great :) thanks a lot for investigating, I wanted to bring it up at some point, but got busy | |
| 15:02:15 | openstack | Launchpad bug 1798489 in Shade "v4-fixed-ip / v6-fixed-ip no longer supported in shade for new vms" [Undecided,New] | |
| 15:02:15 | mordred | mriedem: I got this bug: https://bugs.launchpad.net/shade/+bug/1798489 which I believe stems from when we switched to making direct rest calls for create_server ... I'm sure it's my fault... | |
| 15:02:37 | melwitt | ||
| 15:02:38 | mordred | mriedem: but I was looking for any mentoin of v4-fixed-ip in the api docs and can't find one | |
| 15:02:58 | mordred | I suppose I don't actually need to only talk to mriedem about that :) | |
| 15:02:59 | cfriesen | mriedem: geez, you weren't kidding about a bunch of comments on vTPM | |
| 15:03:18 | mordred | anybody know off the top of their head if that's like an old option or something? | |
| 15:04:54 | mordred | OH - I see it - it's a novaclient thing | |
| 15:11:49 | frickler | mordred: osc has it, too http://git.openstack.org/cgit/openstack/python-openstackclient/tree/openstackclient/compute/v2/server.py#n531 | |
| 15:12:43 | mordred | frickler: yah - so it does. it's just not actually a nova api thing - they all get sent as fixed_ip in the network dict to nova | |
| 15:17:18 | lennyb | moshele, sean-k-mooney both patches passed https://review.openstack.org/#/c/610916/ and https://review.openstack.org/#/c/611017/ | |
| 15:18:09 | sean-k-mooney | lennyb: thanks :) | |
| 15:24:01 | mriedem | mordred: was away - get it figured out? | |
| 15:24:02 | openstack | Launchpad bug 1792077 in OpenStack Compute (nova) "problem specifying multiple "bus=scsi" block devices on nova boot" [Undecided,New] | |
| 15:24:02 | cfriesen | got an interesting bug related to "bus=scsi" that someone else has confirmed....https://bugs.launchpad.net/nova/+bug/1792077 | |
| 15:24:38 | mordred | mriedem: yah- there is an argument novaclient takes that isn't in the rest api that the switch from novaclient to REST lost support for | |
| 15:24:56 | mriedem | ok | |
| 15:27:33 | cfriesen | mdbooth: you might be interested in this ^ | |
| 15:33:55 | mordred | mriedem, frickler: https://review.openstack.org/#/c/611651/ is the fix, just in case you're interested | |
| 15:34:34 | mordred | frickler: I also pushed up an sdk patch for it so that we can support it from osc when we switch over | |
| 15:45:31 | mriedem | melwitt: need this rocky backport https://review.openstack.org/#/c/611327/ | |
| 15:46:02 | melwitt | on it | |
| 15:47:06 | mriedem | we'll likely need a rocky release next week because we have at least 3 upgrade impacting issues | |
| 15:47:41 | melwitt | yeah, I was thinking we'd do the usual and do stable releases for everything along with s-1 | |
| 15:47:48 | mriedem | also need https://review.openstack.org/#/c/611337/ | |
| 15:47:56 | melwitt | unless there's a branch that doesn't have enough stuff in it | |
| 15:48:27 | melwitt | but in general I think a lot goes into the stable branches even in a short-ish time | |
| 15:56:53 | 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 | |
| 15:56:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Refactor scatter-gather utility to return exception objects https://review.openstack.org/607934 | |
| 15:56:54 | openstackgerrit | Dan Smith proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | |
| 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 | |