October 2024 - openstack-discuss - lists.openstack.org

Kolla Ansible on Ubuntu 20.04 - cloud-init & other network issues
by Tobias McNulty 10 Oct '24

10 Oct '24

Hi, I'm attempting to use Kolla Ansible 14.6.0 to deploy OpenStack Yoga on a small 3-node Ubuntu 20.04 cluster. The nodes have 128 GB RAM each, dual Xeon processors, and dual 10G Intel NICs. The NICs are connected to access ports on a 10G switch with separate VLANs for the local and external networks. All the playbooks run cleanly, but cloud-init is failing in the Ubuntu 20.04 and 22.04 VMs I attempt to boot. The VM images are unmodified from https://cloud-images.ubuntu.com/, and cloud-init works fine if I mount a second volume with user-data. The error is a timeout attempting to reach 169.254.169.254. This occurs both when booting a VM in an internal routed network and directly in an external network. I tried various neutron plugin agents (ovn, linuxbridge, and openvswitch both with and without firewall_driver = openvswitch <https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro…>) first with a clean install of the entire OS each time, all with the same result. Running tcpdump looking for 169.254.169.254 shows nothing. As a possible clue, the virtual NICs are unable to pass any traffic (e.g., to reach an external DHCP server) unless I completely disable port security on the interface (even if the associated security group is wide open). But disabling port security does not fix cloud-init (not to mention I don't really want to disable port security). Are there any additional requirements related to deploying OpenStack with Kolla on Ubuntu 20.04? This is a fairly vanilla configuration using the multinode inventory as a starting point. I tried to follow the Quick Start <https://docs.openstack.org/kolla-ansible/yoga/user/quickstart.html> as closely as possible; the only material difference I see is that I'm using the same 3 nodes for control + compute. I am using MAAS so it's easy to get a clean OS install on all three nodes ahead of each attempt. I plan to try again with the standard (non-HWE) kernel just in case, but otherwise I am running out of ideas. In case of any additional clues, here are my globals.yml and inventory file, along with the playbook I'm using to configure the network, images, VMs, etc., after bootstrapping the cluster: https://gist.github.com/tobiasmcnulty/7dbbdbc67abc08cbb013bf5983852ed6 Thank you in advance for any advice! Cheers, Tobias

5 9

DevStack Installation Issue on Ubuntu (Bare Metal) - Can't add security group and floating IP
by nayeem.hossain＠enosisbd.com 09 Oct '24

09 Oct '24

Hi, I hope you're doing well. I am Nayeem from Bangladesh, and we are in the process of installing DevStack on an Ubuntu machine for a proof of concept (POC). However, after installation, we are facing issues with adding security groups and attaching floating IPs to instances in OpenStack. Additionally, we are unable to access the instance from the same LAN. Could you please assist us in resolving these issues? Thank you for your support. Best regards, Nayeem

1 0

{Horizon] Weekly meeting cancelled Oct 9
by Tatiana Ovchinnikova 09 Oct '24

09 Oct '24

Hi team, As we have discussed last week, today's meeting is cancelled. See you next week! With kind regards, Tatiana

1 0

Operators
by engineer2024 09 Oct '24

09 Oct '24

I can't the openstack operators mailing list. Can someone please point me in the right direction?

5 4

Improving stestr... or switching to a (better) compatible test runner?
by Thomas Goirand 09 Oct '24

09 Oct '24

