December 2022 - openstack-discuss

[gate][stable][qa] Hold recheck: Devstack based job using tox4 are broken (especially greande, stable jobs)
by Ghanshyam Mann 09 Dec '22

09 Dec '22

Hi All, As you might know, the devstack-based job fails on the tempest command with the below error: Error- venv: failed with tempest is not allowed, use allowlist_externals to allow it It is failing where jobs are using the tox4 (in grenade job or stable branch job or some master branch job like focal job using tox4[1]). This is another issue of mix match of tox version in stable and master jobs which we are discussing in a separate thread[2]. On tempest command or allowlist_externals failure, we are testing one fix for that but please hold recheck until it gets fixed or any workaround is merged - https://review.opendev.org/q/Ifc8fc6cd7aebda147043a52d6baf99a2bacc009c I have opened a bug also to track it https://bugs.launchpad.net/devstack/+bug/1999183 [1] https://zuul.opendev.org/t/openstack/build/aaad7312f68246c0979e1a43cfe96c3b… [2] https://lists.openstack.org/pipermail/openstack-discuss/2022-December/03144… -gmann

1 1

[sahara][sahara-cores] Combined patch that recovers CI tests
by Dmitriy Rabotyagov 09 Dec '22

09 Dec '22

Hi sahara cores, As you might know Sahara has been broken for quite some time now due to multiple reasons, and didn't have passing tests for Zed release at all. I have come up with a patch [1] that fixes major issues, including: * Zuul Queus definition * Adapting new jsonschema version * Replacing usage of iteritems with six As a result Zuul is happy, all tempest and tox tests are passing it the moment. It would be great if you could review these changes and land other important patches to unblock other contributors in the project and prevent it from falling under "inactive" projects list. [1] https://review.opendev.org/c/openstack/sahara/+/864728

1 0

[neutron] Drivers meeting cancelled
by Rodolfo Alonso Hernandez 09 Dec '22

09 Dec '22

Hello Neutrinos: Due to the lack of agenda, today's meeting is cancelled. If you want to add any topic to this meeting, please check [1] and use the "on demand agenda" section. Regards. [1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

1 0

the zun cmd "python3 setup.py install" error(s)
by 无数的星球 09 Dec '22

09 Dec '22

system:ubuntu:20.04 useDocumentation:https://docs.openstack.org/zun/zed/install/controller-inst… root@controller:/var/lib/zun/zun# python3 setup.py install ERROR:root:Error parsing Traceback (most recent call last):   File "/usr/lib/python3/dist-packages/pbr/core.py", line 96, in pbr     attrs = util.cfg_to_args(path, dist.script_args)   File "/usr/lib/python3/dist-packages/pbr/util.py", line 271, in cfg_to_args     pbr.hooks.setup_hook(config)   File "/usr/lib/python3/dist-packages/pbr/hooks/__init__.py", line 25, in setup_hook     metadata_config.run()   File "/usr/lib/python3/dist-packages/pbr/hooks/base.py", line 27, in run     self.hook()   File "/usr/lib/python3/dist-packages/pbr/hooks/metadata.py", line 25, in hook     self.config['version'] = packaging.get_version(   File "/usr/lib/python3/dist-packages/pbr/packaging.py", line 874, in get_version     raise Exception("Versioning for this project requires either an sdist" Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name zun was given, but was not able to be found. error in setup command: Error parsing /var/lib/zun/zun/setup.cfg: Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. It's also possible that there is a mismatch between the package name in setup.cfg and the argument given to pbr.version.VersionInfo. Project name zun was given, but was not able to be found. root@controller:/var/lib/zun/zun# cryed: pip3 install --upgrade distribute pip3 install --upgrade tensorflow_gpu

3 2

Issue resizing volumes attached to running volume backed instances
by Jérôme BECOT 08 Dec '22

08 Dec '22

