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

[release] Release countdown for week R-24, Oct 14 - 18
by Elõd Illés 11 Oct '24

11 Oct '24

Hi, Welcome back to the release countdown emails! These will be sent at major points in the 2025.1 Epoxy development cycle, which should conclude with a final release on April 2nd, 2025. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2025.1 Epoxy development cycle, assessing 2025.1 Epoxy community goals and approving 2025.1 Epoxy specs. General Information ------------------- 2025.1 Epoxy is a 26 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/epoxy/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2024.2 Dalmatian release are continued in 2025.1 Epoxy with a similar release model. Upcoming Deadlines & Dates -------------------------- Project Teams Gathering: October 21-25, 2024 Epoxy-1 milestone: November 14th, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla] Weekly meeting 16th Oct cancelled
by Michał Nasiadka 11 Oct '24

11 Oct '24

Hello Koalas, Cancelling weekly meeting on 16th October due to OpenInfra Days USA (Indianapolis). The next meeting (23rd October) is also cancelled because we’ll be meeting on Kolla vPTG (https://etherpad.opendev.org/p/kolla-epoxy-ptg) Please propose PTG topics and see you there! Michal

1 0

[PTG][ironic] APAC timezone friendly slot
by Riccardo Pittau 10 Oct '24

10 Oct '24

Hello ironicers! The PTG is getting closer, it's just 10 days away! This time too the ironic team would like to have an APAC timezone friendly slot to allow operators, contributors, and in general anyone interested in ironic from that timezone to be able to hear about the current ironic project direction, propose and discuss topics, or just listen to what's in the plans for epoxy. Looking at the current schedule we can place such a slot on Tuesday 21 or Wednesday 22, and of course we'd like to hear from whoever is interested for potential suited times. Don't hesitate to reply here or contact the ironic team in our IRC channel #openstack-ironic Thanks! Ciao Riccardo (rpittau)

1 0

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

How to create snapshot via python module?
by Saeed 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', } )

1 0

[neutron] OVS Agent constant bridges recreation
by Artsiom Antropau 08 Oct '24

08 Oct '24

Hi, Team! Pretty long time we’re experiencing some troubles with auto-restoration of ovs after some storms. We’re using neutron-wallaby and openvswitch 2.15. The problem is the next: After some storms we’re receiving situation, when ovs agent constantly recreating bridges and doing full syncs, which affects our network stability. All versions (incl. 2024.2), containing some parts of code that I want to highlight: 1. Non-empty `idl_monitor.bridges_added` triggers 2. `_do_reconfigure_physical_bridges`, then it triggers 3. `setup_physical_bridges(bridge_mappings)` then it contains 4. br.create() I’m seeing note in code «The bridge already exists, so create won't recreate it», BUT at the same time we’re receiving in logs: ``` Matched CREATE: BridgeCreateEvent(events=('create',), table='Bridge', conditions=None, old_conditions=None) to row=Bridge(name=br-tun ``` and ``` BridgeCreateEvent, bridge name: br-tun ``` Constantly – by hours and for all our bridges (we have four: br-tun, br-ex, br-int, br-rmi) while we will not restart ovs agent. So this event filling idl_monitor.bridges_added then ovs reacting on it by _do_reconfigure_physical_bridges, then it triggers br.create() and we’re receiving event once again – we’re in loop. Want to add that our datapath-id NOT changing between these runs – keeps same. Any ideas or ways how to fix this problem and never experience it next? [https://my.gcdn.co/images/signature/gcore_logo.png]<https://gcore.com/> Artsiom Antropau Software Engineer artsiom.antropau(a)gcore.com<mailto:artsiom.antropau@gcore.com> +48796909739<tel:+48796909739> gcore.com<https://gcore.com/> [https://my.gcdn.co/images/signature/linkedin.png]<https://www.linkedin.com/company/g-core> [https://my.gcdn.co/images/signature/x.png] <https://x.com/gcore_official> [https://my.gcdn.co/images/signature/youtube.png] <https://www.youtube.com/channel/UCFhtQE7HB097a1_Nfv-Ma_Q> [https://my.gcdn.co/images/signature/facebook.png] <https://www.facebook.com/gcorelabscom/> [https://my.gcdn.co/images/signature/instagram.png] <https://www.instagram.com/gcore.official/> This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment.

2 1

image creation error
by BEDDA Fadhel 08 Oct '24

08 Oct '24

I'm trying to create a debian image for openstack from a file. on the graphical interface it still remains waiting. On the command line: I receive the message: HttpException: 502: Server Error for url: http://192.168.11.40/image/v2/images/1bb75b80-f6d2-4a26-a941-a52b03e48455/f…, : 502 Bad Gateway: Bad Gateway: The proxy server received an invalid: response from an upstream server.: Apache/2.4.52 (Ubuntu) Server at 192.168.11.40 Port 80 Merci

1 0

[manila] stuck at connecting ceph backend with manila
by Shubham Kumar Yadav 08 Oct '24

08 Oct '24

hello, I'm trying to install manila in my openstack cloud (deployed on k8s cluster) but having problem. 1 -> i created the auth using ceph auth get-or-create client.manila -o manila.keyring \ mgr 'allow rw' \ mon 'allow r' source - https://docs.openstack.org/manila/latest/configuration/shared-file-systems/… 2 -> in manila-share pod i see the error 2024-10-08 07:37:25.090 7 INFO manila.share.drivers.cephfs.driver [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] [CEPHFSNATIVE1] Ceph client found, connecting... 2024-10-08 07:37:25.104 7 ERROR manila.share.manager [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] Error encountered during initialization of driver CephFSDriver@lab-11053-26006-ceph-1@cephfsnative1: manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. 2024-10-08 07:37:25.104 7 ERROR manila.share.manager Traceback (most recent call last): 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 421, in rados_client 2024-10-08 07:37:25.104 7 ERROR manila.share.manager self._rados_client.connect() 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "rados.pyx", line 690, in rados.Rados.connect 2024-10-08 07:37:25.104 7 ERROR manila.share.manager rados.IOError: [errno 5] RADOS I/O error (error connecting to the cluster) 2024-10-08 07:37:25.104 7 ERROR manila.share.manager 2024-10-08 07:37:25.104 7 ERROR manila.share.manager During handling of the above exception, another exception occurred: 2024-10-08 07:37:25.104 7 ERROR manila.share.manager 2024-10-08 07:37:25.104 7 ERROR manila.share.manager Traceback (most recent call last): 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/manager.py", line 371, in _driver_setup 2024-10-08 07:37:25.104 7 ERROR manila.share.manager self.driver.do_setup(ctxt) 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 274, in do_setup 2024-10-08 07:37:25.104 7 ERROR manila.share.manager rados_client=self.rados_client, 2024-10-08 07:37:25.104 7 ERROR manila.share.manager File "/var/lib/openstack/lib/python3.10/site-packages/manila/share/drivers/cephfs/driver.py", line 424, in rados_client 2024-10-08 07:37:25.104 7 ERROR manila.share.manager raise exception.ShareBackendException( 2024-10-08 07:37:25.104 7 ERROR manila.share.manager manila.exception.ShareBackendException: [%(be)s] Ceph client failed to connect. 2024-10-08 07:37:25.104 7 ERROR manila.share.manager 2024-10-08 07:37:25.105 7 DEBUG manila.utils [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] Finished call to 'manila.share.manager.ShareManager.init_host.<locals>._driver_setup' after 62.106(s), this was the 6th time calling it. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/after.py:44 2024-10-08 07:37:25.105 7 DEBUG manila.utils [None req-fffe12f7-c7aa-42dc-aea1-bed6f918b278 - - - - - -] Retrying manila.share.manager.ShareManager.init_host.<locals>._driver_setup in 64.0 seconds as it raised ShareBackendException: [%(be)s] Ceph client failed to connect.. log_it /var/lib/openstack/lib/python3.10/site-packages/tenacity/before_sleep.py:65 3 -> when i try to use the maila keyring i get the error *[rook@cmp-2 ceph]$ ceph --key AQBip/9mCMf4N/jFNKFlwl/hA4j64esWuA== osd ls[errno 13] RADOS permission denied (error connecting to the cluster)*this is what i get after running that not sure what permissions any idea? -> i also tried with admin rights to the auth *[rook@cmp-2 ceph]$ ceph auth get client.manila[client.manila] key = AQBip/9mCMf4N/jFNKFlwl/hA4j64esWuA== caps mds = "allow *" caps mgr = "allow *" caps mon = "allow *" caps osd = "allow *"exported keyring for client.manila * 4-> my manila conf looks like conf: manila: DEFAULT: debug: true enabled_share_protocols: NFS,CIFS,CEPHFS enabled_share_backends: cephfsnative1 cephfsnative1: driver_handles_share_servers: False share_backend_name: CEPHFSNATIVE1 share_driver: manila.share.drivers.cephfs.driver.CephFSDriver cephfs_conf_path: /etc/ceph/ceph.conf cephfs_protocol_helper_type: CEPHFS cephfs_auth_id: manila cephfs_cluster_name: rook-ceph cephfs_filesystem_name: myfs any idea what could be wrong? Hope to hear from you soon Thank you!

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R-25)
by Goutham Pacha Ravi 07 Oct '24

