September 2024 - openstack-discuss

Using diskimage-creator for vhd format
by Tony Lombardo 06 Sep '24

06 Sep '24

Hi all. As an example I was trying to run something like this command: sudo tox -e venv -- disk-image-create -o ubuntu-min-gold.vhd vm block-device-gpt ubuntu-minimal -t vhd However, I do get the error message that vhd-util isn't available. "vhd output format specified but no vhd-util executable found." I read the commit where this was deprecated in favor of qemu-img https://opendev.org/openstack/diskimage-builder/commit/a3e9e7f89e1059ae0929… I can't seem to get the syntax for the command to work, not sure what I am missing but any help would be greatly appreciated. QEMU emulator version 6.2.0 Diskimage-builder 3.33.1 I'm running this in WSL Ubuntu, it seems to work. I was able to create an image - just not the vhd format I need. Thanks in advance for any advice. -Tony -- Tony Lombardo Systems Administrator Division of Public Safety Access Control Department Cornell University

4 5

Struggling to rejion a node into rabbitmq cluster of Openstack-on-Ansible environment
by sudeb ghosh 06 Sep '24

06 Sep '24

Hi Team, We are operating an OpenStack environment managed by Ansible with 3 controller nodes. Openstack Version: Ussuri(21.2.1) OS: CentOS8 Recently, Controller-2 encountered a network partition with rabbitmq cluster issue that we couldn't resolve, leading us to remove it from the rabbitmq cluster and do rabbitmqctl reset. Since then, the RabbitMQ cluster node removal, We are currently unable to rejoin this node to the RabbitMQ cluster. The following error occurs when attempting to join the cluster: [Controller-2]# rabbitmqctl join_cluster rabbit@ctrl-1-rabbit-mq-container Clustering node rabbit@ctrl-2 with rabbit@ctrl-1 Error: {:failed_to_cluster_with, [:"rabbit@ctrl-3", :"rabbit@ctrl-1"], 'Mnesia could not connect to any nodes.'} We have verified that Controller-2 can communicate with other nodes in the cluster and it responds with a 'pong' for "rabbitmqctl eval 'net_adm:ping('\''rrabbit@ctrl-1'\'').'" There are no additional error logs indicating the root of the problem. We would appreciate any assistance in resolving this issue. Regards, Sudeb Ghosh 7044064878 9332034788

2 1

[all][tc][ptls] Eventlet: Python 3.13 - Attach your seatbelt
by Herve Beraud 06 Sep '24

06 Sep '24

Hi all, As Python 3.13 is close to become a reality, new concerning incompatibilities between this new CPython version and Eventlet also become a reality: - https://github.com/eventlet/eventlet/issues/964 Fedora Python maintainers proposed a patch, but for now the problem remains unsolved. Also, many people reported bugs related to incompatibility between python3.12/dnspython/eventlet/pip-system-cert. There is an example who summarize well the problem https://github.com/eventlet/eventlet/issues/957 Do you have some visibility concerning the adoption of Python 3.13 into Openstack? Turbulences ahead... -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

4 5

[release] Release countdown for week R-3, Sep 09-13
by Elõd Illés 06 Sep '24

06 Sep '24

Development Focus ----------------- The Release Candidate (RC) deadline is next Friday, September 13th, 2024. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2024.2 branch will be cut. This branch will track the 2024.2 Dalmatian release. Once stable/2024.2 has been created, the master branch will be ready to switch to 2025.1 Epoxy development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2024.2 Dalmatian plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2024.2 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2024.2 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2025.1 Epoxy) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2024.2 Dalmatian release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 13th, 2024 (R-3 week) Final RC deadline: September 26th, 2024 (R-1 week) Final 2024.2 Dalmatian release: October 2nd, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[releases][tempest] Tempest 39.1.0 release
by Rodolfo Alonso Hernandez 05 Sep '24

05 Sep '24

Hello all: Because I think I'm having some communication problems about [1], I would like to write it down in a mail. This release patch for 2024.2 is pointing to [2]. However, the requirements branch used in tempest was tagged as 2024.1. That means the tempest release for 2024.2 will use the requirements from 2024.1. There are other examples done in previous releases that support what I'm saying: * 2023.2: ** https://review.opendev.org/c/openstack/releases/+/896158 ** https://github.com/openstack/tempest/commit/3926608631111a0ec93b3c44129d0cb… * 2023.1: ** https://review.opendev.org/c/openstack/releases/+/877840 ** https://github.com/openstack/tempest/commit/7c7d0fdd67022ad48ed128c997dfcc3… BTW, despite not having the stable 2024.2 branch in "requirements", the link https://releases.openstack.org/constraints/upper/2024.2 is valid and points to master (once the stable branch is created, that will point to 2024.2). Regards. [1]https://review.opendev.org/c/openstack/releases/+/927833 [2]https://review.opendev.org/c/openstack/tempest/+/927831

2 2

[manila] Dalmatian bugsquash - Sep 9th - 10th
by Carlos Silva 05 Sep '24

05 Sep '24

