- openstack-discuss - lists.openstack.org

Report a potential risk of secret leakage in project(barbican)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(barbican), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, barbican. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

3 3

Report a potential risk of secret leakage in project(manila_ui)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(manila_ui), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, manila_ui. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(manila)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(manila), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, manila. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(murano)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(murano), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, murano. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(masakari)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(masakari), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, masakari. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(zun)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(zun), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, zun. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(refstack)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(refstack), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, refstack. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(castellan)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(castellan), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, castellan. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(ceilometer)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(ceilometer), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, ceilometer. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(monasca_api)
by kellanzchow＠gmail.com 13 Aug '24

13 Aug '24

Dear developers of the project(monasca_api), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, monasca_api. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

[Nova][Keystone] Instance boot fail if user has many roles
by Masahito Muroi 13 Aug '24

13 Aug '24

Hi Nova and Keystone folks, I'd like to your feedback for the bug[1] and the commit[2]. We use Keystone as company internal role management system and hit the issue frequently. The commit is to change instance_system_metadata table schema, but it could be too big change only for the long role list. Another idea I can imagine is to introduce "store_boot_roles" boolean configuration to store the boot_roles or not. IIUC, the boot_roles is used only for a specific vendor data in the metadata api. If there is another good value to store from Keystone side, I'm happy to use the value instead of role name, too. 1. https://bugs.launchpad.net/nova/+bug/2075100 2. https://review.opendev.org/c/openstack/nova/+/925163 thank you, Masahito

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-7)
by Goutham Pacha Ravi 12 Aug '24

12 Aug '24

Hello Stackers, As we count down to the final release of OpenStack's 30th version [1], it's been another busy week across our community. Over the past week, the Technical Committee has merged several governance proposals, with a focus on leadership changes in preparation for the upcoming OpenStack election season. Project teams following a Distributed Project Leadership model (DPL) [2] were required to reassert their liaisons within the past week or elect a new PTL during the upcoming elections. The nomination period for Project Team Leads (PTLs) and the OpenStack Technical Committee will begin at 23:45 UTC on August 14, 2024. If you haven't already done so, please confirm your eligibility to vote in these elections by navigating to: https://civs1.civs.us/cgi-bin/opt_in.pl We are currently vetting runtimes for the upcoming 2025.1 ("Epoxy") release [3]. Please note that this will be a Skip-Level Upgradable (SLURP) release [4], meaning upgrades are supported from the 2024.1 ("Caracal") release to the 2025.1 ("Epoxy") release and from the 2025.1 ("Epoxy") release to the 2026.1 ("G") release. This also means that a wider range of distributions and Python versions will be tested within the community for this release. === Weekly Meeting === The last Technical Committee weekly meeting was primarily held over video [5], with notes taken in IRC [6]. We discussed several topics concerning gate health, noting that the recent end-of-life transition of CentOS 8 Stream has rendered the gate unstable across the stack. Several project teams had to find suitable alternatives to keep testing older branches or specific features on this distribution. Members noted that Rocky Linux has been relatively stable and may be a viable alternative for those still seeking a replacement. The OpenDev infrastructure team has freed up space and resources to accommodate mirrors for Rocky Linux. Your help is most appreciated if you're motivated to enable this in CI. We also discussed the upcoming elections and improvements to the election tooling. Several ideas were shared to prevent situations where projects lack a PTL candidate by the end of the nomination period. You'll hear more about these in the coming weeks. The next OpenStack TC weekly meeting is today, August 13, 2024, at 18:00 UTC. It will be hosted on OFTC in the #openstack-tc channel. The agenda has been shared on the meeting wiki [7]. I hope you'll join us. === Governance Proposals === ==== Merged ==== - Update criteria for inactive projects to become active again | https://review.opendev.org/c/openstack/governance/+/921500 - Reset the DPL model for the Freezer project | https://review.opendev.org/c/openstack/governance/+/925830 - Re-initiate the DPL model for the Freezer project | https://review.opendev.org/c/openstack/governance/+/925997 - Reset the DPL model for the Watcher project | https://review.opendev.org/c/openstack/governance/+/925831 - Reset the DPL model for the Release Management project | https://review.opendev.org/c/openstack/governance/+/925832 - Add Release Management DPL and liaison names | https://review.opendev.org/c/openstack/governance/+/926055 ==== Open for Review/Discussion ==== - Opt-in to the Oslo DPL model for the 2025.1 cycle | https://review.opendev.org/c/openstack/governance/+/926154 - Reset the DPL model for the Oslo project | https://review.opendev.org/c/openstack/governance/+/925834 - Define testing runtime for the 2025.1 release | https://review.opendev.org/c/openstack/governance/+/926150 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Inactive state extensions: Monasca | https://review.opendev.org/c/openstack/governance/+/923919 - Update DPL model reset steps | https://review.opendev.org/c/openstack/governance/+/925926 === Upcoming Events === - August 14, 2024: Nominations open for 2025.1 OpenStack PTL + TC elections - August 16, 2024: Call for Proposals due for OpenInfra Days NA [8] - August 24, 2024: OpenInfra Days, Vietnam: https://2024.vietopeninfra.org/ - August 29, 2024: Dalmatian-3 milestone - September 3, 2024: OpenInfra Summit Asia, Suwon Thank you for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Distributed Project Leadership: https://governance.openstack.org/tc/reference/distributed-project-leadershi… [3] Testing runtimes for the 2025.1 release: https://review.opendev.org/c/openstack/governance/+/926150 [4] Skip-Level Upgradable releases (SLURP): https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad… [5] TC Meeting Video Recording, 2024-08-06: https://www.youtube.com/watch?v=HZhY9pxezWo [6] TC Meeting IRC Log, 2024-08-06: https://meetings.opendev.org/meetings/tc/2024/tc.2024-08-06-18.00.log.html [7] TC Meeting, 2024-08-13: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [8] CFP OpenInfra Days, NA: https://docs.google.com/forms/d/1U3TokM5QWTe9_MJvKbOiDc_cNNW_LlFpOL3t-Loib1…

