December 2021 - openstack-discuss

[cinder] festival of XS reviews 17 December 2021
by Brian Rosmaita 16 Dec '21

16 Dec '21

Hello Argonauts [0], Apologies for the lateness of this reminder, but hopefully everyone has already used the handy ICS file [1] to have this event on their personal calendars. The most recent edition of the Cinder Festival of XS Reviews will be held tomorrow (Friday 17 December). who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 17 December 2021 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! brian [0] At the Yoga PTG, the Cinder mascot was named "Argo" and the Cinder project team thereby became the "Argonauts". [1] http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics

1 0

[cyborg][nova][qa]Question about Accelerator unbinding
by Di XiaoLi 16 Dec '21

16 Dec '21

hi, Cyborg and nova team: I am using cyborg with "Wallaby" release to manage my accelerator devices, while I'm trying to unbind the accelerator I found that the device was not actually unbound from the virtual machine. Here are my questions: 1. What is the function of the arq unbind command in cyborg ? 2. How to unbind the accelerator which bounded to vm? Does nova or cyborg support this function now？ Here are my steps: step1: openstack accelerator arq unbind ed205084-f58d-4fad-99b4-327a1398858f +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | uuid | ed205084-f58d-4fad-99b4-327a1398858f | | state | Unbound | | device_profile_name | ssd | | hostname | None | | device_rp_uuid | None | | instance_uuid | None | | attach_handle_type | | | attach_handle_info | {} | +---------------------+--------------------------------------+ step2: login vm and check the device, but it still here. step3: stop vm and start vm, met the following error: "nova.exception.AcceleratorRequestOpFailed: Failed to get accelerator requests: Cyborg returned no accelerator requests for instance ca77ef4e-421c-4c6c-9d76-7618a90ec921"

4 9

[all][tc] Technical Committee next weekly meeting on Dec 16th at 1500 UTC
by Ghanshyam Mann 15 Dec '21

15 Dec '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for Dec 16th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Dec 15th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[stable][requirements][zuul] unpinned setuptools dependency on stable
by Balazs Gibizer 15 Dec '21

15 Dec '21

Hi, The latest setuptools (58.0) removed support for "use_2to3" [1] (deprecated since 46.2). Many OpenStack modules defines decorator==3.4.0 as lower constraints[2]. However, decorator 3.4.0 cannot be installed anymore with the latest setuptool as it depends on "use_2to3". On master, this can be solved easily by bumping the dependency to decorator 4.0.0. On stable/xena we can still solve it the same way with a new RC. But on older stable branches such solution might be against the stable policy as it would require a major bump on our dependencies. This issue is not limited to lower-constraints testing it just hit us there first. A similar break could happen in our upper constraints as well on old stable branches. The root of the problem is that we always use the latest setuptools in our CI testing even on old stable branches. Zuul's ensure-tox task[4] installs tox which installs the virtualenv package which bundles the latest setuptools package. This happens without applying any constraints. Then tox is used to install the project's dependencies under lower or upper constraints with the unconstrained setuptools available. During and after yesterday's nova meeting [3] we discussed possible solutions. Option 1: Bump the major version of the decorator dependency on stable. Pros: * easy to implement Cons: * might against the policy / breaks downstream packagers * needs to be done in each affected project[3] separately * not future proof. After a future setuptools release we can see a similar break with another of our dependencies. @Stable Cores: how do you feel about such bump? Option 2: Pin the setuptools version during tox installation Pros: * single solution for all affected projects * future proof against breaks introduced by future setuptools releases Cons: * complex change as it probably requires to extend the base task in zuul itself Option 3: turn off lower-constraints testing Pros: * easy to implement * some of us want to get rid of lower constraints anyhow Cons: * needs per project changes * not future proof against similar break affecting our upper constraints on old stable branches. Option 4: utilize pyproject.toml[6] to specify build-time requirements Unfortunately, I'm not sure if it is possible to restrict the maximum setuptools version with it As a side note I tried applying [tox]requires in tox.ini to restrict setuptools version[7] but It does not seem to take effect in our case[8]. @Stable Cores: what do you think what could be the way forward? Cheers, gibi [1] https://setuptools.pypa.io/en/latest/history.html#v58-0-2 [2] https://codesearch.openstack.org/?q=decorator%3D%3D3.4.0&i=nope&literal=nop… [3] https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.20… [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks… [5] https://tox.readthedocs.io/en/latest/config.html#conf-requires [6] https://www.python.org/dev/peps/pep-0518/ [7] https://review.opendev.org/c/openstack/placement/+/810293/1/tox.ini [8] https://zuul.opendev.org/t/openstack/build/f78a0300c8734e7c8475309af1d2e1a4…