Hello, Zorillas and interested stackers! We'll have the second bugsquash of the Dalmatian cycle next week. As we have agreed a couple of weeks ago, it will be a two day event (Sep 9 and 10th). We will have a kick-off meeting on Monday, 15 UTC and we will use a meetpad [1] for the meeting. We will be focusing on bugs that are in progress and try to get them delivered as part of the 2024.2 Dalmatian release. Please check the ethercalc with the list of bugs [2] and add the bug you are willing to work on over the next week if it is not there yet. I'm looking forward to it :) [1] https://meetpad.opendev.org/manila-dalmatian-m3-bugsquash [2] https://ethercalc.net/mgstvday5vq0 Regards, carloss

1 0

FIPs broken when used with tunneled router gateway networks
by Sesterhenn, Maximilian 05 Sep '24

05 Sep '24

Hey all, I am currently facing an issue with OpenStack Neutron and OVN and could need some help here. Maybe someone else is doing something similar and can report if it works for them. TLDR: FIPs are broken for us when used together with routers which use a tunneled network as router gateway network. ovn_router_indirect_snat is not used and both OVN 23.09 and 24.03 have been tested. FIPs work fine when used with an external provider network. We have deployed three OpenStack projects, let's just call the left, middle and right for simplicity. The middle project has a network with a large subnet. No special configuration here, just a big subnet which is transported by OVN through Geneve. The idea is to use this subnet as an internal transfer network between different projects / tenants, which means we connect routers with SNAT and FIP configuration. Left and right are potentially the same subnet, that's why we cannot simply route the traffic. The network is shared with "access_as_external/shared" RBAC rules with both the left and right tenant, so it can be selected as the external gateway network for routers. I'm aware that until very recently, neutron was unable to assign a chassis to routers which use gateway networks which are tunneled. Thats why we are currently running the latest neutron code from the master branch where this feature was added. Let's say we want to connect from left to right and we have a router in each project that has this large network from the middle project as the external gateway network. An instance in the right tenant has a FIP to be reachable. Another instance in the left tenant is masqueraded by the SNAT functionality of the router. The router in the left project performs SNAT and the router in the right project performs the FIP DNAT. While the instance from the left project can ping the internal and external interfaces of its local router, the FIP is not reachable. The external interface of the remote router (from the right project) can be pinged as well. When capturing packets on the underlying hosts we can see the packet going from the compute host of the left instance to one of the network nodes. SNAT happens there, DNAT is not visible, this could be due to the packet capture scenario. However, we see ARP requests coming from the external interface of the router on the right project for the FIP address. We see the same ARP requests on a second network node. To me it would make more sense if the router from the left project would ARP for the FIP address. This ARP request is not being answered. We're using enable_distributed_floating_ip / DVR, so the FIP is actually configured onto the compute node. We're not using ovn_router_indirect_snat, here are issues with that. We even tried that; it makes no difference. OVN 23.09 (tested 24.03 as well) OpenStack 2024.1 (neutron master) deployed using kolla-ansible. BR Maximilian

2 2

[charms] Proposing Brian Haley and Nicolas Bock for OpenStack Charms core
by Edward Hope-Morley 05 Sep '24

05 Sep '24

Hi everyone, I would like to propose Brian Haley and Nicolas Bock for the OpenStack Charms core development team. Both Brian and Nicolas have been members of the stable charms core team since 2023 and been hugely helpful in that role, providing insightful feedback to reviews as well as contributions of their own. Nicolas has also been a contributor to the OpenStack charms for many years and Brian is well versed in the ways of upstream OpenStack maintenance through his role as Neutron PTL so I have full confidence that they will prove valuable additions to the charms-core team. Thank you both for your contributions to the project! Regards, Ed

3 2

[Kolla] [LetsEncrypt] Internal/External/Backend Certificates
by jjjamesg＠proton.me 05 Sep '24

05 Sep '24

Hi all, another one here that can't seem to get kolla running with letsencrypt certs, just curious as to what settings are required for kolla to pull internal/external/backend certs from letsencrypt? I've looked at the docs and have tried a few settings but keep getting errors, sure i had this working last week before i tore it down ready to deploy for production and now i just cant get it to complete the deployment because of certs, only thing i can think of is i need to run kolla-ansible -i multinode certificates but i thought that was just for self made certs? Also, what are best practices for backend tls certs, self signed or using the internal cert etc?? Is it possible to use letsencrypt at all for backend? Cheers all

3 6

[neutron] OpenStack OVS DVR setup in large deployments
by frantisek.reznicek.szn＠gmail.com 05 Sep '24

05 Sep '24