Hello Openstack, We have Ussuri deployed on a few clouds, and they're all plugged to PureStorage Arrays. We allow users to only use volumes for their servers. It means that each server disk is a LUN attached over ISCSI (with multipath) on the compute node hosting the server. Everything works quite fine, but we have a weird issue when extending volumes attached to running instances. The guests notice the new disk size .. of the last extent. Say I have a server with a 10gb disk. I add 5gb. On the guest, still 10gb. I add another 5gb, and on the guest I get 15, and so on. I've turned the debug mode on and I could see no error in the log. Looking closer at the log I could catch the culprit: 2022-12-08 17:35:13.998 46195 DEBUG os_brick.initiator.linuxscsi [] Starting size: *76235669504* 2022-12-08 17:35:14.028 46195 DEBUG os_brick.initiator.linuxscsi [] volume size after scsi device rescan *80530636800* extend_volume 2022-12-08 17:35:14.035 46195 DEBUG os_brick.initiator.linuxscsi [] Volume device info = {'device': '/dev/disk/by-path/ip-1...1:3260-iscsi-iqn.2010-06.com.purestorage:flasharray.x-lun-10', 'host': '5', 'channel': '0', 'id': '0', 'lun': '10'} extend_volume 2022-12-08 17:35:14.348 46195 INFO os_brick.initiator.linuxscsi [] Find Multipath device file for volume WWN 3624... 2022-12-08 17:35:14.349 46195 DEBUG os_brick.initiator.linuxscsi [] Checking to see if /dev/disk/by-id/dm-uuid-mpath-3624.. exists yet. wait_for_path 2022-12-08 17:35:14.349 46195 DEBUG os_brick.initiator.linuxscsi [] /dev/disk/by-id/dm-uuid-mpath-3624... has shown up. wait_for_path 2022-12-08 17:35:14.382 46195 INFO os_brick.initiator.linuxscsi [] mpath(/dev/disk/by-id/dm-uuid-mpath-3624) *current size 76235669504* 2022-12-08 17:35:14.412 46195 INFO os_brick.initiator.linuxscsi [] mpath(/dev/disk/by-id/dm-uuid-mpath-3624) *new size 76235669504* 2022-12-08 17:35:14.413 46195 DEBUG oslo_concurrency.lockutils [] Lock "extend_volume" released by "os_brick.initiator.connectors.iscsi.ISCSIConnector.extend_volume" :: held 2.062s inner 2022-12-08 17:35:14.459 46195 DEBUG os_brick.initiator.connectors.iscsi [] <== extend_volume: return (2217ms) *76235669504* trace_logging_wrapper 2022-12-08 17:35:14.461 46195 DEBUG nova.virt.libvirt.volume.iscsi [] Extend iSCSI Volume /dev/dm-28; new_size=*76235669504* extend_volume 2022-12-08 17:35:14.462 46195 DEBUG nova.virt.libvirt.driver [] Resizing target device /dev/dm-28 to *76235669504* _resize_attached_volume The logs clearly shows that the rescan confirm the new size but when interrogating multipath, it does not. But requesting multipath few seconds after on the command line shows the new size as well. It explains the behaviour. I'm running Ubuntu 18.04 with multipath 0.7.4-2ubuntu3.2. The os-brick code for multipath is far more basic than the one in master branch. Maybe the multipath version installed is too recent for os-brick. Thanks for the help Jerome

1 0

(PXE FAILURE)using dnsmasq
by Adivya Singh 08 Dec '22

08 Dec '22

Hi Team. i m trying to setup PXE using dnsmasq, it fails on "Address listen on port 53" but i don't see any IP address listen on this port This IP 10.128.244.2 in the interface IP of the Infrastructure server where PXE is ported named as eno2 my dnsmasq.conf looks like this, All other setting are as per PXE configuration a default file under pxelinux.cfg and a installer in default, and a user-data file under the /var/www/html no-resolv interface=eno2 listen-address=10.128.244.2 dhcp-range=10.128.244.102,10.128.244.110,6h dhcp-boot=pxelinux/pxelinux.0 enable-tftp tftp-root=/var/lib/tftpboot Anyone having any idea on this error Regards Adivya Singh

2 1

