Hello community, we would greatly appreciate if VMware support in OpenStack remained at least at the same level as it is today. We have several large customers who still use OpenStack with VMware vSphere. We are currently in the process of testing an upgrade from Antelope to Caracal and vSphere from 7 to 8. Kind regards. — Andrej Moravčík ICT & Cloud consultant www.aliter.com On 31 Jan 2025, at 12:42, Takashi Kajinami <kajinamit@oss.nttdata.com> wrote: One correction On 1/31/25 8:38 PM, Takashi Kajinami wrote: Note that oslo.vmware is used by not only nova but by a few other projects (cinder, os-brick, glance, ceilometer and monasca-agent). The list can be easily found by quick search, for example using codesearch[1]. [1] https://codesearch.opendev.org/?q=oslo_vmware&i=nope&literal=nope&files=&excludeFiles=&repos= So the discussion is not really specific to nova but needs to involve a few other parties. As far as I know some of these can be removed, - The vmware inspector in ceilometer was deprecated a few cycles ago after no interest to use the feature in the previous thread to discuss vmware support VMWare support by ceilometer was already removed during this cycle by https://review.opendev.org/c/openstack/ceilometer/+/936109 so we can ignore ceilometer in this duscussion. - The vmware image store in glance was deprecated, mainly because using cinder backend(which is again backed by vmware) can be a viable alternative. but at least cinder has no plan to remove the vmware driver so may still need it. On 1/31/25 6:18 PM, Herve Beraud wrote: Thanks Melanie and Sean for your feedback. Indeed, if Nova owns a vmware driver, the oslo.vmware library has to remain in place until Nova decides to retire its driver. Maybe it would be good to add this topic into the next PTG topics for Nova, but as Sean proposed, let's re-discuss at least this topic again during the next series. Le jeu. 30 janv. 2025 à 18:53, melanie witt <melwittt@gmail.com <mailto:melwittt@gmail.com>> a écrit : On 1/30/25 08:09, Sean Mooney wrote: > > On 30/01/2025 10:07, Herve Beraud wrote: >> Hey folks, >> >> I observed that oslo.vmware has not received any significant >> modifications since almost 4 years ago [1]. >> The only changes proposed to oslo.vmware since a while are just >> related to infra changes (python versions, tox versions, etc...). >> >> Due to the recent news about vmware [2], I wonder if oslo.vmware is >> still a relevant library in our context and I wonder if it is worth >> spending time on maintaining it. > > we still have the vmware driver in nova and oslo.vmware is an optional > dependency for that > > https://github.com/openstack/nova/blob/master/setup.cfg#L36 <https://github.com/openstack/nova/blob/master/setup.cfg#L36> > > SAP expressed interest in maintaining the vmware integration 2? cycles > ago maybe 3 and > > have been running a third party ci and trying to fix issues in nova/ > neutron as they arise > > so we cant deprecate or retire it until we do the same for the code that > uses it. > > we have tried to avoid the term deprecated with the vmware driver in nova. > > we consider it "experimental" perhaps is a better term. > > its in a similar state to linux bridge in neutron. > > it "should" mostly work but its still not properly maintained/tested to > a point where > i would recommend new usage of it. for existing deployments however we > have not proposed removing it > in 2025.1 > > we may want to discuss that again but i would not expect it to be > removed in the next cycle or two. It is timely this comes up because literally yesterday I ran into the situation where I had to manually install oslo.vmware into my unit test tox venv in order to run unrelated unit tests. (I was having problems with dependency installs for an older branch and ended up installing requirements.txt and test-requirements.txt content manually): [...] Failed to import test module: nova.tests.unit.virt.vmwareapi.test_images Traceback (most recent call last): File "/usr/lib64/python3.6/unittest/loader.py", line 428, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib64/python3.6/unittest/loader.py", line 369, in _get_module_from_name __import__(name) File "/home/fedora/openstack-nova/nova/tests/unit/virt/vmwareapi/test_images.py", line 24, in <module> from oslo_vmware import rw_handles ModuleNotFoundError: No module named 'oslo_vmware' Failed to import test module: nova.tests.unit.virt.vmwareapi.test_network_util Traceback (most recent call last): File "/usr/lib64/python3.6/unittest/loader.py", line 428, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib64/python3.6/unittest/loader.py", line 369, in _get_module_from_name __import__(name) File "/home/fedora/openstack-nova/nova/tests/unit/virt/vmwareapi/test_network_util.py", line 20, in <module> from oslo_vmware import vim_util ModuleNotFoundError: No module named 'oslo_vmware' [...] So yeah, at best it might be a possibility that we move the oslo.vmware requirement from global-requirements.txt to Nova requirements.txt or test-requirements.txt if it's not used more widely. But the library itself has to stay as long as the VMware driver does. -melwitt -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ <https://github.com/4383/> ________________________________ Táto správa a jej prílohy sú dôverné. Prosím, narábajte s týmito informáciami ako s dôvernými a nezverejňujte, nekopírujte ani neposielajte tieto informácie bez predchádzajúceho súhlasu spoločnosti Aliter Technologies, a.s. Ak nie ste adresátom indikovaným v záhlaví tejto správy alebo želaný príjemca, upovedomte prosím spoločnosť Aliter Technologies, a.s. odpoveďou na tento e-mail a pôvodnú správu vymažte zo svojho systému. Aliter Technologies - registrovaná ochranná známka pre EU, USA This message and any attachments are confidential. Please treat the information as confidential, and do not disclose, copy or deliver this message to anyone without Aliter Technologies' approval. If you are not the addressee indicated in this message or an intended recipient please notify Aliter Technologies a.s. by return e-mail and delete the message from your system. Aliter Technologies - Registered in WIPO & U.S. Patent and Trademark Office