Dear all, we are running several OpenStack instances in Czechia. New generation of clouds we launched are deployed OpenStack Yoga on top of k8s via openstack-helm, using Neutron OVS DVR. Very recently we noticed "wasting" public IP addresses for "network:floatingip_agent_gateway ports" as briefly discussed earlier here [1] while we were scaling number of nodes up (currently around 40, final state around 300). The linked post[1] suggests to use Service subnets and let allocate "network:floatingip_agent_gateway ports" from internal address range. The service subnets documentation page[2] comes with example where "network:floatingip_agent_gateway ports" being allocated from bogon ip range 198.51.100.0/24. I want to achieve state where no allow allocation of "network:floatingip_agent_gateway ports" is allocated from public IP range. I'd preferably stay using OVS+DVR if possible. 1] Could you possibly confirm that DVR setup will accept "network:floatingip_agent_gateway ports" being allocated from smaller network in private ipv4 class A range 10.0.0.0/8? At the moment "network:floatingip_agent_gateway ports" are the ports where all FIP trafic goes, so it is kind of surprising that private addresses can be used there. Could you elaborate more in detail on that? 2] We also use multiple physical provider network segments within one logical openstack network. Can you comment on whether Service subnets feature and multi-segment feature are compatible a can be used together? I believe service subnet for "network:floatingip_agent_gateway ports" has to be routed as segment too, is that right? 3] What steps I would need to do to start using OVS w/o DVR apart from disabling distributed routing in neutron and in neutron-ovs-agent and in L3 agent and restart? Is there any special procedure? Thanks upfront for your comments... Kind Regards, František [1] https://lists.openstack.org/pipermail/openstack-dev/2016-June/096384.html [2] https://docs.openstack.org/neutron/yoga/admin/config-service-subnets.html#e…

2 2

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 04 Sep '24

04 Sep '24

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 2

[cinder] Feature Freeze Exception Request
by Zong, Yian 04 Sep '24

04 Sep '24

Dear All, I'd like to request a feature freeze exception for dalmatian-3 milestone regarding: 907133: Dell PowerStore driver: Add Cinder active-active support | https://review.opendev.org/c/openstack/cinder/+/907133 This change adds cinder active-active support for Dell PowerStore driver and allows users to configure PowerStore backends in cinder clustered environment. Please let me know if you have any concern. Thank you! BR, Yian Internal Use - Confidential

1 0

[all][elections][ptl][tc] Conbined PTL/TC 2025.1 cycle Election Voting Kickoff
by Slawomir Kaplonski 04 Sep '24

04 Sep '24

Poll for TC elections is now open and will remain open for you to cast your vote until Sep 18, 2024 23:45 UTC. We are selecting 4 TC members. Please rank all candidates in your order of preference. You are eligible to vote in the TC election if you are a Foundation individual member[0] that also has committed to any official project team's deliverable repositories[1] over the Sep 15, 2023 00:00 UTC - Aug 28, 2024 00:00 UTC timeframe (2024.1 to 2024.2) or if you are in the list of extra-acs[2] for any official project team. If you are eligible to vote in an election, you should find your email with a link to the Condorcet Internet Voting Service (CIVS) page to cast your vote in the inbox of your Gerrit preferred email[3]. Emails should be already sent to everyone on Aug 30. If you have already voted using the CIVS link from that email, you don't need to submit your vote again now. What to do if you don't see the email and have a commit in at least one of the projects having an election: * due to a new CIVS policy, to get the email from poll supervisors, you must opt in to email communication opt in with your Gerrit email address at: https://civs1.civs.us/cgi-bin/opt_in.pl * eligible voters who opt in to email communication late can see a pending poll invitation and vote until Sep 18, 2024 23:45 UTC. * check the trash or spam folders of your Gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the project's deliverable repos[0] and email the election officials[4]. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/ Happy voting, [0] https://www.openstack.org/community/members/ [1] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [2] Look for the extra-acs element in [1] [3] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [4] https://governance.openstack.org/election/#election-officials -- Best regards Slawek Kaplonski skaplons(a)redhat.com

1 0

[cinder] Offering local storage using the device mapper clone target
by Jan Horstmann 04 Sep '24

04 Sep '24

