| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-07-04 | |||
| 20:43:53 | mnaser | ^ five minuter doc fix | |
| 21:29:27 | opendevreview | Arnaud Morin proposed openstack/nova master: Correctly reset instance task state in rebooting hard https://review.opendev.org/c/openstack/nova/+/867832 | |
| #openstack-nova - 2023-07-05 | |||
| 09:44:48 | opendevreview | Nobuhiro MIKI proposed openstack/nova-specs master: Fix build failures caused by changes in Pillow v10.0.0 https://review.opendev.org/c/openstack/nova-specs/+/887661 | |
| 10:28:12 | opendevreview | Amit Uniyal proposed openstack/nova master: Reproducer for dangling bdms https://review.opendev.org/c/openstack/nova/+/881457 | |
| 10:28:12 | opendevreview | Amit Uniyal proposed openstack/nova master: Refactor CinderFixture https://review.opendev.org/c/openstack/nova/+/885756 | |
| 10:28:13 | opendevreview | Amit Uniyal proposed openstack/nova master: Delete dangling bdms https://review.opendev.org/c/openstack/nova/+/882284 | |
| 10:30:03 | zigo | Moving forward, we have lots of VMs with the xsaves feature. Is there a way to trick libvirt to make VMs live-migrate to a host that doesn't have the flag? | |
| 10:30:03 | zigo | Hi there! Considering what happened with the xsaves flag being removed from hosts with the latest kernels, I backported https://review.opendev.org/c/openstack/nova/+/774240 to Victoria in my Debian packaging, so we can remove xsaves from compute nodes where the flag is still there, and have always the same feature set in our deployment. | |
| 10:31:08 | zigo | This is an enormous headache ... | |
| 10:41:05 | opendevreview | Amit Uniyal proposed openstack/nova master: Reproducer for dangling bdms https://review.opendev.org/c/openstack/nova/+/881457 | |
| 10:41:05 | opendevreview | Amit Uniyal proposed openstack/nova master: Refactor CinderFixture https://review.opendev.org/c/openstack/nova/+/885756 | |
| 10:41:06 | opendevreview | Amit Uniyal proposed openstack/nova master: Delete dangling bdms https://review.opendev.org/c/openstack/nova/+/882284 | |
| 12:21:10 | opendevreview | Merged openstack/nova stable/victoria: Remove mentions of removed scheduler filters https://review.opendev.org/c/openstack/nova/+/858051 | |
| 13:00:22 | opendevreview | Merged openstack/nova master: enable validations in nova-lvm https://review.opendev.org/c/openstack/nova/+/887632 | |
| 13:12:25 | elodilles | oh, cool, this has merged ^^^ \o/ | |
| 13:13:08 | elodilles | sean-k-mooney: do you want to backport it to stable/2023.1? | |
| 13:15:56 | sean-k-mooney | sure i can do it now | |
| 13:16:04 | sean-k-mooney | we need it on all non EM branchs | |
| 13:16:10 | sean-k-mooney | where tempest is using master | |
| 13:16:32 | opendevreview | sean mooney proposed openstack/nova stable/2023.1: enable validations in nova-lvm https://review.opendev.org/c/openstack/nova/+/887674 | |
| 13:33:03 | elodilles | sean-k-mooney: ack, thanks! | |
| 13:35:32 | elodilles | i also backported the devstack patch to stable/2023.1 that fixes the similar problem with nova-ceph-multistore job, but it is somehow not enough (this is the patch: https://review.opendev.org/c/openstack/devstack/+/887660 ) | |
| 13:57:40 | bauzas | stephenfin: other sphinx SMEs, it looks like we have a CI failure on nova specs, fortunately we have a fix https://review.opendev.org/c/openstack/nova-specs/+/887661 | |
| 13:58:21 | stephenfin | I wonder if we should just drop blockdiag? | |
| 14:01:22 | bauzas | stephenfin: IMHO we use it for some specs | |
| 14:01:47 | stephenfin | right, but we can just generate the SVGs once and store them | |
| 14:02:27 | stephenfin | or PNGs or whatever they are | |
| 14:03:57 | bauzas | stephenfin: the problem is that we have the spec freeze tomorrow | |
| 14:04:07 | bauzas | stephenfin: so, for the moment our gate is blocked | |
| 14:04:14 | sean-k-mooney | i woudl be fien with droping it | |
| 14:04:35 | sean-k-mooney | and just having it ascii or svg | |
| 14:05:22 | bauzas | ditto, but for this week, I'd prefer to first fix our CI | |
| 14:07:39 | sean-k-mooney | yep | |
| 14:08:08 | sean-k-mooney | fix ci but going forward just using ascii or an svg woudl be fine | |
| 14:12:37 | bauzas | yup, fair enough, I'm okay provided we keep the sources | |
| 14:14:19 | bauzas | sean-k-mooney: stephenfin: provided a comment on https://review.opendev.org/c/openstack/nova-specs/+/887661 | |
| 14:14:36 | bauzas | can either of you just approve this patch and we could revert it next week ? | |
| 14:24:48 | opendevreview | Stephen Finucane proposed openstack/nova-specs master: Remove sphinxcontrib.seqdiag https://review.opendev.org/c/openstack/nova-specs/+/887702 | |
| 14:24:56 | stephenfin | bauzas: there you go | |
| 14:25:11 | stephenfin | builds fine locally | |
| 14:34:02 | bauzas | sean-k-mooney: your vote may be appreciated on https://review.opendev.org/c/openstack/nova-specs/+/887702 | |
| 15:28:34 | bauzas | gibi: sean-k-mooney: can either of you can vote for https://review.opendev.org/c/openstack/nova-specs/+/887702 in order to unblock our specs repo ? | |
| 15:37:24 | sean-k-mooney | sure ill do it now | |
| 15:43:04 | sean-k-mooney | stephenfin: the content looks correct so far. there is a tiny regession in fucntionaltiy with how it interact with a client side browser extention | |
| 15:43:16 | sean-k-mooney | but i think i cna overlook that | |
| 15:45:30 | sean-k-mooney | basically i use "dark reader" to view everythingin darkmode even when the site does not have a dark mode. | |
| 15:45:59 | sean-k-mooney | with the existing docs site the svg get inverted properlfy with the new content on the docs preview site they are not inverted | |
| 15:47:42 | sean-k-mooney | i think this is because we changed from using <svg> to the <image> | |
| 15:49:12 | sean-k-mooney | so even though we are displayign an svg its content is not aviable to the bowser as an svg so it being rendered differently | |
| 15:50:24 | sean-k-mooney | as a result darkreader cannot modify the styling | |
| 15:50:58 | sean-k-mooney | i approved it for now but if there was a way to embded the svg as an svg that would be nice | |
| 15:52:13 | sean-k-mooney | https://github.com/sphinx-doc/sphinx/issues/2240 apprently its an open issue ssicne 2016 | |
| 15:56:26 | opendevreview | Merged openstack/nova-specs master: Remove sphinxcontrib.seqdiag https://review.opendev.org/c/openstack/nova-specs/+/887702 | |
| 16:47:35 | dvo-plv | sean-k-mooney, I have rerun zuul after your fix, all pass. You can review if you have a chance: bp https://review.opendev.org/c/openstack/nova/+/876075/16 | |
| 16:49:17 | sean-k-mooney | dvo-plv: not today as im debugging somethign but ill try and take a look tomorrow | |
| 16:50:03 | sean-k-mooney | quick glance https://review.opendev.org/c/openstack/nova/+/876075/16/nova/tests/functional/test_servers.py looks good | |
| 18:04:29 | mgariepy | can this be pushed a bit ? https://review.opendev.org/c/openstack/nova/+/882914 | |
| 21:05:03 | mgariepy | thanks sean-k-mooney | |
| #openstack-nova - 2023-07-06 | |||
| 01:42:10 | opendevreview | Merged openstack/nova-specs master: Re-propose "Add maxphysaddr support for Libvirt" for 2023.2 Bobcat https://review.opendev.org/c/openstack/nova-specs/+/878753 | |
| 08:28:24 | opendevreview | Vitalii Vrublevskyi proposed openstack/nova master: Napatech SmartNIC support https://review.opendev.org/c/openstack/nova/+/859577 | |
| 08:28:37 | opendevreview | Vitalii Vrublevskyi proposed openstack/os-vif master: Openvswitch driver was extended https://review.opendev.org/c/openstack/os-vif/+/859574 | |
| 08:38:06 | bauzas | as a reminder, today is the last day for approving specs | |
| 09:25:35 | elodilles | bauzas sean-k-mooney auniyal : a bit of a distraction from the specs reviews: i have a quick question in the os-vif release patch: https://review.opendev.org/c/openstack/releases/+/887486/1#message-9bb674cb5826ef01bbf20c442ad18a7ae8e08bbd | |
| 10:11:27 | sean-k-mooney | we do not really need a m2 release of os-vif. although it does not hurt let me take a look at the coment quickly | |
| 10:11:49 | sean-k-mooney | ah the set default change | |
| 10:13:09 | sean-k-mooney | elodilles: os-vif is release with intermediaries so we can do as many releases as we want as long as we have at least one per release | |
| 10:13:39 | sean-k-mooney | that also means we dont have to align them to milestones so if we want to wait for https://review.opendev.org/c/openstack/os-vif/+/885127 we can | |
| 10:17:26 | sean-k-mooney | elodilles: also just replied to https://review.opendev.org/c/openstack/os-vif/+/883015/1#message-fb3bacb0ce69979a469c69a136bc4dcfd89ae915 | |
| 10:22:32 | sean-k-mooney | elodilles: also just commented on your specific question https://review.opendev.org/c/openstack/releases/+/887486/1#message-a1446c91db95121f23e1304625fb5a728b4c0b71 on the release patch | |
| 10:22:43 | sean-k-mooney | happy to chat about this more when your around | |
| 10:27:08 | sean-k-mooney | elodilles: for more context the only reason i called out the change in the upgrade section was because it does not take effect on existing running instance immideatly | |
| 10:27:35 | sean-k-mooney | so simply updating os-vif is not enough the vms need tobe moved ro rebooted to have ovs port recreated | |
| 10:27:56 | sean-k-mooney | so i didnt want operators to think cool i patch it so my performance will imporve | |
| 10:28:21 | sean-k-mooney | it will for new instances or old ones once recreated via a hard reboot or move op | |
| 10:29:32 | sean-k-mooney | i could have just called that out in the fixes section but my thinking was when you are upgrading you would wnat to know that you shoudl live migratie the instace or comunicate to your custoemres that a reboot will improve the perfermance if they are expirince low network througput | |
| 10:46:32 | elodilles | sean-k-mooney: it's not a problem you added it in the upgrade section, it attracts more attention :) | |
| 10:46:42 | elodilles | and thanks for the explanation | |
| 10:46:56 | elodilles | i've +2'd the patch | |
| 10:46:57 | sean-k-mooney | hehe thats the point of release notes | |
| 10:47:09 | elodilles | yepp :) | |
| 10:47:34 | sean-k-mooney | in terms fo the backprot woudl you prefer to remove the default for the config option | |
| 10:48:04 | sean-k-mooney | we woudl have to slightly modify the test to set it and add a new test to assert its not set by default | |
| 10:48:18 | sean-k-mooney | but i think that would be pretty simple | |
| 10:48:25 | elodilles | well, it's not about my preference, really :) the thing is that a change should not change default behaviour when an operator upgrades to a new release | |
| 10:49:07 | elodilles | especially if it's a change that could cause issues for operators | |
| 10:49:30 | sean-k-mooney | ya the tricky part here is because a bug in ovs we did not see that theree was actully a change in behavior when we swapped form libvirt plugging to os-vif pluging the interface | |
| 10:49:51 | sean-k-mooney | well it cant as far as i am aware | |
| 10:50:20 | sean-k-mooney | the patch only sets teh linux-noop qos policy on the port if the port does not exist on teh bridge | |
| 10:50:56 | sean-k-mooney | so this woudl only cause an issue if that was not supported by your ovs version | |
| 10:51:17 | elodilles | and we don't always realize what can cause issues ;) so to be on the safe side, should chose opt-in config ;) | |
| 10:51:18 | sean-k-mooney | to my knoldage this has been supproted for many many years in ovs | |
| 10:51:33 | elodilles | (on stable branches) | |
| 10:51:38 | sean-k-mooney | yep | |
| 10:51:50 | sean-k-mooney | that is why i normally do this as two patches on master | |
| 10:52:01 | sean-k-mooney | but i forgot this time since we had some heat to fix this downstream | |
| 10:52:51 | sean-k-mooney | as i said im find with making it opt in in the backport if thats what other think we should do | |
| 10:52:54 | elodilles | i see. yepp, it's better when it is separated into 2 patches | |
| 10:54:05 | sean-k-mooney | there is no opt out in the master version because when libvirt was doing this it alwasy set the noop qdisc on the port | |
| 10:54:06 | elodilles | sean-k-mooney: i mean, generally it is the best way of working to follow. of course if a team decides that this is fine like this, i'm not against then. | |
| 10:55:09 | sean-k-mooney | of couse that was not documented anywhere which is why we missed it orgianlly | |