December 2021 - openstack-discuss

[nova] instance device_metadata
by Arnaud Morin 16 Dec '21

16 Dec '21

Hey all, How is filled the device_metadata in instance_extra db? It's empty for my instances. It's supposed to be accessible then through metadata api, and contains at least network and block device info, but it's empty here. Thanks for any hint!

1 1

[manila] No IRC meeting on 30th Dec 2021
by Goutham Pacha Ravi 16 Dec '21

16 Dec '21

Hi Zorillas, As we discussed during our meeting today [1], we'll have our last IRC meeting for 2021 next week (23rd Dec 2021 at 1500 UTC) in OFTC's #openstack-meeting-alt. We'll skip the meeting on 30th Dec 2021 due to the year end holidays. As always, please feel free to add to the meeting agenda here: https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting Thanks, Goutham Pacha Ravi [1] https://meetings.opendev.org/meetings/manila/2021/manila.2021-12-16-15.01.l…

1 0

[all][tc][policy] Canceling policy popup team next meeting
by Ghanshyam Mann 16 Dec '21

16 Dec '21

Hello Everyone, Due to holiday weeks, we are cancelling the policy pop-up next meeting scheduled for 30th Dec. We will continue this biweekly meeting from 13th Jan. https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… -gmann

1 0

[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 15 Dec '21

15 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