Hello cinder team and other interested parties, I have recently started thinking about ways to offer local storage as part of the OpenStack block storage service. Naturally any solution would require to transparently migrate volumes to and with the instances they are attached to, so that the user experience of being able to access their storage from anywhere would not be degraded. Fortunately, with the device mapper clone target ([1]), a mechanism is available in the linux kernel which allows to do exactly that: Create copies of devices (even network attached ones) while allowing to immediately use the target device. I have detailed the motivation and some implications of having local storage in the block storage service in a blog post [2], which I do not want to repeat here in order to not make this mail longer than it needs to be. The blog post also outlines a way to implement a cinder driver leveraging this mechanism, which is loosely based on the way cinder migrates volumes between backends, i.e.: When a volume is going to be attached, a new volume is created on the instance's host, which is backed by a device mapper clone target with the original volume as its source; Then the volume objects are switched and a local connector is returned, which may be used immediately. Since then I went ahead and created a proof of concept cinder driver ([3]), which roughly follows what is outlined in the post (some lessons were already learned during implementation). The driver is based on the in-tree lvm driver for basic volume management and can do basic things like create/delete, attach/detach and also handles live migration and rebuilding of instances. There is nothing currently regarding snapshots and volume migrations will definitly not work as expected yet, but it should be sufficient to get a feeling for the general idea. I am currently looking for feedback on the idea and the implementation and would like to know if this is of interest to others. I am happpy to answer any questions or present this in more detail. In case anyone wants to take the driver for a spin I am going to leave some instructions on how to set up the environment in [4]. Regards, Jan [1] https://docs.kernel.org/admin-guide/device-mapper/dm-clone.html [2] https://scs.community/2024/07/12/local-block-storage-via-dm-clone/ [3] https://github.com/janhorstmann/openstack-cinder/tree/59e1808a24d112d2e8d08… [4] - Set up an OpenStack environment - Create an lvm2 volume group and run a cinder volume service on every hypervisor - Configure a new backend on every volume service with the same `volume_backend_name` Configure it like you would an lvm backend, but with `volume_driver = cinder.volume.drivers.dmclone.DMCloneVolumeDriver`, e.g.: [local-volumes] volume_driver = cinder.volume.drivers.dmclone.DMCloneVolumeDriver volume_group = local volume_backend_name = local-volumes target_helper = tgtadm target_protocol = iscsi lvm_type = default I have tested with the values above, but any target driver should work -- Jan Horstmann Senior Cloud Engineer Mail: horstmann(a)osism.tech Web: https://osism.tech OSISM GmbH Talweg 8 / 75417 Mühlacker / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Mühlacker Amtsgericht Mannheim, HRB 750852

1 1

[OSSA-2024-003] OpenStack Ironic: Unvalidated image data passed to qemu-img (CVE-2024-44082)
by Brian Rosmaita 04 Sep '24

04 Sep '24

======================================================== OSSA-2024-003: Unvalidated image data passed to qemu-img ======================================================== :Date: September 04, 2024 :CVE: CVE-2024-44082 Affects ~~~~~~~ - Ironic: <21.4.3, >=22.0.0 <23.0.2, >=23.1.0 <24.1.2, >=25.0.0 <26.0.1 - Ironic-python-agent: <9.4.2, >=9.5.0 <9.7.1, >=9.8.0 <9.11.1, >=9.12.0 <9.13.1 Description ~~~~~~~~~~~ Dan Smith and Julia Kreger of Red Hat and Jay Faulkner of G-Research noticed a vulnerability in image processing for Ironic, in which a specially crafted image could be used by an authenticated user to exploit undesired behaviors in qemu-img, including possible unauthorized access to potentially sensitive data. Mitigation ---------- The attached patches contain code allowing Ironic and the Ironic-Python-Agent (IPA) to pre-screen images before passing them to qemu-img. You should patch both of them because in some popular deployment configurations, it is possible for images to bypass the Ironic conductor for more efficient image downloads. In situations where it is not possible to patch IPA, there is a new configuration option, ``[conductor]conductor_always_validates_images``. When this option is True, all image downloads are forced to occur through the Ironic conductor, where they are validated. However, this may incur a significant performance hit; hence our recommendation to patch both Ironic and IPA. Patches are available for both Ironic and IPA for all maintained branches, namely, the Dalmatian development branch (current master) through Antelope. For these branches, ``conductor_always_validates_images`` defaults to False. For the unmaintained branches (Zed through Victoria), patches are not available for IPA due to a significant risk of regressions. For these branches, the Ironic patches set ``conductor_always_validates_images`` to True, as this is the only safe way to run Ironic with an un-patched IPA. Cached images ------------- Images in the Ironic image cache should be purged. To purge the cache, stop the Ironic conductor and remove the files in the ``[pxe]/instance_master_path`` directory on that conductor node. Supported image formats ----------------------- A new configuration option, ``[conductor]permitted_image_formats`` controls what image formats will be accepted by Ironic. By default, the allowed formats are 'raw' and 'qcow2', which are the only formats that Ironic is tested with. In previous releases, it was possible to use images of other, unsupported formats with Ironic, but this is now blocked by default due to security issues arising from the image conversion process. It is possible, though not recommended, to expand the list of permitted formats. Alternatively, users requiring the use of an image in an unsupported format can convert the image offline into a supported format before uploading the image to Glance or otherwise making the image available to Ironic. Consult the Ironic documentation for details. Warning ------- As is well-documented, the OpenStack Ironic project does not support the use of ironic-lib for non-Ironic use cases. In its normal supported context, ironic-lib assumes that images have been pre-screened before ironic-lib comes in contact with them. Thus, unsupported use of ironic-lib leaves you vulnerable to the exploit outlined in this OSSA. The Ironic project intends eventually to explicitly remove the vulnerable methods in ironic-lib, but reminds the reader that independent use of ironic-lib is not supported. Bugfix branches --------------- Patches are available for maintained bugfix branches. These patches will be merged to the maintained branches, but no new releases will be triggered from those branches. Patches ~~~~~~~ - https://review.opendev.org/927972 (2023.1/antelope(ironic)) - https://review.opendev.org/927979 (2023.1/antelope(ironic-python-agent)) - https://review.opendev.org/927970 (2023.2/bobcat(ironic)) - https://review.opendev.org/927978 (2023.2/bobcat(ironic-python-agent)) - https://review.opendev.org/927968 (2024.1/caracal(ironic)) - https://review.opendev.org/927976 (2024.1/caracal(ironic-python-agent)) - https://review.opendev.org/927965 (2024.2/dalmatian(ironic)) - https://review.opendev.org/927974 (2024.2/dalmatian(ironic-python-agent)) - https://review.opendev.org/927969 (Bugfix/24.0 (ironic)) - https://review.opendev.org/927967 (Bugfix/25.0 (ironic)) - https://review.opendev.org/927966 (Bugfix/26.0 (ironic)) - https://review.opendev.org/927983 (Bugfix/9.12 (ironic-python-agent)) - https://review.opendev.org/927981 (Bugfix/9.13 (ironic-python-agent)) - https://review.opendev.org/927984 (Bugfix/9.9 (ironic-python-agent)) - https://review.opendev.org/927982 (Unmaintained/victoria(ironic)) - https://review.opendev.org/927980 (Unmaintained/wallaby(ironic)) - https://review.opendev.org/927977 (Unmaintained/xena(ironic)) - https://review.opendev.org/927975 (Unmaintained/yoga(ironic)) - https://review.opendev.org/927973 (Unmaintained/zed(ironic)) Credits ~~~~~~~ - Dan Smith from Red Hat (CVE-2024-44082) - Jay Faulkner from G-Research (CVE-2024-44082) - Julia Kreger from Red Hat (CVE-2024-44082) References ~~~~~~~~~~ - https://launchpad.net/bugs/2071740 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-44082 Notes ~~~~~ - For more information about the unadvisability of calling 'qemu-img info' on untrusted images, see CVE-2024-04467. - The ironic unmaintained/* branches will receive no point releases, but patches for them are provided as a courtesy. - The ironic-python-agent unmaintained/* branches will receive no point releases, nor are patches for them available. - The ironic and ironic-python-agent bugfix/* branches will receive no point releases, but patches for them are provided as a courtesy. -- Brian Rosmaita OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