07 Oct '24

Hello Stackers, This week, we begin our 26-week endeavor towards the next SLURP release, 2025.1 ("Epoxy") [1]. OpenStack Project Teams will meet virtually at the Project Teams Gathering (PTG) in two weeks, starting on 2024-10-21 [2]. The OpenStack TC plans to host cross project meetings during the following time slots: - 2024-10-21 (Monday): 1400 UTC - 1700 UTC - 2024-10-25 (Friday): 1500 UTC - 1700 UTC You'll find the proposed topics on the PTG Etherpad [3]; please add your IRC nickname if you'd like to attend or be notified when discussions begin. Last week, a few community leads presented at OpenInfra Live, recapping the 2024.2 release [4]. I encourage you to watch the presentation and follow the themes each team is pursuing in the "Epoxy" release cycle. I'm excited to share that the organizers of the upcoming OpenInfra Days North America (Oct 15-16) have made it a hybrid event. Please register if you plan to attend virtually [5]. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held simultaneously on IRC [6] and video [7]. We discussed meeting times, and the current time (Tuesdays at 1800 UTC) was retained due to a lack of consensus on better alternatives. Sylvain Bauza (bauzas) volunteered to be an Election Official for the 2025.2 elections, which will be announced around February 2025. We also discussed "leaderless" projects for the 2025.1 release and appointed leaders for the OpenStack Mistral, OpenStack Watcher, and OpenStack Swift projects. Additionally, we created a TC tracker for the 2025.1 release cycle [8] to monitor the progress of community goals and other governance initiatives. The next OpenStack Technical Committee meeting is today (2024-10-08) at 1800 UTC on the #openstack-tc IRC channel on OFTC. You can find the agenda on the weekly meeting wiki page [9]. I hope you can join us! Below is a list of governance changes that have merged in the past week and those still pending community review. === Governance Proposals === ==== Merged ==== - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 ==== Open for Review ==== - Mark kuryr-kubernetes and kuryr-tempest-plugin inactive | https://review.opendev.org/c/openstack/governance/+/929698 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Propose the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/931254 === Upcoming Events === - 2024-10-08: OpenInfra Monthly Board Meeting: https://board.openinfra.dev/ - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering: https://openinfra.dev/ptg/ Thank you for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] "Epoxy" PTG Schedule: https://ptg.opendev.org/ptg.html [3] Technical Committee PTG Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [4] "Introducing OpenStack Dalmatian 2024.2": https://youtu.be/6igJNIJ9yFE [5] OpenInfra Days NA: https://ittraining.iu.edu/explore-topics/titles/oid-iu/index.html#register [6] TC Meeting IRC Log, 2024-10-01: https://meetings.opendev.org/meetings/tc/2024/tc.2024-10-01-18.00.log.html [7] TC Meeting Video Recording, 2024-10-01: https://youtu.be/6RXE1LfEv7w [8] 2025.1 TC Tracker: https://etherpad.opendev.org/p/tc-2025.1-tracker [9] TC Meeting Agenda, 2024-10-08: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