11 28

Re: [gate][tripleo] gate blocker
by Ananya Banerjee 15 Dec '21

15 Dec '21

Hi, We have a tripleo gate blocker. Patches 816991,16 and 821778 which fixes bugs needs to go first to unblock the rest. Can someone please get these two patches to the top of the queue? https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/821699/ https://review.opendev.org/c/openstack/tripleo-ci/+/821778/ Thanks, Ananya -- Ananya Banerjee, RHCSA, RHCE-OSP Software Engineer Red Hat EMEA <https://www.redhat.com/> anbanerj(a)redhat.com M: +491784949931 IM: frenzy_friday @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com/>

3 3

[barbican][keystone] Weekly meetings to resume in 2022
by Douglas Mendizabal 15 Dec '21

15 Dec '21

Hi Barbican and Keystone contributors! I'll be taking some time off for the holidays starting next week and won't be available to chair the weekly meetings. I'll be back on January 11 to resume the weekly meetings for both Barbican and Keystone teams. Happy holidays, y'all! See you in 2022! - Douglas Mendizábal (redrobot)

1 0

[ops] [nova] problems with some default nova config values after update to Xena
by Massimo Sgaravatto 15 Dec '21

15 Dec '21

Hi After trying to update a CentOS8-stream testbed to Xena, there is a mess with some default values of nova In particular I see that: - everything (for all services) is being logged to syslog (it looks like that log_dir is using "none") - state_path for nova is using /usr/lib/python3.6/site-packages instead of /var/lib/nova Any hints on how to debug this? Thanks, Massimo

1 0

[Openstack][FOSDEM][CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski 15 Dec '21

15 Dec '21

We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2022, to be hosted virtually on February 5th 2022. This year will mark FOSDEM’s 22nd anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. Due to Covid-19, FOSDEM will be held virtually this year on February 5th & 6th, 2022. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at users or developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 20th of December Acceptance notifications: 25th of December Final schedule announcement: 31st of December Recorded presentations upload deadline: 15th of January Devroom: 6th February 2022 Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will need to be pre-recorded and put into our system at least a couple of weeks before the event. The presentations should be uploaded by 15th of January and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend the virtual FOSDEM event for the Q&A. We will not consider proposals from prospective speakers who are unsure whether they will be able to attend the FOSDEM virtual event. If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance with helping speakers to record the presentation as well as helping with streaming and chat moderation for the devroom. Please contact devroom mailing list [2] for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://penta.fosdem.org/submission/FOSDEM22 [2] iaas-virt-devroom at lists.fosdem.org

1 1

[cinder] Bug deputy report for week of 12-15-2021
by Sofia Enriquez 15 Dec '21

15 Dec '21

This is a bug report from 12-08-2021 to 12-15-2021. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1953704 "Volume Type deletion error (image_volume_cache_enabled = True) - stable/xena". Unassigned. Incomplete - https://bugs.launchpad.net/cinder/+bug/1954613 "Blank volume's attach_status causes the volume list to fail". Unassigned. - https://bugs.launchpad.net/cinder/+bug/1954664 "Customer has issues in removing the volumes on the hosts , volumes from 3par". Unassigned. Cheers -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[all] Pending patches proposed by release bot
by Takashi Kajinami 15 Dec '21

15 Dec '21

(I'm using all tag instead of project specific tags because the list can be too long) Hi all, I noticed that many patches proposed by release bot are still pending on reviews. Because of this, I see several projects like; - unit tests are executed in old test runtimes, - release note for specific release is missing ... https://review.opendev.org/q/owner:infra-root%2540openstack.org+status:open I'd like to encourage each project to take a moment to move these forward, or abandon them if these are unnecessary. I'm trying to list up all projects affected but I might be missing some of them. So please check the above query to find anything maintained by your project. - heat - keystone - mistral - sahara - magnum - adjutant - monasca - murano - barbican - freezer - openstacksdk - zaqar - watcher - telemetry(ceilometer/aodh/panko) Thank you, Takashi

2 2