[keystoneauth] OpenID Connect support for Onelogin broke Okta
by Pavlo Shchelokovskyy 04 Sep '24

04 Sep '24

Hi all, I'd like to bring your attention and discuss the following bug https://bugs.launchpad.net/keystoneauth/+bug/2078437 When onboarding Caracal release internally, we've noticed a regression in keystoneauth, namely that openstack CLI using v3OidcPassword auth no longer works with Okta provider. Okta returns the following error: HTTP 401 {"error":"invalid_request","error_description":"Cannot supply multiple client credentials. Use one of the following: credentials in the Authorization header, credentials in the post body, or a client_assertion in the post body." It looks like this is the aftermath of the following patch https://review.opendev.org/c/openstack/keystoneauth/+/881969 that presumably aimed to fix the Onelogin provider. I've prepared a patch that should fix both my Okta use case and, to my understanding, also address the original Onelogin concern, but I do not obviously have the use case and Onelogin access the original author of the patch had, and also it seems the author has changed jobs and is no longer active in OpenStack. Maybe somebody still has such an access to try and validate the original Onelogin use case using my patch? Or at least validate my conclusions I've outlined in the bug comments on why this should work and satisfy both cases: https://review.opendev.org/c/openstack/keystoneauth/+/927581 CC Graeme Moss who has ported that original Onelogin patch to Antelope and Zed and thus might have some additional perspective. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

1 0

[largescale-sig] Next meeting: August 21, 9utc
by Thierry Carrez 04 Sep '24

04 Sep '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240821T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 2

Subject: Best Deployment Method for Large-Scale Production OpenStack
by Thamanna Farhath 04 Sep '24

04 Sep '24

Hello OpenStack Community, We are preparing for a large-scale OpenStack deployment in production and currently use Kolla Ansible. Before proceeding, we want to know if Kolla Ansible is the best choice for production or if there are better alternatives for large-scale deployments. Any recommendations or insights on the best deployment methods for production environments would be greatly appreciated. Thank you! Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 3

[neutron] "eventlet" deprecation status
by Rodolfo Alonso Hernandez 03 Sep '24

03 Sep '24

Hello Neutrinos: During the last week we have started the "journey" to deprecate "eventlet" in Neutron and the stadium projects. We have two fronts to deal with: the Neutron API and the Neutron agents. The Neutron agents are spawned using "oslo.service" ``ServiceLauncher``, based on "eventlet". It is first needed the deprecation of "eventlet" in this project. The Neutron API was still using, by default, the "eventlet" server. The migration to the WSGI module, to the detriment of the "eventlet" implementation, was required. Most of the main project APIs have already migrated. The Neutron API using ML2/OVS was already migrated to WSGI but it was not fully functional. The periodic workers were not running, at least when spawned with devstack: * https://review.opendev.org/c/openstack/devstack/+/922125 It was also noticeable the instability of some ML2/OVS tempest CI jobs. That was caused by the RPC event handler implementation in the Neutron API: * https://review.opendev.org/c/openstack/neutron/+/926922 The Neutron API using ML2/OVN was not working at all. It was first needed to refactor the way to initialize the OVN plugin: * https://review.opendev.org/c/openstack/neutron/+/922470 ML2/OVN was also missing the maintenance worker, that was not running when using WSGI: * https://review.opendev.org/c/openstack/devstack/+/922611 * https://review.opendev.org/c/openstack/neutron/+/922074 With ML2/OVN, that usually doesn't need RPC communication, was a problem with the RPC worker (my bad for so many iterations...): * https://review.opendev.org/c/openstack/devstack/+/924473 * https://review.opendev.org/c/openstack/devstack/+/924693 * https://review.opendev.org/c/openstack/devstack/+/925412 The TLS CI job running with ML2/OVN was failing too: * https://review.opendev.org/c/openstack/neutron/+/925376/ The next steps: * To test the Neutron API using ML2/OVN (that doesn't use oslo.messaging for RPC) without any "eventlet" call (at least not calling the monkey patch method). That will be a POC patch only, but enough for testing. * Once we have new versions of the oslo libraries, we'll start with the deprecation in the agents. Regards.

1 0

[all][rbac][tacker][horizon][neutron][octavia] oslo.policy 4.4.0 enable the RBAC new defaults by default
by Ghanshyam Mann 03 Sep '24

03 Sep '24

Hi All, You might have seen some fixes and testing changes on your project to test the oslo.policy 4.4.0. oslo.policy 4.4.0 enables the RBAC new defaults by default, which means those will be enabled for all the OpenStack services unless they have disabled them by overriding the default value. It enables both enforce_scope as well enforce_new_defaults. The requirement change[1] adds the oslo.policy 4.4.0 in upper-constraints which will enable the latest oslo.policy in upstream CI. Along with jobs failing on requirement change, I tested more integration jobs and fixing the failures[2]. Most of the fixes have been merged, and a few of them are up for review. Below is the list of fixes up for review, please merge them before the requirement change is merged. If there is something else I missed to test and failed, let me know on IRC or here. In-progress fixes: - Horizon: - https://review.opendev.org/c/openstack/horizon/+/927571 - Tacker: - https://review.opendev.org/c/openstack/tacker/+/926089/5 - Neutron + Designates job (making it non-voting until we figure out the root cause): - https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/927648 - Octavia (Michael is working on more modifications on this ): - https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/926867 [1] https://review.opendev.org/c/openstack/requirements/+/925464 [2] https://review.opendev.org/q/topic:%22secure-rbac%22+owner:gmann@ghanshyamm… -gmann

2 4

[horizon] SCSS compilers
by Radomir Dopieralski 03 Sep '24

03 Sep '24

The openstack dashboard uses scss for styling, and so far we have used a python scss library for compiling those files to css for use in the browser. However, that library (pyscss) had in recent years some problems, and is not developed or supported by the authors anymore. So it's time to switch to something with a better support. The django-compressor plugin that we use for handling the compilation of files allows us to use any command-line tool to do the compilation, so we can switch to an scss compiler that is supported and used by the wider community. However, there are several options we can choose from: sassc python-libsass pysassc ruby-sass ruby-sassc node-node-sass Each of those would introduce a non-python dependency on the dashboard. The question for the packagers and distro maintainer is which of those tools would be preferable in terms of support, packaging, and maintenance for the long term? Do you have opinions? Maybe there is another tool that would be even better that I didn't find?

2 2

[ops][kolla][kolla-ansible] Lets Encrypt Deployment on 2024.1/v18
by Forrest Fuqua 03 Sep '24

03 Sep '24

The documentation seems a little incomplete when it comes to deploying a stack with let's encrypt The attached config is after trying a few settings, but the lets encrypt container errors out every time during deployment causing haproxy to not get a proper ssl certificate the services.d entries are showing its ignoring kolla_internal_fqdn_cert and still using kolla_internal.pem in most services causing the following deployment error TASK [service-ks-register : keystone | Creating services] **************************************************************************************************************************************************** FAILED - RETRYING: [100.70.0.1]: keystone | Creating services (5 retries left). FAILED - RETRYING: [100.70.0.1]: keystone | Creating services (4 retries left). FAILED - RETRYING: [100.70.0.1]: keystone | Creating services (3 retries left). FAILED - RETRYING: [100.70.0.1]: keystone | Creating services (2 retries left). FAILED - RETRYING: [100.70.0.1]: keystone | Creating services (1 retries left). failed: [100.70.0.1] (item=keystone (identity)) => {"action": "os_keystone_service", "ansible_loop_var": "item", "attempts": 5, "changed": false, "item": {"description": "Openstack Identity Service", "endpoints": [{"interface": "internal", "url": "https://openstack.cyberrange.rit.edu:5000"}, {"interface": "public", "url": "https://openstack.cyberrange.rit.edu:5000"}], "name": "keystone", "type": "identity"}, "module_stderr": "Failed to discover available identity versions when contacting https://openstack.cyberrange.rit.edu:5000. Attempting to parse version from URL.\nTraceback (most recent call last):\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/connectionpool.py\", line 715, in urlopen\n httplib_response = self._make_request(\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/connectionpool.py\", line 404, in _make_request\n self._validate_conn(conn)\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/connectionpool.py\", line 1058, in _validate_conn\n conn.connect()\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/connection.py\", line 419, in connect\n self.sock = ssl_wrap_socket(\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/util/ssl_.py\", line 449, in ssl_wrap_socket\n ssl_sock = _ssl_wrap_socket_impl(\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/util/ssl_.py\", line 493, in _ssl_wrap_socket_impl\n return ssl_context.wrap_socket(sock, server_hostname=server_hostname)\n File \"/usr/lib/python3.10/ssl.py\", line 513, in wrap_socket\n return self.sslsocket_class._create(\n File \"/usr/lib/python3.10/ssl.py\", line 1100, in _create\n self.do_handshake()\n File \"/usr/lib/python3.10/ssl.py\", line 1371, in do_handshake\n self._sslobj.do_handshake()\nssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1007)\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File \"/opt/ansible/lib/python3.10/site-packages/requests/adapters.py\", line 486, in send\n resp = conn.urlopen(\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/connectionpool.py\", line 799, in urlopen\n retries = retries.increment(\n File \"/opt/ansible/lib/python3.10/site-packages/urllib3/util/retry.py\", line 592, in increment\n raise MaxRetryError(_pool, url, error or ResponseError(cause))\nurllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='openstack.cyberrange.rit.edu', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1007)')))\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/session.py\", line 1021, in _send_request\n resp = self.session.request(method, url, **kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/requests/sessions.py\", line 589, in request\n resp = self.send(prep, **send_kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/requests/sessions.py\", line 703, in send\n r = adapter.send(request, **kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/requests/adapters.py\", line 517, in send\n raise SSLError(e, request=request)\nrequests.exceptions.SSLError: HTTPSConnectionPool(host='openstack.cyberrange.rit.edu', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1007)')))\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/generic/base.py\", line 133, in _do_create_plugin\n disc = self.get_discovery(session,\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/base.py\", line 605, in get_discovery\n return discover.get_discovery(session=session, url=url,\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/discover.py\", line 1459, in get_discovery\n disc = Discover(session, url, authenticated=authenticated)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/discover.py\", line 539, in __init__\n self._data = get_version_data(session, url,\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/discover.py\", line 106, in get_version_data\n resp = session.get(url, headers=headers, authenticated=authenticated)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/session.py\", line 1154, in get\n return self.request(url, 'GET', **kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/session.py\", line 930, in request\n resp = send(**kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/session.py\", line 1025, in _send_request\n raise exceptions.SSLError(msg)\nkeystoneauth1.exceptions.connection.SSLError: SSL exception connecting to https://openstack.cyberrange.rit.edu:5000: HTTPSConnectionPool(host='openstack.cyberrange.rit.edu', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1007)')))\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File \"/tmp/ansible-tmp-1720019606.1431425-10481-181523778594420/AnsiballZ_catalog_service.py\", line 107, in <module>\n _ansiballz_main()\n File \"/tmp/ansible-tmp-1720019606.1431425-10481-181523778594420/AnsiballZ_catalog_service.py\", line 99, in _ansiballz_main\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\n File \"/tmp/ansible-tmp-1720019606.1431425-10481-181523778594420/AnsiballZ_catalog_service.py\", line 47, in invoke_module\n runpy.run_module(mod_name='ansible_collections.openstack.cloud.plugins.modules.catalog_service', init_globals=dict(_module_fqn='ansible_collections.openstack.cloud.plugins.modules.catalog_service', _modlib_path=modlib_path),\n File \"/usr/lib/python3.10/runpy.py\", line 224, in run_module\n return _run_module_code(code, init_globals, run_name, mod_spec)\n File \"/usr/lib/python3.10/runpy.py\", line 96, in _run_module_code\n _run_code(code, mod_globals, init_globals,\n File \"/usr/lib/python3.10/runpy.py\", line 86, in _run_code\n exec(code, run_globals)\n File \"/tmp/ansible_os_keystone_service_payload_m68qs7ok/ansible_os_keystone_service_payload.zip/ansible_collections/openstack/cloud/plugins/modules/catalog_service.py\", line 211, in <module>\n File \"/tmp/ansible_os_keystone_service_payload_m68qs7ok/ansible_os_keystone_service_payload.zip/ansible_collections/openstack/cloud/plugins/modules/catalog_service.py\", line 207, in main\n File \"/tmp/ansible_os_keystone_service_payload_m68qs7ok/ansible_os_keystone_service_payload.zip/ansible_collections/openstack/cloud/plugins/module_utils/openstack.py\", line 415, in __call__\n File \"/tmp/ansible_os_keystone_service_payload_m68qs7ok/ansible_os_keystone_service_payload.zip/ansible_collections/openstack/cloud/plugins/modules/catalog_service.py\", line 113, in run\n File \"/tmp/ansible_os_keystone_service_payload_m68qs7ok/ansible_os_keystone_service_payload.zip/ansible_collections/openstack/cloud/plugins/modules/catalog_service.py\", line 175, in _find\n File \"/opt/ansible/lib/python3.10/site-packages/openstack/service_description.py\", line 89, in __get__\n proxy = self._make_proxy(instance)\n File \"/opt/ansible/lib/python3.10/site-packages/openstack/service_description.py\", line 289, in _make_proxy\n found_version = temp_adapter.get_api_major_version()\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/adapter.py\", line 352, in get_api_major_version\n return self.session.get_api_major_version(auth or self.auth, **kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/session.py\", line 1289, in get_api_major_version\n return auth.get_api_major_version(self, **kwargs)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/base.py\", line 497, in get_api_major_version\n data = get_endpoint_data(discover_versions=discover_versions)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/base.py\", line 268, in get_endpoint_data\n service_catalog = self.get_access(session).service_catalog\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/base.py\", line 131, in get_access\n self.auth_ref = self.get_auth_ref(session)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/generic/base.py\", line 203, in get_auth_ref\n self._plugin = self._do_create_plugin(session)\n File \"/opt/ansible/lib/python3.10/site-packages/keystoneauth1/identity/generic/base.py\", line 155, in _do_create_plugin\n raise exceptions.DiscoveryFailure(\nkeystoneauth1.exceptions.discovery.DiscoveryFailure: Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. SSL exception connecting to https://openstack.cyberrange.rit.edu:5000: HTTPSConnectionPool(host='openstack.cyberrange.rit.edu', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1007)')))\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1} #config excerpts from globals.yml kolla_base_distro: "ubuntu" kolla_internal_vip_address: "100.70.0.20" # /etc/hosts updated on all hosts to have openstack.cyberrange.rit.edu point to the internal IP kolla_internal_fqdn: "openstack.cyberrange.rit.edu" kolla_external_vip_address: "129.21.246.130" kolla_external_fqdn: "openstack.cyberrange.rit.edu" kolla_enable_tls_internal: "yes" kolla_enable_tls_external: "yes" kolla_certificates_dir: "/etc/kolla/certificates" kolla_external_fqdn_cert: "{{ kolla_certificates_dir }}/haproxy.pem" kolla_internal_fqdn_cert: "{{ kolla_certificates_dir }}/haproxy.pem" #kolla_admin_openrc_cacert: "" kolla_copy_ca_into_containers: "yes" haproxy_backend_cacert: "{{ 'ca-certificates.crt' if kolla_base_distro in ['debian', 'ubuntu'] else 'ca-bundle.trust.crt' }}" haproxy_backend_cacert_dir: "/etc/ssl/certs" letsencrypt_email: "fffics(a)rit.edu" enable_letsencrypt: yes letsencrypt_cert_server: "https://acme-v02.api.letsencrypt.org/directory" # attempt to renew Let's Encrypt certificate every 12 hours letsencrypt_cron_renew_schedule: "0 */12 * * *"