Hi, This is the 2nd time I'm opening a thread about it. Sorry for this, but it really bothers me. Today, running tempest, I got these stats from stestr: - Worker 0 (132 tests) => 0:24:49.209885 - Worker 1 (100 tests) => 0:17:14.791845 - Worker 2 (124 tests) => 0:42:52.690906 - Worker 3 (189 tests) => 0:41:21.307241 - Worker 4 (159 tests) => 0:45:49.503031 - Worker 5 (143 tests) => 0:28:13.282371 - Worker 6 (156 tests) => 3:16:52.364976 - Worker 7 (103 tests) => 0:46:05.366089 So, thread #1 ran 17 minutes, sitting idle for the rest of the 3 hours run of thread #6. While I thought stestr was deviding the number of tests by the number of thread, I don't get why worker #1 only had 100 tests assigned. All together, all tests could have been ran within maybe less than an hour of time (rather than 3h16 above), if not-yet-ran-tests were reassigned to idle treads. I'm currently spending a lot of time on running tempest. Indeed, I'm running tempest on each OpenStack upgrade, from Victoria up to Dalmatian. With the current way stestr run, it may take 2 full days to do that (and that's not even counting when upgrade will fail and will need fixing...), when it could be done in maybe 8 hours (if I count 1h per OpenStack release). So, knowing the above, it might be a good use of my time to dig into stestr and see if I can fix this... or not! Does anyone have a suggestion for another test runner, that's compatible with stestr, at least for the tests selection with a regular expression? As much as I know, pytest cannot take a regexp for test selection, can it? Or is there maybe a plugin for it? If there's no compatible test runner, where should I dig in the stestr code to rewrite things in a smarter way? Cheers, Thomas Goirand (zigo) P.S: On Caracal today, I just had this: ============== Worker Balance ============== - Worker 0 (117 tests) => 0:59:32.291385 - Worker 1 (147 tests) => 1:22:28.228980 - Worker 2 (125 tests) => 0:45:20.969397 - Worker 3 (114 tests) => 1:46:21.667579 - Worker 4 (170 tests) => 0:45:27.577738 - Worker 5 (190 tests) => 2:28:39.744920 - Worker 6 (182 tests) => 2:29:01.402255 - Worker 7 (152 tests) => 2:29:10.183359 this looks better, but that's probably 1/ random 2/ still not perfect, with worker #0, #2 and #4 doing nothing 2/3rd of the time.

2 1

[tc][watcher] No leaders for project team, heading to retirement
by Goutham Pacha Ravi 09 Oct '24

09 Oct '24

Hello Stackers, The "watcher" project [1] did not have any volunteers to lead the project in the 2025.1 election cycle. In the past few years, the project's team has slowly disbanded and there have been no significant changes proposed/merged in the project's repositories [2]. We noticed that there were three deployers that noted their use of Watcher in production in the past user survey [3]. It's possible that the project failed to gather any significant adoption, and hence there's less interest in contributing to, and maintaining the project. I'm sending this notification pursuant to the OpenStack governance recommendations [4] to retire project teams. We can mark a project team "inactive", however, an "inactive" project must have some contributors aiming to build-back a maintainers team around it - and it must pick a project team lead, or adopt a distributed project leadership model by nominating liaisons. Since there are no PTL nominees, we think marking this project "inactive" serves no purpose. Is there any objection to retiring the "openstack/watcher" project (and associated deliverables: python-watcherclient, watcher-dashboard and watcher-tempest-plugin)? Once the project is retired, configuration management and deployment projects can drop their integrations as well. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi [1] https://wiki.openstack.org/wiki/Watcher [2] https://review.opendev.org/q/(project:%5Eopenstack/watcher.*+OR+project:ope… [3] https://governance.openstack.org/tc/user_survey/analysis-2023.html [4] https://governance.openstack.org/tc/reference/dropping-projects.html

5 7

[all][manila][ironic][swift][bandit] removal of Python standard libraries in Python 3.13
by Thomas Goirand 08 Oct '24

08 Oct '24

Hi, OpenStack Dalmatian is currently fully in Debian Testing, and in a quite good shape. However, as you may know, Python 3.13 is about to be uploaded to Debian unstable, and we intend to release Debian 13 (aka: Trixie) with it. A number of OpenStack (or related) packages are affected by the removal of Python standard libraries in Python 3.13. We need to fix these ASAP (and not only because of Debian). Here's the list of affected projects, with the name of the bad import that was removed from Python 3.13: manila https://bugs.debian.org/1084543 (pipes) swift https://bugs.debian.org/1084544 (cgi) ironic https://bugs.debian.org/1084566 (crypt) ironic-python-agent https://bugs.debian.org/1084680 (crypt) bandit https://bugs.debian.org/1084700 (crypt, telnetlib) There's also a number of libraries that we don't directly maintain, but that are in our requirements: qpid-proton https://bugs.debian.org/1084552 (cgi) python-wsme https://bugs.debian.org/1084594 (cgi) python-falcon https://bugs.debian.org/1084623 (cgi) python-pysaml2 https://bugs.debian.org/1084670 (cgi) These will need to be fixed. For more details with were the bad import was found, please dive into the individual bug reports. While pipes and crypt have direct replacement (subprocess and for example the pypi module bcrypt), there's a few comments here: https://docs.python.org/3.13/whatsnew/3.13.html While I will for sure attempt to fix some of the above, I cannot be held responsible for all of OpenStack code, and I'd appreciate a lot having some help. Unless I'm being pointed at fixes patches in Gerrit, I'll start filling bugs for the above once I'm done with other tasks (currently, I'm working on validation of OpenStack upgrades in Debian), and hopefully, get all in order before Trixie's freeze in early 2025. I know there's probably going to be more Python 3.13 fixes to come, and I expect some package to fail to build from source (FTBFS) due to some tests failing in 3.13. Then I'll run my usual tempest validation CI, and hopefully, Dalmatian on Trixie will be the best OpenStack ever... :) In the mean time, let's tackle the above. Cheers, Thomas Goirand (zigo)

