| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-08 | |||
| 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 | |
| 12:47:04 | Uggla | question, I have this signature: def _hard_reboot(self, context, instance, network_info, block_device_info=None, accel_info=None, share_info=None): I would like share_info to be an ShareMappingList object either empty or with items (not None). Shoud I change to share_info=ShareMappingList(), an empty list by default. I noticed the file is also under mypy so I could define a type. What is your preference ? | |
| 12:49:24 | sean-k-mooney | Uggla: no never | |
| 12:49:33 | opendevreview | Christian Rohmann proposed openstack/nova master: db: Drop redundant indeces on instances and console_auth_tokens tables https://review.opendev.org/c/openstack/nova/+/856757 | |
| 12:49:55 | sean-k-mooney | Uggla: you shoudl never us a collection as the default for a keyward arg | |
| 12:50:34 | sean-k-mooney | Uggla: the way python works is that the vlaue of the keyword args are initalised once one the fucntion is first parsed and then rused across all function calls | |
| 12:50:54 | sean-k-mooney | so fi you default to a list or object that object will be shared across all fucntion calls | |
| 12:51:23 | sean-k-mooney | so kwargs shoudl only be litral values like Ture 42 None | |
| 12:51:30 | opendevreview | Christian Rohmann proposed openstack/nova master: db: Drop redundant indexes on instances and console_auth_tokens tables https://review.opendev.org/c/openstack/nova/+/856757 | |
| 12:51:32 | sean-k-mooney | "a sting litral" | |
| 12:51:49 | sean-k-mooney | so share_info=ShareMappingList() is not correct to use | |
| 12:52:51 | Uggla | ok, but what is the good way to be sure share_info will have the proper type and safely call its methods ? | |
| 12:53:08 | sean-k-mooney | we can add the type annotations | |
| 12:53:23 | sean-k-mooney | but its if you want ti to be a requried arge then it should not be a kwarg | |
| 12:53:30 | sean-k-mooney | if its optional you should do | |
| 12:53:48 | sean-k-mooney | if share_info is None: | |
| 12:53:53 | sean-k-mooney | share_info=ShareMappingList() | |
| 12:54:08 | sean-k-mooney | in the hard reboot funtion if you need too | |
| 12:55:05 | sean-k-mooney | in most cases we woudl expect this to be None as most vms wont have shares | |