L2 gateway
by engineer2024 07 Oct '24

07 Oct '24

I am trying to understand the L2-GW concept in openstack neutron. I understand that its primary purpose is to bridge two l2 networks into one single network. We have tenant and provider networks in neutron. 1. Why would anyone want to bridge two l2 networks in the first place ? 2. Can these two l2 networks be, two unroutable tenant networks ? Please bear with my ignorance here. I am trying to grasp and learn these concepts. Any help in this regard is much appreciated... Thanks elinux

2 2

[neutron][nova][oslo][all] Common middleware to log requests
by Takashi Kajinami 07 Oct '24

07 Oct '24

Hello, (I'm adding tags from teams which may be directly involved with this discussion but also add all tag because this topic is actually a global topic) I recently spent some time to try neutron deployments with api run by httpd and rcp-server, and I noticed that I no longer see request details logged in neutron logs. It used to be logged by WSGI server implementation in oslo.service (which heavily depends on eventlet and being removed). Based on my past experience, the information is quite important when we have to debug any problems triggered by API request (API returned 500, Tried to create a resource but it failed, etc...). WSGI server (uwsgi or apache) may have their own request loggings but the problem with these is that these do not log context details (especially request id) so analyzing logs is still difficult. I initially created https://bugs.launchpad.net/neutron/+bug/2083760 to discuss this problem in neutron. However, when I looked at a few other repos, I noticed that current implementation is quite inconsistent across projects and now I think this needs to be discussed as a more global topic. IMO the current inconsistency makes debugging quite difficult and we need more consistent logging to help operators get more consistent and detailed information. 1. Some projects (eg. aodh, designate, octavia) does not log requests 2. Other projects (eg. cinder, glance, heat) log requests in their logic but does not log some items such as remote addr and response time. 3. nova[1] and placement[2] have own request_log middleware with more complete information (but one in nova does not have debug log dumped when api starts processing the request) I'm wondering if it makes sense to import the existing request_log middleware implementation from nova/placement and use it globally (and drop the existing logging with less incomplete information to avoid redundant logs). Thank you, Takashi [1] https://github.com/openstack/nova/blob/master/nova/api/openstack/requestlog… [2] https://github.com/openstack/placement/blob/master/placement/requestlog.py -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 4

[neutron] [ovs] OVS agent constant bridge recreate flow
by Max Payne 07 Oct '24

07 Oct '24

Hi, Team! Pretty long time we’re experiencing some troubles with auto-restoration of ovs after some storms. We’re using neutron-wallaby and openvswitch 2.15. The problem is the next: After some storms we’re receiving situation, when ovs agent constantly recreating bridges and doing full syncs, which affects our network stability. All versions (incl. 2024.2), containing some parts of code that I want to highlight: 1. Non-empty `idl_monitor.bridges_added` triggers 2. `_do_reconfigure_physical_bridges`, then it triggers 3. `setup_physical_bridges(bridge_mappings)` then it contains 4. br.create() I’m seeing note in code «The bridge already exists, so create won't recreate it», BUT at the same time we’re receiving in logs: ``` Matched CREATE: BridgeCreateEvent(events=('create',), table='Bridge', conditions=None, old_conditions=None) to row=Bridge(name=br-tun ``` and ``` BridgeCreateEvent, bridge name: br-tun ``` Constantly – by hours and for all our bridges (we have four: br-tun, br-ex, br-int, br-rmi) while we will not restart ovs agent. So this event fills idl_monitor.bridges_added then ovs reacting on it by _do_reconfigure_physical_bridges, then it triggers br.create() and we’re receiving event once again – we’re in the loop. Want to add that our datapath-id NOT changing between these runs – keeps same. Additional debugging shows that bridges `_uuid` are not changing in tables, which means that rows were not added => but for some reason, we’re receiving an event about it. Any ideas or ways how to fix this problem and never experience it again?

2 1

[neutron] Bug report 40th week (Sep 30th - Oct 6th)
by Rodolfo Alonso Hernandez 07 Oct '24

07 Oct '24

Hello Neutrinos: This is the bug report of the 40th week (Sep 30th - Oct 6th). High: * https://bugs.launchpad.net/neutron/+bug/2083237: Initial router state is not set correctly. Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/929406. * https://bugs.launchpad.net/neutron/+bug/2083287: test_add_router_interfaces_on_overlapping_subnets_returns_400 failed when retrying router interface removal after API timeout; (pymysql.err.OperationalError) (1205, 'Lock wait timeout exceeded; try restarting transaction') in neutron log. *Not assigned*. * https://bugs.launchpad.net/neutron/+bug/2083482: "neutron-fullstack-with-uwsgi-fips" failing in stable releases (Zed, 2023.1). Assigned. Patches proposed: https://review.opendev.org/q/topic:%22bug/2083482%22. * https://bugs.launchpad.net/neutron/+bug/2083483: [ovn-octavia-provider] [neutron]/endpoint_type is not respected. Assigned. Patch proposed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/931141. * https://bugs.launchpad.net/neutron/+bug/2083609: neutron.tests.fullstack.test_l3_agent.TestHAL3Agent.test_ha_router_failover_host_failure fails with "MismatchError: 2 != 1: More than one active HA routers". *Not assigned*. * https://bugs.launchpad.net/neutron/+bug/2083682: Slowness of security groups list API. *Not assigned*. Medium: * https://bugs.launchpad.net/neutron/+bug/2083226: [scale] Adding a public external network to a router is killing database. Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/930888. * https://bugs.launchpad.net/neutron/+bug/2083456: Unable to detect from OVN DB if Neutron uses distributed floating IPs or not. Assigned. Patch proposed: https://review.opendev.org/c/openstack/neutron/+/931067. * https://bugs.launchpad.net/neutron/+bug/2083570: Neutron times out handling a request to create a network. *Not assigned*. To be discussed/undecided: * https://bugs.launchpad.net/neutron/+bug/2083527: [OVN] dnat_and_snat rules are setting GATEWAY_PORT when LR pinned to chassis. * https://bugs.launchpad.net/neutron/+bug/2083760: API request is not logged when neutron is run by httpd+mod_wsgi. Regards.

1 0

[Openstack] devstack won't startup nova-api
by Maxim Sava 07 Oct '24

07 Oct '24

Hi, During new devstack install get nova-api did not start. I appreciate any help you can provide. # Logs: +:: sleep 1 ++:: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}' http://192.168.122.157/compute/v2.1/ +:: [[ 503 == 503 ]] +:: sleep 1 ++:: curl -g -k --noproxy '*' -s -o /dev/null -w '%{http_code}' http://192.168.122.157/compute/v2.1/ +:: [[ 503 == 503 ]] +:: sleep 1 +functions:wait_for_service:472 rval=124 +functions:wait_for_service:477 time_stop wait_for_service +functions-common:time_stop:2421 local name +functions-common:time_stop:2422 local end_time +functions-common:time_stop:2423 local elapsed_time +functions-common:time_stop:2424 local total +functions-common:time_stop:2425 local start_time +functions-common:time_stop:2427 name=wait_for_service +functions-common:time_stop:2428 start_time=1728285798601 +functions-common:time_stop:2430 [[ -z 1728285798601 ]] ++functions-common:time_stop:2433 date +%s%3N +functions-common:time_stop:2433 end_time=1728285858734 +functions-common:time_stop:2434 elapsed_time=60133 +functions-common:time_stop:2435 total=2287 +functions-common:time_stop:2437 _TIME_START[$name]= +functions-common:time_stop:2438 _TIME_TOTAL[$name]=62420 +functions:wait_for_service:478 return 124 +lib/nova:start_nova_api:1015 die 1015 'nova-api did not start' +functions-common:die:285 local exitcode=0 [Call Trace] ./stack.sh:1299:start_nova_api /opt/stack/devstack/lib/nova:1015:die [ERROR] /opt/stack/devstack/lib/nova:1015 nova-api did not start exit_trap: cleaning up child processes Error on exit # Trying to connect [stack@devstack devstack]$ curl http://192.168.122.157/compute/v2.1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>503 Service Unavailable</title> </head><body> <h1>Service Unavailable</h1> <p>The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.</p> <hr> <address>Apache/2.4.52 (Ubuntu) Server at 192.168.122.157 Port 80</address> </body></html>

2 1

How To Create Snapshot Via Python Module
by Saeed 06 Oct '24

06 Oct '24

Hello everyone, this is my python code to find a specific server: import openstack openstack.enable_logging(debug=False) servers = [] for region in ['region1', 'region2', 'region3']: openstack_connection = openstack.connect(cloud=region) # clouds.yaml for server in openstack_connection.compute.servers(details=True, hostname='my_specific_hostname'): servers.append(server.to_dict()) servers = servers[0]['id'] Now I'm going to create a snapshot from this ID only. How can I do that? I read the documents but was unable to find proper way in Python. Regards, Saeed

1 0

Re: openstack-discuss Digest, Vol 72, Issue 23
by BEDDA Fadhel 06 Oct '24

06 Oct '24

Good morning, I created a debian (12) instance on openstack. But I don't know what the username and password are. Please help m Le ven. 4 oct. 2024 à 19:48, <openstack-discuss-request(a)lists.openstack.org> a écrit : > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > Today's Topics: > > 1. Re: [all][qa][infra] Restore unit tests for intermediate python > versions > (Takashi Kajinami) > 2. Re: [all][qa][infra] Restore unit tests for intermediate python > versions > (Takashi Kajinami) > 3. Re: [cinder] What is the "official" name for Cinder in the service > catalog? > (Ghanshyam Mann) > 4. Re: [cinder] What is the "official" name for Cinder in the service > catalog? > (Takashi Kajinami) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 5 Oct 2024 02:26:59 +0900 > From: Takashi Kajinami <kajinamit(a)oss.nttdata.com> > Subject: Re: [all][qa][infra] Restore unit tests for intermediate > python versions > To: Clark Boylan <cboylan(a)sapwetik.org>, > openstack-discuss(a)lists.openstack.org > Message-ID: <9aec1a2b-0f30-4a47-879f-76ada4412057(a)oss.nttdata.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 10/5/24 01:47, Clark Boylan wrote: > > On Fri, Oct 4, 2024, at 9:30 AM, Takashi Kajinami wrote: > >> Hello, > >> > >> > >> As you may know, current master runs unit tests with only Python 3.9 > >> and Python 3.12. > >> My understanding about this set up is that we test the minimum boundary > >> and the maximum > >> boundary and assume the change may work with all the versions between > >> these two. > >> > >> However in some of my recent work I had to introduce the switch in the > >> middle of these > >> two versions. For example > >> https://review.opendev.org/c/openstack/neutron/+/931271 introduces > >> the logic to distinguish Python < 3.10 from Python >= 3.10 , and we > >> don't specifically > >> test that boundary. I'm afraid that this may potentially cause uncaught > >> problems. > > > > One approach that wasn't discussed in the change is to continue to use > the existing code (pkg_resources) until python3.12 then only change the > behavior for 3.12. That approach would generally work if we are only > testing the boundaries since we're flipping the behavior on the boundary. > > For this case we need python 3.11 job to test the boundary. Also this > leaves > noisy deprecation warnings in < Python 3.11 . > > > > >> > >> So my question here is ... Can we test all supported python versions, > >> not only min/max, > >> at least in check jobs ? This would helps us catch any regressions > >> caused by such > >> implementation. > > > > We can. The main limitation is that we may not have a test platform for > every version of python depending on how the distro releases align with > python releases. Currently I think we have a platform for every release > though (centos/rocky 3.9, jammy 3.10, bookworm 3.11, noble 3.12). If we end > up without a platform for a version of python jobs may need to be updated > to install python from source or some other method. > > acknowledged > > > >> > >> I know there could be tradeoffs between test coverage and infra > >> resources, but IMO > >> this is the test coverage we should fill. > > > > Yes, the main concern was simply to avoid unnecessary effort. In the > case of unittest jobs the vast majority of those are much cheaper in terms > of resources than tempest jobs. I think if we stuck to this primarily for > unittests the impact would be minimal. If we tried to expand the tempest > matrix that would become unwieldy. > > Yes. I don't intend to run all tests in all versions but at least having > unit test jobs, > which are supposed to be cheap, may avoid 0 test coverage and would be > enough now. > > In case we find any real problems then we can expand the scope to other > jobs. > > > > >> > >> Thank you, > >> > >> -- > >> Takashi Kajinami > >> irc: tkajinam > >> github: https://github.com/kajinamit > >> launchpad: https://launchpad.net/~kajinamit > > ------------------------------ > > Message: 2 > Date: Sat, 5 Oct 2024 02:29:31 +0900 > From: Takashi Kajinami <kajinamit(a)oss.nttdata.com> > Subject: Re: [all][qa][infra] Restore unit tests for intermediate > python versions > To: Jeremy Stanley <fungi(a)yuggoth.org>, > openstack-discuss(a)lists.openstack.org > Message-ID: <6b5f06e2-1c2f-4e62-be6f-fb289922bb4d(a)oss.nttdata.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 10/5/24 02:16, Jeremy Stanley wrote: > > On 2024-10-05 01:30:30 +0900 (+0900), Takashi Kajinami wrote: > > [...] > >> to distinguish Python < 3.10 from Python >= 3.10 > > [...] > > > > This is a questionable choice of implementation, given some distros > > in the past have backported features to older releases or reverted > > removals they saw as regressions. When possible, it makes more sense > > to test for the existence/absence of the feature you want to use > > rather than blindly assuming the (C)Python version will serve as a > > faithful proxy. An up-side to this approach is that you don't need > > to worry as much about version boundaries, as long as you test > > versions both with and without the feature/behavior in question. > > The super annoying thing with that change is that > importlib.metadata.entry_point > has been existing since python 3.8 but it changed the behavior in python > 3.10 . > So checking existance of modules/attributes didn't work and I avoided > implementing > hanky inspect check to analyze accepted arguments. > > An alternative solution may be relying on importlib_metadata for all > versions because > it works for Python 3.12, but I was unsure if requiring unnecessary 3rd > party dependency > to make the code older version would be a good choice. > > ------------------------------ > > Message: 3 > Date: Fri, 04 Oct 2024 10:38:36 -0700 > From: Ghanshyam Mann <gmann(a)ghanshyammann.com> > Subject: Re: [cinder] What is the "official" name for Cinder in the > service catalog? > To: "Artem Goncharov" <artem.goncharov(a)gmail.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Message-ID: > <192589cb074.be2d62a51024073.7540045177503817038(a)ghanshyammann.com > > > Content-Type: text/plain; charset="UTF-8" > > ---- On Fri, 04 Oct 2024 10:26:33 -0700 Artem Goncharov wrote --- > > This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli > so no users should be affected unless they explicitly ignored official > rules. > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > On Fri, Oct 4, 2024, 19:23 Artem Goncharov artem.goncharov(a)gmail.com> > wrote: > > Official procedure is described at > https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.… > > You know the service that you want to talk to and there is a list of > service types that the service supports. You follow the procedure to find > the one set by your cloud. > > We have been trying to standardize the use of service catalog type for > many years (I think ~7-8 years :) or maybe more), and > if we still expect/support users to use them the wrong way, then there is > no point in the whole effort on these guidelines. > In the first step, we should fix our implementation in all the > services/tools you mentioned. This is what devstack change > is trying to impose. > > -gmann > > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > On Fri, Oct 4, 2024, 19:19 Takashi Kajinami kajinamit(a)oss.nttdata.com> > wrote: > > > > > > On 10/5/24 02:03, Artem Goncharov wrote: > > > > > > > > > > > > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami kajinamit(a)oss.nttdata.com > kajinamit(a)oss.nttdata.com>> wrote: > > > > > > IMHO changing the default value now is not a good option here. If > we change the default value > > > in tempest, nova, glance (and so on, if exists) it means that > deployment would break during upgrade > > > unless users explicitly set these options to the legacy value or > update keystone endpoints to use > > > the new type. > > > This sounds like a quite breaking change which makes upgrade of > real deployments difficult. > > > > > > May I know if there is any clear downside of using 'volumev3' ? > To be honest based on the fact that > > > "volumev3" has been used as default and mentioned in docs for > very long time, I find it little valuable > > > while it has big use impact. > > > > > > > > > > > > There should be no impact at all as long as keystoneauth lib is used > which implements service/version discovery. > > > If services hard coded service type of cinder without implementing > discovery it is clearly a bug and must be fixed instead of sticking to > keeping bugs forever what we do so often. > > > > I'm not following this. Even if we use keystoneauth, we should know the > service type > > to look up the correct endpoint from the list. Or are you saying that > we can determine > > the endpoint for cinder without service_type field ? > > > > There are number of implementations which hard-code volumev3 or use the > volumev3 as default. > > > > > https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&exclu… > > > > examples: > > > https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard… > > > https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os… > > > https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volum… > > > > We may be need to make these at least configurable. > > > > > > > In addition to that a split between upgrade vs. new install should be > implemented (install docs should explicitly recommend proper usage while > existing installations may stick to their current configuration). Moreover > nothing prevents adding multiple values to the catalog and drop older ones > once all consumers are updated to follow the discovery procedure. > > > > I agree we can add multiple service types and endpoints for the same > service. However my main > > concern is that not all users may be aware of the required steps to > avoid inconsistency caused by > > such change of default behavior. > > > > I can easily imagine that users upgrade their deployment and now their > services require block-storage > > service type without noticing they should create that "new" service > type. > > > > > > > > > > > > > > On 10/5/24 01:50, Ghanshyam Mann wrote: > > > > ---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam Mann > wrote --- > > > > > ---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem Goncharov > wrote --- > > > > > > Hey Stephen > > > > > > > > > > > > On Friday, 4 October 2024 15:15:08 GMT+2 Stephen > Finucane wrote: > > > > > > > o/ > > > > > > > > > > > > > > I've proposed a series of patches to "clean up" the > service catalog that > > > > > > > DevStack creates in a deployment. Currently, DevStack > creates two endpoints > > > > > > > for Cinder: one called 'cinderv3' of type 'volumev3' > and another called > > > > > > > 'cinder' of type 'block-storage'. For example: > > > > > > > > > > > > > > { > > > > > > > "services": > > > > > > > [ > > > > > > > { > > > > > > > "name": "cinderv3", > > > > > > > "description": "Cinder Volume Service > V3", > > > > > > > "id": > "65460706a9864e71926f13042f526aeb", > > > > > > > "type": "volumev3", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb>" > > > > > > > } > > > > > > > }, > > > > > > > { > > > > > > > "name": "cinder", > > > > > > > "description": "Cinder Volume > Service", > > > > > > > "id": > "cd406a0e296d47dca1e481e992851bb2", > > > > > > > "type": "block-storage", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2>" > > > > > > > } > > > > > > > }, > > > > > > > // ... > > > > > > > ], > > > > > > > "links": > > > > > > > { > > > > > > > "next": null, > > > > > > > "self": " > http://10.0.108.50/identity/v3/services > http://10.0.108.50/identity/v3/services>", > > > > > > > "previous": null > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > They both ultimately point to the same API, the > Cinder v3 API, meaning one > > > > > > > of these endpoints is redundant. My assumption was > 'block-storage' was the > > > > > > > correct one, since that's the official service type > [1], and that 'cinder' > > > > > > > was the appropriate name since it mirrors what we use > for other services > > > > > > > (nova, neutron, keystone, glance, ...). However, > tkajinam raised the point > > > > > > > [2] that the Install Guide currently recommends use > of the 'volumev3' type > > > > > > > and that projects like Nova and Glance have an > '[cinder] catalog_info' that > > > > > > > defaults to 'volumev3'. If so, is 'block-storage' > really the official > > > > > > > service type, or is it 'volumev3'. If it is, should > we be changing the > > > > > > > Install Guide and the various config option defaults? > > > > > > > > > > > > > > > > > > > Previously we had volumev2 and volumev3. Those are both > versioned aliases to > > > > > > the block-storage as the official service type name > (that is what structure of > > > > > > the service-types-authority claims). Now there is no > volumev2 and thus the > > > > > > confusion grows. > > > > > > I suggest looking at the rendered json at [2] which > states: > > > > > > ``` > > > > > > "cinder": { > > > > > > "aliases": [ > > > > > > "volumev3", > > > > > > "volumev2", > > > > > > "volume", > > > > > > "block-store" > > > > > > ], > > > > > > "api_reference": " > https://docs.openstack.org/api-ref/block-storage/ > https://docs.openstack.org/api-ref/block-storage/>", > > > > > > "project": "cinder", > > > > > > "service_type": "block-storage" > > > > > > }, > > > > > > ``` > > > > > > > > > > > > Catalog consumption process is in detail described at > [3]. It is insanely > > > > > > complex and confusing but that is what all tools that > look at the service > > > > > > catalog do. > > > > > > > > > > > > Overall: > > > > > > - official and unique service_type of the cinder is > block-storage > > > > > > - volumev3 is an alias pointing to explicit v3 api of > block-storage > > > > > > - there was an "idea" that once a service exposing > multiple API versions (and > > > > > > those are exposed independently with version-suffixed > service types) there is an > > > > > > unversioned one pointing to the "latest" version > (therefore typically you also > > > > > > find `volume` service pointing to the v3 > > > > > > - technically install docs should stop suggesting > registering volumev3 > > > > > > including project_id suffix. This is in detail > addressed by the service catalog > > > > > > consumption procedure and in addition blosk-storage v3 > api has a series of > > > > > > APIs without project_id. Continuing appending > project_id in the service > > > > > > catalog is heavily harmful. > > > > > > - install docs may switch to registering > `block-storage` or `volume` instead > > > > > > of volumev3 and even stop pointing it to the v3 api > explicitly since version > > > > > > discovery is there to figure out all the aspects. > > > > > > > > > > With the API version changing and just to keep backward > compatibility of devstack > > > > > among tooling, we kept modifying the catalog name in this > way and ended up with more > > > > > confusion. > > > > > > > > > > I agree to make the cinder catalogue also consistent with > others and name them only > > > > > 'blosk-storage'. > > > > > > > > > > Tempest still uses 'volumev3' as the default cinder > service catalog, but that is something we > > > > > should change as first: > > > > > > > > > > - > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > > > > > > > > > > Just saw that you already proposed that. thanks ++ > > > > > > > > https://review.opendev.org/c/openstack/tempest/+/930296 > https://review.opendev.org/c/openstack/tempest/+/930296> > > > > > > > > -gmann > > > > > > > > > > > > > > -gmann > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > ------------------------------ > > Message: 4 > Date: Sat, 5 Oct 2024 02:48:13 +0900 > From: Takashi Kajinami <kajinamit(a)oss.nttdata.com> > Subject: Re: [cinder] What is the "official" name for Cinder in the > service catalog? > To: Artem Goncharov <artem.goncharov(a)gmail.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Message-ID: <e3731ee2-6ffb-4827-b03e-a0008625a8b5(a)oss.nttdata.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > OK. Thanks for the explanation. > I then probably misunderstood the impact of the change. It sounds like as > long as we use appropriate SDK > in a proper manner, we can look up the endpoint with official service type > by legacy service type and > vise versa, because of internal translation which I was not aware of. > > If that is true, I agree the change has no impact unless something too > hacky is made in services. > > On 10/5/24 02:26, Artem Goncharov wrote: > > This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli > so no users should be affected unless they explicitly ignored official > rules. > > > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > > > On Fri, Oct 4, 2024, 19:23 Artem Goncharov <artem.goncharov(a)gmail.com > <mailto:artem.goncharov@gmail.com>> wrote: > > > > Official procedure is described at > https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.… > < > https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.… > > > > > > You know the service that you want to talk to and there is a list of > service types that the service supports. You follow the procedure to find > the one set by your cloud. > > > > ---- > > typed from mobile, auto-correct typos assumed > > ---- > > > > On Fri, Oct 4, 2024, 19:19 Takashi Kajinami < > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote: > > > > > > > > On 10/5/24 02:03, Artem Goncharov wrote: > > > > > > > > > > > > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami < > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com> <mailto: > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>>> wrote: > > > > > > IMHO changing the default value now is not a good option > here. If we change the default value > > > in tempest, nova, glance (and so on, if exists) it means > that deployment would break during upgrade > > > unless users explicitly set these options to the legacy > value or update keystone endpoints to use > > > the new type. > > > This sounds like a quite breaking change which makes > upgrade of real deployments difficult. > > > > > > May I know if there is any clear downside of using > 'volumev3' ? To be honest based on the fact that > > > "volumev3" has been used as default and mentioned in docs > for very long time, I find it little valuable > > > while it has big use impact. > > > > > > > > > > > > There should be no impact at all as long as keystoneauth lib > is used which implements service/version discovery. > > > If services hard coded service type of cinder without > implementing discovery it is clearly a bug and must be fixed instead of > sticking to keeping bugs forever what we do so often. > > > > I'm not following this. Even if we use keystoneauth, we should > know the service type > > to look up the correct endpoint from the list. Or are you saying > that we can determine > > the endpoint for cinder without service_type field ? > > > > There are number of implementations which hard-code volumev3 or > use the volumev3 as default. > > > > > https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&exclu… > < > https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&exclu… > > > > > > examples: > > > https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard… > < > https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard… > > > > > https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os… > < > https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os… > > > > > https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volum… > < > https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volum… > > > > > > We may be need to make these at least configurable. > > > > > > > In addition to that a split between upgrade vs. new install > should be implemented (install docs should explicitly recommend proper > usage while existing installations may stick to their current > configuration). Moreover nothing prevents adding multiple values to the > catalog and drop older ones once all consumers are updated to follow the > discovery procedure. > > > > I agree we can add multiple service types and endpoints for the > same service. However my main > > concern is that not all users may be aware of the required steps > to avoid inconsistency caused by > > such change of default behavior. > > > > I can easily imagine that users upgrade their deployment and now > their services require block-storage > > service type without noticing they should create that "new" > service type. > > > > > > > > > > > > > > On 10/5/24 01:50, Ghanshyam Mann wrote: > > > > ---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam > Mann wrote --- > > > > > ---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem > Goncharov wrote --- > > > > > > Hey Stephen > > > > > > > > > > > > On Friday, 4 October 2024 15:15:08 GMT+2 > Stephen Finucane wrote: > > > > > > > o/ > > > > > > > > > > > > > > I've proposed a series of patches to "clean > up" the service catalog that > > > > > > > DevStack creates in a deployment. Currently, > DevStack creates two endpoints > > > > > > > for Cinder: one called 'cinderv3' of type > 'volumev3' and another called > > > > > > > 'cinder' of type 'block-storage'. For example: > > > > > > > > > > > > > > { > > > > > > > "services": > > > > > > > [ > > > > > > > { > > > > > > > "name": "cinderv3", > > > > > > > "description": "Cinder Volume > Service V3", > > > > > > > "id": > "65460706a9864e71926f13042f526aeb", > > > > > > > "type": "volumev3", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb < > http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb> > <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb > <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb > >>" > > > > > > > } > > > > > > > }, > > > > > > > { > > > > > > > "name": "cinder", > > > > > > > "description": "Cinder Volume > Service", > > > > > > > "id": > "cd406a0e296d47dca1e481e992851bb2", > > > > > > > "type": "block-storage", > > > > > > > "enabled": true, > > > > > > > "links": > > > > > > > { > > > > > > > "self": > > > > > > > " > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 < > http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2> > <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 > <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 > >>" > > > > > > > } > > > > > > > }, > > > > > > > // ... > > > > > > > ], > > > > > > > "links": > > > > > > > { > > > > > > > "next": null, > > > > > > > "self": " > http://10.0.108.50/identity/v3/services < > http://10.0.108.50/identity/v3/services> < > http://10.0.108.50/identity/v3/services < > http://10.0.108.50/identity/v3/services>>", > > > > > > > "previous": null > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > They both ultimately point to the same API, > the Cinder v3 API, meaning one > > > > > > > of these endpoints is redundant. My > assumption was 'block-storage' was the > > > > > > > correct one, since that's the official > service type [1], and that 'cinder' > > > > > > > was the appropriate name since it mirrors > what we use for other services > > > > > > > (nova, neutron, keystone, glance, ...). > However, tkajinam raised the point > > > > > > > [2] that the Install Guide currently > recommends use of the 'volumev3' type > > > > > > > and that projects like Nova and Glance have > an '[cinder] catalog_info' that > > > > > > > defaults to 'volumev3'. If so, is > 'block-storage' really the official > > > > > > > service type, or is it 'volumev3'. If it is, > should we be changing the > > > > > > > Install Guide and the various config option > defaults? > > > > > > > > > > > > > > > > > > > Previously we had volumev2 and volumev3. Those > are both versioned aliases to > > > > > > the block-storage as the official service type > name (that is what structure of > > > > > > the service-types-authority claims). Now there > is no volumev2 and thus the > > > > > > confusion grows. > > > > > > I suggest looking at the rendered json at [2] > which states: > > > > > > ``` > > > > > > "cinder": { > > > > > > "aliases": [ > > > > > > "volumev3", > > > > > > "volumev2", > > > > > > "volume", > > > > > > "block-store" > > > > > > ], > > > > > > "api_reference": " > https://docs.openstack.org/api-ref/block-storage/ < > https://docs.openstack.org/api-ref/block-storage/> < > https://docs.openstack.org/api-ref/block-storage/ < > https://docs.openstack.org/api-ref/block-storage/>>", > > > > > > "project": "cinder", > > > > > > "service_type": "block-storage" > > > > > > }, > > > > > > ``` > > > > > > > > > > > > Catalog consumption process is in detail > described at [3]. It is insanely > > > > > > complex and confusing but that is what all > tools that look at the service > > > > > > catalog do. > > > > > > > > > > > > Overall: > > > > > > - official and unique service_type of the > cinder is block-storage > > > > > > - volumev3 is an alias pointing to explicit v3 > api of block-storage > > > > > > - there was an "idea" that once a service > exposing multiple API versions (and > > > > > > those are exposed independently with > version-suffixed service types) there is an > > > > > > unversioned one pointing to the "latest" > version (therefore typically you also > > > > > > find `volume` service pointing to the v3 > > > > > > - technically install docs should stop > suggesting registering volumev3 > > > > > > including project_id suffix. This is in detail > addressed by the service catalog > > > > > > consumption procedure and in addition > blosk-storage v3 api has a series of > > > > > > APIs without project_id. Continuing appending > project_id in the service > > > > > > catalog is heavily harmful. > > > > > > - install docs may switch to registering > `block-storage` or `volume` instead > > > > > > of volumev3 and even stop pointing it to the v3 > api explicitly since version > > > > > > discovery is there to figure out all the > aspects. > > > > > > > > > > With the API version changing and just to keep > backward compatibility of devstack > > > > > among tooling, we kept modifying the catalog name > in this way and ended up with more > > > > > confusion. > > > > > > > > > > I agree to make the cinder catalogue also > consistent with others and name them only > > > > > 'blosk-storage'. > > > > > > > > > > Tempest still uses 'volumev3' as the default > cinder service catalog, but that is something we > > > > > should change as first: > > > > > > > > > > - > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > < > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee…> > < > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > < > https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee… > >> > > > > > > > > Just saw that you already proposed that. thanks ++ > > > > > > > > > https://review.opendev.org/c/openstack/tempest/+/930296 < > https://review.opendev.org/c/openstack/tempest/+/930296> < > https://review.opendev.org/c/openstack/tempest/+/930296 < > https://review.opendev.org/c/openstack/tempest/+/930296>> > > > > > > > > -gmann > > > > > > > > > > > > > > -gmann > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openstack-discuss mailing list -- openstack-discuss(a)lists.openstack.org > To unsubscribe send an email to > openstack-discuss-leave(a)lists.openstack.org > > > ------------------------------ > > End of openstack-discuss Digest, Vol 72, Issue 23 > ************************************************* >

2 1