7 7

[publiccloud-sig] Heads-Up: next meeting October 9th (tomorrow) - 0700 UTC
by Felix Kronlage-Dammers 08 Oct '24

08 Oct '24

Hi everyone, This Wednesday, tomorrow, (October 9th) the next meeting of the publiccloud-sig is going to happen. Thanks to Artem (gtema) and Joern (joek-office) who helped prepare the meeting agenda for this wednesday: - Housekeeping - Upcoming vPTG - Reminder to sign up for PTG: https://openinfra.dev/ptg/ - CfPs for Devrooms @ FOSDEM 2025 -> Sovereign Cloud Devroom? - Continued discussion regarding IAM Federation If you’re interesting in IAM federation, be sure to join! We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> Due to vacation, I’ll not be around so I wish a fruitful meeting :) felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

Configuring Multiple IdPs with OpenStack and Shibboleth
by Abubakur Sait 08 Oct '24

08 Oct '24

Hello everyone, I have successfully configured a single Shibboleth Federation system with OpenStack (using a single IdP and SP) on a DevStack deployment. Now, I’m looking to expand the setup to support multiple IdPs with OpenStack. I followed the instructions on the Shibboleth SessionInitiator page ( https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334685/SessionIn…) but I haven’t had any success so far. Does anyone have experience or suggestions on how to configure multiple IdPs in this setup? Thank you in advance for any guidance! Best regards, Abubakur Sait

1 0

How to create snapshot via Python module
by Saeed Fazlollahzadeh 08 Oct '24

08 Oct '24

Hello, this is my full code to create a snapshot from an instance. The code creates a new image with type snapshot, but after around 2 hours, its status is still in queue. But when I create another snapshot via the Openstack UI, it works fine. Would you please help me how can I create a snapshot? import openstack import datetime now = datetime.datetime.now() today = now.strftime('%Y_%m_%d_%H_%M_%S') openstack.enable_logging(debug=False) servers = [] images = [] openstack_connection = openstack.connect(cloud='region1') # clouds.yaml for server in openstack_connection.compute.servers(details=True, hostname='my_server'): servers.append(server.to_dict()) servers = servers[0] for image in openstack_connection.compute.images(details=True, id=servers['image']['id']): images.append(image.to_dict()) images = images[0] name = f'my_server_{today}' openstack_connection.image.create_image( name=name, disk_format='raw', container_format='bare', visibility='private', timeout=1, properties={ 'hw_disk_bus': 'scsi', 'hw_qemu_guest_agent': 'yes', 'hw_scsi_model': 'virtio-scsi', 'hw_watchdog_action': 'reset', 'base_image_ref': servers['image']['id'], 'owner_user_name': 'whmcs', 'owner_project_name': 'admin', 'boot_roles': 'admin,reader,member', 'os_admin_user': 'administrator', 'os_distro': 'windows', 'os_type': 'windows', 'owner_specified.openstack.object': images['metadata']['owner_specified.openstack.object'], 'clean_attempts': '1', 'hw_machine_type': 'pc', 'password_0': '', 'password_1': '', 'password_2': '', 'password_3': '', 'hw_cdrom_bus': 'ide', 'hw_input_bus': 'usb', 'hw_pointer_model': 'usbtablet', 'hw_video_model': 'virtio', 'hw_vif_model': 'virtio', 'instance_uuid': servers['id'], 'image_type': 'snapshot', } )

2 2