| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-11-08 | |||
| 15:26:47 | bauzas | already had 2 hours of meeting already | |
| 15:26:51 | bauzas | okay, so | |
| 15:27:07 | bauzas | https://meet.google.com/mdo-owzo-zka | |
| 15:27:27 | bauzas | people wanting to discuss on https://bugs.launchpad.net/nova/+bug/2041519 are free to come here ^ | |
| 15:28:27 | dvo-plv | FYI, I've updated packed ring spec file https://review.opendev.org/c/openstack/nova-specs/+/895924 | |
| 15:31:50 | dansmith | sean-k-mooney: ? | |
| 15:32:49 | dansmith | ah nevermind, you're busy sorry | |
| 15:37:16 | sean-k-mooney | ya sorry on two calls currently | |
| 15:41:27 | bauzas | sean-k-mooney: nevermind, dansmith found me a solution that should work :) | |
| 15:41:51 | bauzas | I just need to make sure we can verify the resource providers by init_host :) | |
| 17:43:27 | bauzas | dang, since we call check_on_dest before check_on_source in the live migration worflow, I don't have any way to hard guess the mdev type the instance was set against | |
| 20:17:01 | opendevreview | Erik Olof Gunnar Andersson proposed openstack/nova master: Fix coverage issues with eventlet https://review.opendev.org/c/openstack/nova/+/900116 | |
| #openstack-nova - 2023-11-09 | |||
| 15:01:12 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix unit tests broken by olso.utils https://review.opendev.org/c/openstack/nova/+/900532 | |
| 15:05:39 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix unit tests broken by olso.utils https://review.opendev.org/c/openstack/nova/+/900532 | |
| 15:18:03 | opendevreview | Erik Olof Gunnar Andersson proposed openstack/nova master: Fix coverage issues with eventlet https://review.opendev.org/c/openstack/nova/+/900116 | |
| 15:28:54 | eandersson | Now with a more reasonable commit message. | |
| 15:37:14 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix unit tests broken by olso.utils https://review.opendev.org/c/openstack/nova/+/900532 | |
| 15:41:57 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix unit tests broken by olso.utils https://review.opendev.org/c/openstack/nova/+/900532 | |
| 15:43:43 | tkajinam | Hi ! It'd be nice if someone from the core review the above patch to bump oslo.utils to fix sqlalchemy-2.x jobs | |
| 15:48:54 | opendevreview | Takashi Kajinami proposed openstack/nova master: Make sqlalchemy-2x job voting again https://review.opendev.org/c/openstack/nova/+/900538 | |
| 15:49:10 | opendevreview | Takashi Kajinami proposed openstack/nova master: Make sqlalchemy-2x job voting again https://review.opendev.org/c/openstack/nova/+/900538 | |
| 16:38:20 | opendevreview | Samuel Kunkel proposed openstack/nova master: fix: amd-sev handle missing img properties https://review.opendev.org/c/openstack/nova/+/874264 | |
| 19:24:17 | dansmith | melwitt: maybe you can hit this for tkajinam: https://review.opendev.org/c/openstack/nova/+/900532 | |
| #openstack-nova - 2023-11-10 | |||
| 02:30:18 | opendevreview | Nobuhiro MIKI proposed openstack/nova-specs master: Re-propose "Add maxphysaddr support for Libvirt" for 2024.1 Caracal https://review.opendev.org/c/openstack/nova-specs/+/895135 | |
| 02:55:22 | opendevreview | Merged openstack/nova master: Fix unit tests broken by olso.utils https://review.opendev.org/c/openstack/nova/+/900532 | |
| 11:36:08 | dvo-plv | Hello, All | |
| 11:36:38 | dvo-plv | Maybe you will have a chance for review today ? https://review.opendev.org/c/openstack/nova-specs/+/895924 | |
| 15:35:28 | opendevreview | Vasyl Saienko proposed openstack/nova master: libvirt: Make Enligtened VMCS optional https://review.opendev.org/c/openstack/nova/+/900629 | |
| 15:49:36 | opendevreview | Vasyl Saienko proposed openstack/nova master: libvirt: Make Enligtened VMCS optional https://review.opendev.org/c/openstack/nova/+/900629 | |
| 16:27:32 | opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Proposes mdev live-migration support in libvirt https://review.opendev.org/c/openstack/nova-specs/+/900636 | |
| 16:42:18 | opendevreview | Takashi Natsume proposed openstack/nova master: Update contributor guide for 2024.1 Caracal https://review.opendev.org/c/openstack/nova/+/896305 | |
| 17:45:58 | opendevreview | sean mooney proposed openstack/nova master: remove eventlet.tpool from rbd_utils https://review.opendev.org/c/openstack/nova/+/900682 | |
| 17:45:58 | opendevreview | sean mooney proposed openstack/nova master: removew use of eventlet.queue.LightQueue https://review.opendev.org/c/openstack/nova/+/900681 | |
| 19:26:40 | opendevreview | Merged openstack/nova master: doc: clarify that pre-commit is optional https://review.opendev.org/c/openstack/nova/+/897057 | |
| 19:59:41 | opendevreview | Vasyl Saienko proposed openstack/nova master: libvirt: Make Enligtened VMCS optional https://review.opendev.org/c/openstack/nova/+/900629 | |
| 20:12:32 | opendevreview | Erik Olof Gunnar Andersson proposed openstack/nova master: Fix coverage issues with eventlet https://review.opendev.org/c/openstack/nova/+/900116 | |
| 20:15:32 | mgariepy | is there issue with placement allocation ? depsite having a Memory_MB allocation_ratio of 1.0 i got used:737280 out of a total of 515555 | |
| 20:35:39 | mgariepy | pretty much the same issue as : https://bugzilla.redhat.com/show_bug.cgi?id=1846844 | |
| #openstack-nova - 2023-11-12 | |||
| 09:28:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM: test hostname based migration URL https://review.opendev.org/c/openstack/nova/+/900275 | |
| 09:28:16 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Add migration_inbound_addr https://review.opendev.org/c/openstack/nova/+/900203 | |
| #openstack-nova - 2023-11-13 | |||
| 10:35:48 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix KeyError on assisted snapshot call https://review.opendev.org/c/openstack/nova/+/900783 | |
| 11:46:38 | opendevreview | Danylo Vodopianov proposed openstack/nova master: Packed virtqueue support was added. https://review.opendev.org/c/openstack/nova/+/876075 | |
| 12:01:11 | jkulik | Hi folks, we just stumbled over https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/5ASRKETLJQAZM2KJ2EDIJZB6XMDWAL4P/ which has removing vmware from Nova and other projects as the topic. We're still actively using VMware inside SAP through OpenStack. Is there any way we can reverse the decision to completely remove the vmwareapi infrastructure from Nova? | |
| 12:12:32 | stephenfin | jkulik: I would suggest bringing this up on the Nova weekly meeting and likely openstack-discuss. The details and link to the agenda for the former can be found here https://meetings.opendev.org/#Nova_Team_Meeting | |
| 12:15:23 | stephenfin | jkulik: the tl;dr: is that we have had no CI for any of this code for many years now, which means we have no ability to test it and ensure that it works/isn't broken by other changes | |
| 12:17:41 | opendevreview | Samuel Kunkel proposed openstack/nova master: fix: amd-sev handle missing img properties https://review.opendev.org/c/openstack/nova/+/874264 | |
| 12:17:57 | stephenfin | jkulik: I would also suggest you need to bring this up internally rather quickly. I can't speak for anyone else but _my guess_ would be that the only way this decision would be reversed would be via a long-term commitment from some third party to maintain testing infrastructure for these components (the VMWare-related drivers in Nova, Cinder, Neutron etc.; oslo-vmware, ...) | |
| 12:20:10 | stephenfin | jkulik: We previously got such a commitment from VMWare folks (about 2-3 years ago, iirc) but it wasn't followed up on, so there will likely be some hesitation at taking any commitment at face value without seeing e.g. a CI being established | |
| 12:20:28 | stephenfin | Hopefully that helps provide a bit of colour to the situation | |
| 12:23:19 | jkulik | thank you. indeed I remember the deprecation attempt 2-3 years ago when we got VMware to bring back some CI. we were not aware that it's broken again. | |
| 12:34:27 | sean-k-mooney | jkulik: the ci hase been absent for 2+ years | |
| 12:39:19 | jkulik | iirc this was the time when we talked to VMware and they brougt back a CI https://review.opendev.org/c/openstack/nova/+/712101 - 2020-03 ... so there should have been some CI ~3 years ago again. https://review.opendev.org/c/openstack/nova/+/806391 in 2021-09 still contains a message from a "VMware NSX CI". I'm just wondering when it went away. | |
| 12:47:47 | sean-k-mooney | jkulik: presumably related to the pandmeic that ci went way again in 2021 and never returned | |
| 12:47:52 | jkulik | 2022-02 I found a message `ext-nova-zuul: NOT_REGISTERED` for that CI. sounds like a good hint when it went away. in 2021 it still seemed to work. Even in 2022-01-27 there's still a message for a Cinder review-request | |
| 12:48:51 | jkulik | yeah, VMware doesn't have too much going for OpenStack. is there a way for a third-party, non-VMware user to get notified if the CI goes away? | |
| 12:49:27 | sean-k-mooney | there isnt, and evenupstream developer will only know if they noticed its not reporting | |
| 12:49:44 | sean-k-mooney | jkulik: they did not tell us they were nolonger maintianing it or removing it | |
| 12:49:51 | sean-k-mooney | it jus t disappeared silently | |
| 12:50:03 | sean-k-mooney | again | |
| 12:50:18 | jkulik | they did not tell us either ... that's why I would have liked to get notified somehow to tell them to fix it | |
| 12:50:42 | sean-k-mooney | at this point i thik its beyond that | |
| 12:51:05 | sean-k-mooney | they have demonstarted that they will not maintain the ci or lib requried to supprot vmware | |
| 12:51:40 | jkulik | Could someone else step up? | |
| 12:51:47 | jkulik | Would that be acceptable, I mean? | |
| 12:51:52 | sean-k-mooney | honestly i dont think so | |
| 12:52:46 | jkulik | so we would be left with trying to maintain an out-of-tree driver, which is not supported, and keeping all the to-be-removed code in sync with upstream in our downstream fork ... :/ | |
| 12:52:48 | sean-k-mooney | at this point i think we woudl neeed to see more then a token effort | |
| 12:53:01 | sean-k-mooney | jkulik: out of tree dirvers wont work | |
| 12:53:08 | jkulik | yeah, I read that | |
| 12:53:35 | stephenfin | sean-k-mooney: I don't see any reason why another third party couldn't maintain it. As you say though, it'd have to be more than a token effort | |
| 12:53:40 | sean-k-mooney | the core of vmware is opensouce right (EXSI( | |
| 12:54:05 | sean-k-mooney | stephenfin: someone else could | |
| 12:54:25 | jkulik | no, ESXi is not open source. not sure if that was sarcasm | |
| 12:54:42 | sean-k-mooney | i tought ther ewas an opensouce core | |
| 12:54:45 | sean-k-mooney | exi is not | |
| 12:54:53 | sean-k-mooney | but isnt esxi based on linux | |
| 12:55:02 | jkulik | I haven't heard of any. The things we use are not open source. | |
| 12:55:24 | jkulik | what would "more than a token effort" entail? | |
| 12:56:20 | sean-k-mooney | actully continutigi to the maintaicne of vmaware as well as first/tridpary ci | |
| 12:56:48 | sean-k-mooney | jkulik: i might of been thinking fo the fact there is a free version of esxi | |
| 12:57:07 | sean-k-mooney | its not opensouce but there are free lisnces | |
| 12:57:19 | stephenfin | At a minimum, CI coverage. Practically speaking though, there's mountains of tech debt in the VMWare driver that needs addressing if we're keeping it around long-term | |
| 12:57:30 | sean-k-mooney | basically i was considing if instead of third party ci we coudl do this first party somehow | |
| 12:58:37 | sean-k-mooney | right there is a lot of techdebt( lack of functional tests, old apis/deps) and large feature gaps | |
| 12:59:05 | jkulik | sounds like it boils down to us (SAP) working more with upstream, cleaning the driver and by that recognizing CI going missing, if we want that driver to stay | |
| 12:59:09 | stephenfin | that cost compares to maintaining an out-of-tree driver would be interesting to study | |
| 12:59:09 | stephenfin | jkulik: Really it would be a near-full-time job. The obvious answer here is that SAP put forward someone to maintain CI and work to get your downstream fork synced back upstream (or at least work to get equivalent functionality added upstream) but I don't know how SAP are for upstream development. It's definitely something that has to developed and nurtured be in the org/company culture. There's also a cost to it, though how | |
| 12:59:17 | stephenfin | jkulik: exactly | |
| 13:02:56 | jkulik | we're open to upstreaming, but given that we need the features downstream first, they often don't end up upstream due to time constraints and us not actively including ourselves in the upstream community. I feel that pain every time when we port our patches to a newer release. I'll bring that topic up internally with management. | |
| 13:03:00 | jkulik | thank you both | |
| 13:05:40 | stephenfin | jkulik: np. I'll also add that we're generally very open to adding additional cores, particularly when those cores are focused on a particular area and have competency there, but obviously that competency needs to be demonstrated for some time first | |
| 13:06:00 | jkulik | :+1: | |
| 13:06:30 | sean-k-mooney | well keep in mind the job of a core is primarly to review code not write it | |
| 13:07:30 | sean-k-mooney | so while stephenfin is correct we would be open to adding cores the copendncy we woudl use to make that determination is there review output not there code output | |
| 13:08:07 | jkulik | review output in Nova in general, I guess, not only the vmwareapi driver then? As I guess, that one doesn't see too many patches. | |
| 13:09:17 | sean-k-mooney | sortof both. in general in the past we have expect a general knowladge of the entire codebase but most core have areas or specialisation where they spend most of there time | |
| 13:10:16 | stephenfin | That would be an interesting discussion to have as a community. As you say, that area doesn't see too many patches and there is very little expertise in that area among existing cores. Ensuring we had decent review throughput would be an interesting thing to figure out | |
| 13:10:45 | sean-k-mooney | well part of the expction would be that they would enforece the same feature design crita as we do for the rest of nova | |
| 13:11:06 | sean-k-mooney | in the past vmware have added funcitonlity in the out of tree drive and then tried to upstream it | |
| 13:11:34 | sean-k-mooney | or made changes that normaly woudl requrie spec or blueprints that got little or no discussion | |