1 0

Re: [legal-discuss] [Kolla] Re: LICENSE question - Openstack Masakari
by Michal Arbet 12 Aug '24

12 Aug '24

Adding openstack discuss mailing list [Kolla] On Mon, Aug 12, 2024, 22:11 <wes(a)openinfra.dev> wrote: > After consulting foundation legal counsel, this type of integration should > not be a problem from a licensing perspective as long as no BSL licensed > code is added into OpenStack code and as long as use of the HashiCorp > product remains optional. > _______________________________________________ > legal-discuss mailing list -- legal-discuss(a)lists.openstack.org > To unsubscribe send an email to legal-discuss-leave(a)lists.openstack.org >

1 0

[packing]Does the OpenStack repository break overall system compatibility
by 韩光宇 12 Aug '24

12 Aug '24

Hello, As an OpenStack operator who is also involved in packaging OpenStack, I've recently encountered some confusion regarding the packaging of OpenStack. From what I've gathered, Red Hat, SUSE, and Ubuntu package OpenStack in such a way that a single OS version can support multiple OpenStack versions. Each OpenStack version corresponds to its own separate repository (please correct me if I'm mistaken). I'm trying to understand the implications this packaging approach might have on system compatibility and maintenance. Such as, could this lead to the following scenario: The system repository has package A==1.0, The OpenStack repository has package A==2.0. After installing A==2.0 from the OpenStack repository, package B (which depends on A<=1.0) from the system repository can no longer be installed. Does this mean that the OpenStack repository breaks overall compatibility? My understanding of packaging is not very deep, so I would greatly appreciate any guidance or insights you can provide on this matter. Looking forward to your insights. Best regards, Han Guangyu

3 2

[cinder] Deadlock found when trying to get lock; try restarting transaction
by Eugen Block 12 Aug '24

12 Aug '24

Hi, in a customer cluster (Victoria, Galera cluster on 3 control nodes) we're seeing failing pipeline deployments from time to time when cinder is instructed to create multiple volumes at once. This is the error message: ---snip--- 2024-08-12 15:01:34.762 33307 WARNING oslo_db.sqlalchemy.exc_filters [req-aa5505d3-167a-4096-9311-36b10deebcc1 049f5ea05bd14c019aeab37d3cff4ffc ed22c592548e4903b9af541bb158c6fe - - -] DB exception wrapped.: sqlalchemy.exc.ResourceClosedError: This Connection is closed ... 2024-08-12 15:01:34.762 33307 ERROR oslo_db.sqlalchemy.exc_filters pymysql.err.InternalError: (1213, 'Deadlock found when trying to get lock; try restarting transaction') ... 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server File "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", line 476, in _revalidate_connection 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server raise exc.ResourceClosedError("This Connection is closed") 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server sqlalchemy.exc.DBAPIError: (sqlalchemy.exc.ResourceClosedError) This Connection is closed 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server (Background on this error at: http://sqlalche.me/e/13/dbapi) ---snip--- I found this bug [1] with a fix for Pike, so Victoria already has that fix, but the error still blocks some deployments, leaving volumes in "creating" state which has to be cleaned up manually. I can't find much else on this, am I missing something? Any pointers would be highly appreciated! Thanks! Eugen [1] https://bugs.launchpad.net/cinder/+bug/1789106

3 5

Assistance Needed with FWaaS Configuration in Kolla Ansible 2023.1
by Thamanna Farhath 12 Aug '24

12 Aug '24

Hello openstack community, I am currently working on integrating FWaaS V2 into my OpenStack deployment using Kolla Ansible 2023.1. Following the guidelines provided, I attempted to backport the changes from the following reviews: https://review.opendev.org/c/openstack/kolla-ansible/+/914854 https://review.opendev.org/c/openstack/kolla/+/914855/6 While I successfully made the necessary changes to each file in the first review, I encountered an issue with the second review. Specifically, the following files are missing from my environment: docker/horizon/extend_start.sh kolla/common/sources.py I am unsure why these files are missing and how I can resolve this issue to complete the backport process. Could you please provide guidance on how to address this problem? Any assistance or pointers would be greatly appreciated. Thanks in advance 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."

1 0

[tacker] Cancelling IRC meeting
by Yasufumi Ogawa 11 Aug '24

11 Aug '24

Hi tacker team, I'd like to skip IRC meeting this week since I'm going to be out of office for summer holidays. Thanks, Yasufumi

1 0

[neutron] Bug deputy report - week of Aug 5
by Slawek Kaplonski 11 Aug '24

11 Aug '24

Hi, I was bug deputy this week. It was a pretty quiet week. Here is a summary of the new bugs reported: *Critical* - https://bugs.launchpad.net/neutron/+bug/2076430 - rally job broken with recent keystone change and fails with ValueError: Cannot convert datetime.date(2024, 8, 7) to primitive - not assigned yet but it seems that gtema, xek and ykarel are taking care of it already *High* - https://bugs.launchpad.net/neutron/+bug/2076328 -SubnetsSearchCriteriaTest.test_list_pagination_page_reverse_with_href_links fails sporadically - *not assigned yet*, seems like intermittent gate failure, it was marked as Low by Lajos but as it is causing gate failures, I changed it to *High* - https://bugs.launchpad.net/neutron/+bug/2076405 - # neutron-fwaas stable/2023.1 periodic jobs are failing, assigned to Lajos, fix already proposed and merged https://review.opendev.org/c/openstack/neutron-fwaas/+/926047 *Low* - https://bugs.launchpad.net/neutron/+bug/2076181 - Accidentally no-allocation-pool for subnet leads to poor diagnosis of build-in dhcp service issues - *not assigned*, marked as low-hanging-fruit as the only thing which would be needed here is just improve exception message slightly *RFE* - https://bugs.launchpad.net/neutron/+bug/2076122 - dns integration: support multiple domains per instance -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[oslo] Feature freeze is apporching
by Daniel Bengtsson 09 Aug '24

09 Aug '24

Hi there, Just a friendly reminder that oslo's feature freeze[1] will happen. Oslo observes a feature freeze that is earlier than other projects. And it's coming up soon. Aug. 15th is the Oslo feature freeze date for this cycle. That leaves about one week for features to be merged in Oslo libraries. After that, any features to be merged will require a feature freeze exception, which can be requested on the list. Feel free to ping us on IRC if you need code review. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… -- Daniel Bengtsson Software Engineer

1 0

What is the expected behaviour of openstack user with reader access ?
by abitha.ramu32＠gmail.com 09 Aug '24

09 Aug '24

I have created new user with reader access, As expected it was supposed to view the resources created in openstack. but the user with reader access can create/update/modify the resource

2 1

[release] Release countdown for week R-7
by Thierry Carrez 09 Aug '24

09 Aug '24

Development Focus ----------------- We are entering the last weeks of the 2024.2 "Dalmatian" development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Next week is the Extra-AC freeze, in preparation for elections. All contributions to OpenStack are valuable, but some are not expressed as Gerrit code changes. Please list active contributors to your project team who do not have a code contribution this cycle, and therefore won't automatically be considered an Active Contributor and allowed to vote. This is done by adding extra-acs to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-AC freeze on August 15th, 2024. A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * Oslo libraries are entering feature freeze next week, August 15th, 2024. * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 22nd, 2024). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (August 29th, 2024) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, August 29th, 2024. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before the end of the RC1 target week (September 13, 2024) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (September 26, 2024) Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to one week after Feature freeze (September 5th, 2024). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… jeremy [at] openstack.org/fungi on IRC is available if you need help selecting or writing your highlights. Upcoming Deadlines & Dates -------------------------- Extra-AC freeze: August 15th, 2024 (R-7 week) Oslo feature freeze: August 15th, 2024 (R-7 week) Non-client library freeze: August 22nd, 2024 (R-6 week) Client library freeze: August 29th, 2024 (R-5 week) Dalmatian-3 milestone: August 29th, 2024 (R-5 week) Cycle highlights deadline: September 5th, 2024 (R-4 week) -- Thierry Carrez (ttx)

1 0

[Glance] Cancelling Weekly Meeting (Aug 8)
by Pranali Deore 08 Aug '24

08 Aug '24

Hello, I'm not feeling well, won't be able to chair today's meeting, so cancelling the same. See you next week! Thanks, Pranali Deore

1 0

Deployment Caracal with OVN not working (same test setup with Bobcat runs perfectly)
by Maurer Remo (murm) 07 Aug '24

07 Aug '24

Dear all I'm running multiple Openstack production clusters for years. Currently, our clusters hold approx 600 instances mainly for educational purposes. We're deploying the environment using Kolla-Ansible. Host OS Ubuntu Jammy, using the Jammy-Kolla containers. At the moment we're running Bobcat and are testing the Upgrade to Caracal (2024.1). To make the problem reproduceable I set up a one node testenvironment. Host OS: Ubuntu Jammy running on KVM. Kolla-Ansible Version: 18.1.1.dev1 Ansible-Version: 9.8.0 (ansible-core 2.16.9) Kolla config: * passwords.yml from caracal template, values filled in with kolla-genpwd * multinode from caracal template. Control, network and compute node set to the hostname of the testserver. Everything else left as is. * globals.yml from caracal template. Changes (I'm not listing the network config entries): * kolla_base_distro: "ubuntu" * neutron_plugin_agent: "ovn" Deployment runs smoothly. Post deploy tests: * "openstack compute service list", shows all services up (nova-scheduler, nova-conductor, nova-compute) * "openstack network agent list", shows all network agents up (OVN Controller Gateway agent, OVN Metadata agent) To setup network, flavors, etc, I'm running an adapted init_runonce script, creating an external (flat) and an internal (geneve) network and a router. Spinning up an instance leads to a fatal error on nova: --- Dashboard --- Error: Failed to perform requested operation on instance "test", the instance has an error status: Please try again later [Error: Build of instance 38488604-3d83-4676-b0c2-a4218696eba3 aborted: Failed to allocate the network(s), not rescheduling.]. --- --- /var/log/kolla/nova/nova-compute.log --- ... 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [None req-14f0d15f-5892-406b-a750-698ec54d9b70 ec93e00940164f30b5076a93c0a24722 499b452a194d4cbeb401302eaef1304a - - default default] [instance: 38488604-3d83-4676-b0c2-a4218696eba3] Instance failed to spawn: nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] Traceback (most recent call last): 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/libvirt/driver.py", line 8002, in _create_guest_with_network 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] with self.virtapi.wait_for_instance_event( 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/usr/lib/python3.10/contextlib.py", line 142, in __exit__ 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] next(self.gen) 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/compute/manager.py", line 559, in wait_for_instance_event 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] self._wait_for_instance_events( 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/compute/manager.py", line 471, in _wait_for_instance_events 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] actual_event = event.wait() 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/compute/manager.py", line 436, in wait 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] instance_event = self.event.wait() 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/eventlet/event.py", line 124, in wait 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] result = hub.switch() 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/eventlet/hubs/hub.py", line 310, in switch 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] return self.greenlet.switch() 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] eventlet.timeout.Timeout: 300 seconds 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] During handling of the above exception, another exception occurred: 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] Traceback (most recent call last): 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/compute/manager.py", line 2885, in _build_resources 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] yield resources 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/compute/manager.py", line 2632, in _build_and_run_instance 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] self.driver.spawn(context, instance, image_meta, 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/libvirt/driver.py", line 4642, in spawn 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] self._create_guest_with_network( 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] File "/var/lib/kolla/venv/lib/python3.10/site-packages/nova/virt/libvirt/driver.py", line 8028, in _create_guest_with_network 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] raise exception.VirtualInterfaceCreateException() 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed 2024-08-07 15:33:02.742 7 ERROR nova.compute.manager [instance: 38488604-3d83-4676-b0c2-a4218696eba3] 2024-08-07 15:33:02.753 7 INFO nova.compute.manager [None req-14f0d15f-5892-406b-a750-698ec54d9b70 ec93e00940164f30b5076a93c0a24722 499b452a194d4cbeb401302eaef1304a - - default default] [instance: 38488604-3d83-4676-b0c2-a4218696eba3] Terminating instance ... --- The same configuration works without error under Bobcat (kolla-ansible: 17.4.0, ansible: 8.4.0) When I upgrade a running Bobcat configuration to Caracal, I run into the same issue. When running the upgrade with "--skip-tags openvswitch" the upgraded environment runs perfectly (with the bobcat openvswitch containers). As soon as I upgrade those, the deployment is broken again. I clouldn't find a bug on launchpad which points to this issue. I coudn't find any info in the release notes of caracal which solves my problem. Does anyone struggling on the same issue as well? Do you have any hint? I'm appreciating any comment, help, ... Thanks Remo Maurer

