| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-08 | |||
| 17:29:09 | sean-k-mooney | but image is required | |
| 17:29:13 | sean-k-mooney | in the api | |
| 17:29:24 | sean-k-mooney | https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action | |
| 17:29:40 | sean-k-mooney | stephenfin: so in osc image should be required | |
| 17:29:59 | sean-k-mooney | unless this was implemted in osc /nova client | |
| 17:30:04 | stephenfin | yeah, it was | |
| 17:30:10 | sean-k-mooney | ah ok | |
| 17:30:13 | stephenfin | if you don't specify it, we use the same image | |
| 17:30:21 | sean-k-mooney | right but that is client side | |
| 17:30:29 | stephenfin | which is why you're used to that behaviour, I guess | |
| 17:30:31 | stephenfin | sean-k-mooney: yup | |
| 17:30:38 | sean-k-mooney | ack | |
| 17:31:38 | stephenfin | whoami-rajat: one point: annoyingly either nova or novaclient returns the empty string if the server is volume-backed, so that 'if server.image is None' needs to be simply 'if not server.image' :( | |
| 17:32:20 | stephenfin | https://paste.opendev.org/show/bcl82mF5NEjC4T1uhbnu/ | |
| 17:32:30 | stephenfin | yeah, it's nova itself. Ugh | |
| 17:32:40 | whoami-rajat | ah ok, will update that part | |
| 17:33:06 | sean-k-mooney | The UUID and links for the image for your server instance. The image object will be an empty string when you boot the server from a volume. | |
| 17:33:10 | sean-k-mooney | its in the api ref | |
| 17:33:27 | stephenfin | Just because it's documented doesn't make it right :-P | |
| 17:33:29 | sean-k-mooney | stephenfin: so its not a bug that just what we chose as the sentinel | |
| 17:33:44 | sean-k-mooney | yes but its part of the api contract | |
| 17:34:06 | stephenfin | oh, I'm not suggesting changing it. Merely complaining | |
| 17:34:30 | sean-k-mooney | :) | |
| 17:35:08 | stephenfin | yup, confirmed that rebuilding a BFV instance with the same image works, but using a different image results in a failure | |
| 17:35:14 | stephenfin | ❯ openstack server rebuild --image cirros-0.5.1-x86_64-disk test-server-bfv | |
| 17:35:14 | stephenfin | Image 781c8aa6-210f-4f55-9964-b9fe5ef07749 is unacceptable: Unable to rebuild with a different image for a volume-backed server. (HTTP 400) (Request-ID: req-945cc80d-129e-448a-bde9-bce5f3a8be88) | |
| 17:35:32 | stephenfin | ❯ openstack server rebuild --image cirros-0.5.2-x86_64-disk test-server-bfv | |
| 17:35:32 | stephenfin | | Field | Value | | |
| 17:35:32 | stephenfin | +-------------------+----------------------------------------------------------+ | |
| 17:35:34 | stephenfin | ... | |
| 17:36:03 | stephenfin | whoami-rajat: I think we're on the same page. I'll review that again in the morning. Late for me now o/ | |
| 17:36:13 | stephenfin | Cheers for the input, sean-k-mooney | |
| 17:36:37 | sean-k-mooney | :) | |
| 17:37:11 | whoami-rajat | thanks stephenfin and sean-k-mooney | |
| #openstack-nova - 2022-09-09 | |||
| 08:55:06 | kashyap | Does anyone recall if use "virtio-blk" or "virtio-scsi" by default for in Wallaby? | |
| 09:09:38 | kashyap | virtio-blk | |
| 09:15:50 | bauzas | sean-k-mooney: fwiw, as you being the release liaison, please see the etherpad I wrote for managing RC1 patches that are on duty https://etherpad.opendev.org/p/nova-zed-rc-potential | |
| 09:35:55 | sean-k-mooney | bauzas: thanks looking | |
| 09:50:10 | kashyap | sean-k-mooney: Hey | |
| 09:50:23 | kashyap | sean-k-mooney: Do you recall what's the limit to no. of disks when using 'virtio-blk'? | |
| 09:50:29 | kashyap | In OpenStack... | |
| 09:50:43 | sean-k-mooney | in openstack we dont have one | |
| 09:50:47 | sean-k-mooney | but in reality | |
| 09:50:51 | sean-k-mooney | each virtio-blk device | |
| 09:50:58 | sean-k-mooney | consumes a pci slot | |
| 09:51:07 | sean-k-mooney | so ~20ish | |
| 09:51:14 | kashyap | Right; some 28 disks, IIRC | |
| 09:51:32 | sean-k-mooney | if you need more you need to use virtio-scsi | |
| 09:52:01 | kashyap | Yep | |
| 09:52:23 | sean-k-mooney | there uses to be a limit of 26 because we ran out of drive letters but we fix that a few cycles ago | |
| 09:52:23 | kashyap | I was more interested in the no. of disks limitation for virtio-blk; and the QEMU blog-post confirms it is 28 (https://www.qemu.org/2021/01/19/virtio-blk-scsi-configuration/) | |
| 09:53:12 | sean-k-mooney | ya so that limit as i said si based on the number of pci slots you can have | |
| 09:54:14 | sean-k-mooney | for pc there are 32pci slots and i think 4 are requird so only 28 freee with q35 you can configre the number of pcie slots | |
| 09:54:24 | sean-k-mooney | so in realyity its plably less then that | |
| 09:55:21 | sean-k-mooney | with q35 we can add pcie extnetion bridge in the pci toplogy but i do not think those virtual pcie bridge give us more prots like a hardware bridge chip would | |
| 09:57:00 | kashyap | Yeap; agreed. Thanks! | |
| 10:44:32 | whoami-rajat | stephenfin, so regarding the parameter --confirm-reimage, my original idea of parameter name was --reimage-boot-volume but sean-k-mooney suggested --confirm-reimage, if he agrees to your suggestions, I'm happy to update it https://review.opendev.org/c/openstack/nova-specs/+/840155/4..5/specs/zed/approved/volume-backed-server-rebuild.rst#b142 | |
| 10:45:11 | stephenfin | whoami-rajat: yup, --reimage-boot-volume works for me. That's better again than what I'd suggested | |
| 10:46:04 | whoami-rajat | sean-k-mooney, ^ we're discussing about https://review.opendev.org/c/openstack/python-openstackclient/+/831014/7/openstackclient/compute/v2/server.py#3095 | |
| 10:56:09 | opendevreview | Merged openstack/nova master: doc: mark the max microversion for zed https://review.opendev.org/c/openstack/nova/+/855707 | |
| 11:19:48 | kashyap | sean-k-mooney: I'm wondering if we should revive this: https://review.opendev.org/c/openstack/nova/+/663614/ (libvirt: Update the default number of PCIe root ports to 32 | |
| 11:19:51 | kashyap | ) | |
| 11:20:13 | sean-k-mooney | i dont think so | |
| 11:20:22 | sean-k-mooney | its configurable and we overried it downstream | |
| 11:20:39 | sean-k-mooney | kashyap: have qemu reduced the memroy overhead | |
| 11:20:50 | kashyap | sean-k-mooney: I know it is. | |
| 11:20:57 | kashyap | sean-k-mooney: The memory overhead is negligible, BTW | |
| 11:21:04 | sean-k-mooney | it was not in the past | |
| 11:21:54 | sean-k-mooney | danpb did a lot of testing and it was a signifcant increase | |
| 11:22:08 | kashyap | sean-k-mooney: I know that whole thing, I also referred to it in the commit message | |
| 11:22:39 | kashyap | See my comment on _why_ the overhead is acceptable in the commit message | |
| 11:23:18 | sean-k-mooney | its more the 16mb | |
| 11:24:00 | kashyap | Sigh, where are you quoting that from? I recall putting up that WIP after extensive discussion with the virt folks | |
| 11:24:21 | sean-k-mooney | On memory usage of using Q35 machine type with different number of root | |
| 11:24:23 | sean-k-mooney | ports: | |
| 11:24:25 | sean-k-mooney | - Q35 with 4 root ports: the "resident RAM" is 2056 MB | |
| 11:24:27 | sean-k-mooney | - Q35 with 32 root ports: the "resident RAM" is 2066 MB | |
| 11:24:29 | sean-k-mooney | The additional overhead of increasing the number of root ports is just | |
| 11:24:31 | sean-k-mooney | about 16 MB. This is acceptable. | |
| 11:24:39 | sean-k-mooney | but the comparisons i remeber were showign more then that | |
| 11:25:45 | kashyap | Well, I quoted DanPB's stats there | |
| 11:26:17 | sean-k-mooney | i guess if you are already using q35 its only 16mb | |
| 11:26:32 | sean-k-mooney | what we were orgianlly concered about was the increase form pc to q35 | |
| 11:26:40 | sean-k-mooney | so if we keep the default as pc | |
| 11:26:57 | sean-k-mooney | then i guess we could but based on your arm triles | |
| 11:27:07 | sean-k-mooney | im not sure we shoudl do it vai the config option | |
| 11:27:21 | sean-k-mooney | or perhaps we shoudl set it to say -1 | |
| 11:27:23 | kashyap | Hmm, our upstream default is still 'pc', right? | |
| 11:27:34 | sean-k-mooney | meaning nova use the most that we know works for the acitrues | |
| 11:27:42 | sean-k-mooney | kashyap: yes it is | |
| 11:27:54 | kashyap | Okay, I need to think a bit more about this; now /me really steps out :) | |
| 11:28:07 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/663614/1/nova/conf/libvirt.py | |
| 11:28:29 | sean-k-mooney | thats the comment that makes me thing we woudl be better allowing -1 to mean nova chooes the larges value that will work for the arch | |
| 11:28:56 | sean-k-mooney | so 32 on x86 and 24 on aarch64 | |
| 11:29:21 | sean-k-mooney | and delegate to libvirt for anythign we dont have a known good value for | |
| 11:29:27 | sean-k-mooney | same as 0 today | |
| 11:30:07 | sean-k-mooney | if we did something like that i can proably be sold on updating the value | |
| 12:01:30 | opendevreview | Christian Rohmann proposed openstack/nova master: db: Drop redundant unique constraint for instances uuid https://review.opendev.org/c/openstack/nova/+/856757 | |
| 12:02:59 | opendevreview | Christian Rohmann proposed openstack/nova master: db: Drop redundant unique constraint for instances uuid https://review.opendev.org/c/openstack/nova/+/856757 | |
| 12:43:49 | kashyap | sean-k-mooney: Yeah, arch-specific setting makes sense | |