[IRC Client] [Setup in Macbook] Best Practice to follow
by Rajesh Gunasekaran 07 Dec '22

07 Dec '22

Hello Team, I am really struggling with setting up the OpenStack IRC client in my new macbook pro! I made the switch from Windows to MAC recently. Could someone please advise what is the best practice I should follow to stay connected with #openstack community channels! in IRC while using mac -- Thanks, Rajesh

3 3

[ironic][release] Bugfix branch status and cleanup w/r/t zuul-config-errors
by Jay Faulkner 07 Dec '22

07 Dec '22

Hey all, I've been looking into the various zuul config errors showing up for Ironic-program branches. Almost all of our old bugfix branches are in the list. Additionally, not properly retiring the bugfix branches leads to an ever-growing list of branches which makes it a lot more difficult, for contributors and operators alike, to tell which ones are currently supported. I've put together a document describing the situation as it is now, and my proposal: https://etherpad.opendev.org/p/IronicBugfixBranchCleanup Essentially, I think we need to: - identify bugfix branches to cleanup (I've done this in the above etherpad, but some of the ) - clean them up (the next step) - update Ironic policy to set a regular cadence for when to retire bugfix branches, and encode the process for doing so This means there are two overall questions to answer in this email: 1) Mechanically, what's the process for doing this? I don't believe the existing release tooling will be useful for this, but I'm not 100% sure. I've pulled (in the above etherpad and a local spreadsheet) the last SHA for each branch; so we should be able to EOL these branches similarly to how we EOL stable branches; except manually instead of with tooling. Who is going to do this work? (I'd prefer releases team continue to hold the keys to do this; but I understand if you don't want to take on this manual work). 2) What's the pattern for Ironic to adopt regarding these branches? We just need to write down the expected lifecycle and enforce it -- so we prevent being this deep into "branch debt" in the future. What do folks think? - Jay Faulkner

4 6

[ironic][stable] Cleanup of clerical issues in ironic-stable-maint group
by Jay Faulkner 07 Dec '22

07 Dec '22

Hey all, I was looking over Ironic ACLs in Gerrit today, and I discovered the ironic-stable-maint group which is set to include ironic-core and stable-maint-core (as expected) -- but I also discovered a member in this list who is no longer a core reviewer, or active contributor to Ironic (Jim Rollenhagen). Lucky for us, Jim is a nice guy and we all trust him, and this access hasn't been used. In order to prevent this from happening in the future, I've removed all individual members from the ironic-stable-maint group and left it inheriting from ironic-core. The effective difference is just that Jim has been removed. tl;dr: The effective ironic-stable-maint core group has been dropped by one; Jim Rollenhagen was mistakenly left in the list. Thanks, Jay Faulkner

1 0

[Manila] S-RBAC Hack-a-thon
by Liron Kuchlani 07 Dec '22

07 Dec '22

Hi everyone, We are planning a Hack-a-thon for secure RBAC between Wed 12/07 to Thur 12/08 with Fri 12/09 as needed for code reviews. The session will take place between 15:00 UTC and 15:30 UTC. Join meeting: https://bluejeans.com/8520212381 Please find below helpful references and links, Openstack S-RBAC docs [0] Manila-tempest-plugin S-RBAC tests [1] S-RBAC collab review [2] Manila Secure RBAC Antelope PTG etherpad [3] Openstack Shared File Systems API documentation [4] S-RBAC code reviews [5] S-RBAC Kanban [6] [0] https://docs.openstack.org/patrole/latest/rbac-overview.html [1] https://github.com/openstack/manila-tempest-plugin/tree/master/manila_tempe… [2] https://etherpad.opendev.org/p/Manila-S-RBAC-collaborative-review [3] https://etherpad.opendev.org/p/antelope-ptg-manila-srbac [4] https://docs.openstack.org/api-ref/shared-file-system [5] https://review.opendev.org/q/topic:secure-rbac+project:openstack/manila-tem… [6] https://tree.taiga.io/project/silvacarloss-manila-tempest-plugin-rbac/kanban Hope you can all join us, -- Thanks, Liron

1 1