2 1

[oslo][freezer][watcher][requirement][release] Resetting the DPL model liaisons
by Ghanshyam Mann 06 Aug '24

06 Aug '24

Hi, DPL projects, To keep the DPL model/liaisons up to date, TC defined the new policy to reset the DPL state/liaisons every cycle[1]. If the project wants to continue the DPL model, they can opt-in the same; otherwise, they fall into the PTL model/election process. I am resetting the DPL model for all the existing 5 DPL projects[2]. If needed, feel free to opt-in the DPL model for the next cycle. [1] https://governance.openstack.org/tc/reference/distributed-project-leadershi… [2] this series - https://review.opendev.org/c/openstack/governance/+/925834/1 -gmann

1 0

Firewall as a Service - kolla ansible 2023.1
by Thamanna Farhath 06 Aug '24

06 Aug '24

Hello OpenStack Community, I hope this message finds you well. My name is Thamanna , and I am currently working with the OpenStack Kolla-Ansible deployment version 2023.1. I am interested in deploying Firewall as a Service (FWaaS) within our OpenStack environment. However, I have noticed that FWaaS is not available in the Kolla-Ansible 2023.1 version. Could anyone please provide guidance on the following points? 1. Is there an official or recommended way to integrate FWaaS with Kolla-Ansible 2023.1? 2. Are there any specific configurations or additional components required to enable FWaaS? 3. Has anyone in the community successfully deployed FWaaS with this version, and if so, could you share your experience and any potential challenges faced? 4. Are there alternative approaches or tools that you would recommend for deploying FWaaS in an OpenStack environment? Any help or pointers to relevant documentation would be greatly appreciated. Thank you in advance for your assistance! Best regards, Thamanna mailto:thamanna.f@zybisys.com 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."

3 5