3 2

Best Deployment Method for Large-Scale Production OpenStack
by Thamanna Farhath 03 Sep '24

03 Sep '24

Hello OpenStack Community, We are preparing for a large-scale OpenStack deployment in production and currently use Kolla Ansible. Before proceeding, we want to know if Kolla Ansible is the best choice for production or if there are better alternatives for large-scale deployments. Any recommendations or insights on the best deployment methods for production environments would be greatly appreciated. Thank you! Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

2 1

[release][PTLs] 2024.2 / Dalmatian Cycle Highlights
by Elõd Illés 03 Sep '24

03 Sep '24

Hi, This is a reminder, that *this week* is the week for Cycle highlights [1][2]! They need to be added to deliverable yamls so that they can be included in release marketing preparations. (See the details about how to add them at the project team guide [3]) [1] https://releases.openstack.org/dalmatian/schedule.html [2] https://releases.openstack.org/dalmatian/schedule.html#d-cycle-highlights [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle… Thanks, Előd Illés irc: elodilles @ #openstack-release

1 0

[openstack-ansible] ussuri to victoria major upgrade
by Ram Ram 03 Sep '24

03 Sep '24

Hi Team I am planning openstack-ansible major upgrade from current version Ussuri to next sequential version Victoria. I am checking below link for the same. https://docs.openstack.org/openstack-ansible/victoria/admin/upgrades/major-… And I need support regarding below points: 1. What are the pre-requisite backups to be taken before the upgrade? 2. What is the impact of the upgrade , are all openstack services upgraded parallel or one by one. Example: there are 3 control nodes having each openstack control service lxc container (neutron, nova-api, cinder) running, so at a time one service of openstack is upgraded on each control node example nova (control-1)--->nova(control02)--->nova(control03) or all together. 3. What is the downtime expected in this upgrade? 4. How are openstack services upgraded on the compute nodes? What is the impact on VM running on the compute node that is being upgraded? 5. Any suggestion or experience which can be helpful for the upgrade. 6. What should be the rollback plan in case some issue occurs? Regards Rambo

2 1