- openstack-discuss - lists.openstack.org

[manila] Feature freeze exceptions
by Carlos Silva 31 Aug '24

31 Aug '24

Hello, Zorillas! This is feature freeze week and we managed to get a lot done, but during this week's IRC meeting we talked about the features we are working on, and would likely need a couple more days to be merged. They are: [1] NetApp SnapLock support This feature will allow users to create WORM shares and OpenStack operators to configure retention policy for the manila shares while using the NetApp ONTAP driver. This is a feature targeting a single driver. [2] [NetApp] Custom storage efficiency policy support for Manila share This feature is also constrained to the NetApp ONTAP driver. It will allow configuring custom efficiency policies using Manila. The change is not very numerous in terms of lines of code and has received some reviews. The author needs some more time to hash out some implementation details. [3] Export Location Metadata This is a feature that introduces the possibility of adding metadata to export locations. The generic metadata mechanism is being used, and it is thoroughly tested in manila-tempest-plugin. This change has received reviews and the author has been responsive. The author needs some time to figure out some unit test failures. [4] Ensure shares API An API change that will allow OpenStack operators to start the process that recalculates the export location of their shares, which is currently only done during the service restart. Reviews have been provided, but we would also like some more time for some more testing and more reviews. [5] Add json and yaml formatting to manila-manage This is an RFE. Doesn't introduce any APIs, and will allow OpenStack operators to specify the output format in the `manila-manage service list` command, which is useful for automations consuming this feature. I would like to grant a feature freeze exception for the three features mentioned and they should be merged by next Thursday (September 5th). [1] https://review.opendev.org/c/openstack/manila/+/926049 [2] https://review.opendev.org/c/openstack/manila/+/925079 [3] https://review.opendev.org/q/topic:%22bp/metadata-for-share-resources%22+st… [4] https://review.opendev.org/c/openstack/manila/+/924279 [5] https://review.opendev.org/c/openstack/manila/+/899295 Thank you, carloss

1 0

[Ironic] [Kolla Ansible] [Yoga] Redfish Drive
by Ali Hussain 31 Aug '24

31 Aug '24

Hello Everyone, We are having issue deploying Ironic baremental image to compute using Ironic(Yoga). The Baremetal machine is enrolled using Redfish driver. It goes to Available state as well. Once we attempt to deploy it the following exception is thrown. Error: Detected change in error condition on node “BMNode1”. Deploy step deploy.deploy failed: Redfish exception occurred. Error: Setting boot mode to uefi failed for node <UUID>. Error: HTTP PATCH http://IP/redfish/v1/Systems/1 returned code 400. Base.v1_10_3.GeneralError: The service detected a malformed request body that it was unable to interpret. Extended information: [{'MessageId': 'Base.1.10.*UnrecognizedRequestBody*', 'Severity': 'Warning', 'Resolution': 'Correct the request body and resubmit the request if it failed.', 'Message': 'The service detected a malformed request body that it was unable to interpret.', 'MessageArgs': [''], 'RelatedProperties': ['']}]. This is issue with Ironic used with Kolla Ansible but if we try with Bifrost the image booting goes fine. Any help or suggestion would be helpful to us. Best regards, Ali Hussain

2 3

[elections][tc] Question for Candidates: Availability
by Jay Faulkner 31 Aug '24

31 Aug '24

Hello all, First of all, I'm incredibly happy that the community has stepped up and provided us the opportunity to avoid any issues at all around company affiliations this cycle. Thank you to all the new folks who have run for the TC and helped with this. My two questions are simple: How much of your workweek is spent focused on upstream OpenStack? How much of that time will be available to use for TC-related activities? Thanks, Jay Faulkner

5 4

[release] Release countdown for week R-4, Sep 02-06
by Elõd Illés 31 Aug '24

31 Aug '24

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2024.2 Dalmatian deliverables can be proposed, well ahead of the final 2024.2 Dalmatian release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2024.2 Dalmatian release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2024.2 Dalmatian, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2024.2 Dalmatian that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By September 26th, 2024 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2024.2 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2024.2 Dalmatian changes should be added there to make sure the consumers of your release notes see them. 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 OpenInfra Summit Asia: September 3-4, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[all][elections][ptl][tc] Opt in to CIVS voting system
by Sławek Kapłoński 30 Aug '24

30 Aug '24

Hi, The election uses the Condorcet Internet Voting Service (CIVS). Due to CIVS policy, to vote in private CIVS polls, you must opt in to email communication. To opt in, please enter your Gerrit email address in the following page before the start of the election Sep 04, 2024 23:45 UTC, and confirm with the code that will sent to you via email. https://civs1.civs.us/cgi-bin/opt_in.pl If you have any question, please contact the election officials. https://governance.openstack.org/election/#election-officials -- Slawek Kaplonski Principal Software Engineer Red Hat

3 2

kolla openstack and ceph cephadm compatible?
by William Muriithi 30 Aug '24

30 Aug '24

Hello, I am faced with an issue where I can't run kolla-ansible prechecks against one of the system and the only thing unique about this system is that its the one I used to bootstrap ceph, hence have cephadm installed. It makes me assume that the two might be incompatible. Ceph is using a system account called cephuser and kolla is using an system account called kolla, so I am lost why they are stumping on each other. Granted, both have full sudo, so that could be the route where this mess came up. The three systems are both execution machine and storage machine. When I initially set it up, I made assumptions that cinder was part of the core service. I then struggled to bring up the virtual machine and its while debugging this issue that I realized I need cinder. Fine, I enabled cinder on /etc/kolla/globals.d/cinder.yml as documented, but now I can't run prechecks. This was failing only on cinder. When I run deploy, now its failing on glance too. Have anyone noticed something similar? Can it be fixed without reinstalling all the systems? This is the error I am seeing:- The full traceback is: Traceback (most recent call last): File "/var/lib/kolla/.ansible/tmp/ansible-tmp-1724965733.8092885-882811-135535224643810/AnsiballZ_kolla_container_facts.py", line 107, in <module> _ansiballz_main() File "/var/lib/kolla/.ansible/tmp/ansible-tmp-1724965733.8092885-882811-135535224643810/AnsiballZ_kolla_container_facts.py", line 99, in _ansiballz_main invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS) File "/var/lib/kolla/.ansible/tmp/ansible-tmp-1724965733.8092885-882811-135535224643810/AnsiballZ_kolla_container_facts.py", line 47, in invoke_module runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=dict(_module_fqn='ansible.modules.kolla_container_facts', _modlib_path=modlib_path), File "/usr/lib64/python3.9/runpy.py", line 225, in run_module return _run_module_code(code, init_globals, run_name, mod_spec) File "/usr/lib64/python3.9/runpy.py", line 97, in _run_module_code _run_code(code, mod_globals, init_globals, File "/usr/lib64/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/tmp/ansible_kolla_container_facts_payload_msvskycx/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py", line 132, in <module> File "/tmp/ansible_kolla_container_facts_payload_msvskycx/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py", line 124, in main File "/tmp/ansible_kolla_container_facts_payload_msvskycx/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py", line 105, in use_podman File "/usr/local/lib/python3.9/site-packages/podman/domain/manager.py", line 68, in reload latest = self.manager.get(self.id) File "/usr/local/lib/python3.9/site-packages/podman/domain/containers_manager.py", line 44, in get response.raise_for_status() File "/usr/local/lib/python3.9/site-packages/podman/api/client.py", line 75, in raise_for_status raise APIError(cause, response=self._response, explanation=message) podman.errors.exceptions.APIError: 500 Server Error: Internal Server Error (getting container from store "1127b70a453e15c7b5e2ba8da307f8b17791e6a23fb2b2e94a4d5dd5fce59907": container not known) fatal: [ostack-49.openstack.example.com] FAILED! => { "changed": false, "module_stderr": "OpenSSH_8.7p1, OpenSSL 3.0.7 1 Nov 2022\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug3: /etc/ssh/ssh_config line 55: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0\r\ndebug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf\r\ndebug2: checking match for 'final all' host ostack-49.openstack.example.com originally ostack-49.openstack.example.com\r\ndebug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: not matched 'final'\r\ndebug2: match not found\r\ndebug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)\r\ndebug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config\r\ndebug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]\r\ndebug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]\r\ndebug1: configuration requests final Match pass\r\ndebug1: re-parsing configuration\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug3: /etc/ssh/ssh_config line 55: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0\r\ndebug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf\r\ndebug2: checking match for 'final all' host ostack-49.openstack.example.com originally ostack-49.openstack.example.com\r\ndebug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: matched 'final'\r\ndebug2: match found\r\ndebug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1\r\ndebug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config\r\ndebug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]\r\ndebug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]\r\ndebug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/var/lib/kolla/.ssh/known_hosts'\r\ndebug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/var/lib/kolla/.ssh/known_hosts2'\r\ndebug1: auto-mux: Trying existing master\r\ndebug2: fd 3 setting O_NONBLOCK\r\ndebug2: mux_client_hello_exchange: master version 4\r\ndebug3: mux_client_forwards: request forwardings: 0 local, 0 remote\r\ndebug3: mux_client_request_session: entering\r\ndebug3: mux_client_request_alive: entering\r\ndebug3: mux_client_request_alive: done pid = 881450\r\ndebug3: mux_client_request_session: session request sent\r\ndebug1: mux_client_request_session: master session id: 2\r\ndebug3: mux_client_read_packet: read header failed: Broken pipe\r\ndebug2: Received exit status from master 1\r\nShared connection to ostack-49.openstack.example.com closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n File \"/var/lib/kolla/.ansible/tmp/ansible-tmp-1724965733.8092885-882811-135535224643810/AnsiballZ_kolla_container_facts.py\", line 107, in <module>\r\n _ansiballz_main()\r\n File \"/var/lib/kolla/.ansible/tmp/ansible-tmp-1724965733.8092885-882811-135535224643810/AnsiballZ_kolla_container_facts.py\", line 99, in _ansiballz_main\r\n invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)\r\n File \"/var/lib/kolla/.ansible/tmp/ansible-tmp-1724965733.8092885-882811-135535224643810/AnsiballZ_kolla_container_facts.py\", line 47, in invoke_module\r\n runpy.run_module(mod_name='ansible.modules.kolla_container_facts', init_globals=dict(_module_fqn='ansible.modules.kolla_container_facts', _modlib_path=modlib_path),\r\n File \"/usr/lib64/python3.9/runpy.py\", line 225, in run_module\r\n return _run_module_code(code, init_globals, run_name, mod_spec)\r\n File \"/usr/lib64/python3.9/runpy.py\", line 97, in _run_module_code\r\n _run_code(code, mod_globals, init_globals,\r\n File \"/usr/lib64/python3.9/runpy.py\", line 87, in _run_code\r\n exec(code, run_globals)\r\n File \"/tmp/ansible_kolla_container_facts_payload_msvskycx/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 132, in <module>\r\n File \"/tmp/ansible_kolla_container_facts_payload_msvskycx/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 124, in main\r\n File \"/tmp/ansible_kolla_container_facts_payload_msvskycx/ansible_kolla_container_facts_payload.zip/ansible/modules/kolla_container_facts.py\", line 105, in use_podman\r\n File \"/usr/local/lib/python3.9/site-packages/podman/domain/manager.py\", line 68, in reload\r\n latest = self.manager.get(self.id)\r\n File \"/usr/local/lib/python3.9/site-packages/podman/domain/containers_manager.py\", line 44, in get\r\n response.raise_for_status()\r\n File \"/usr/local/lib/python3.9/site-packages/podman/api/client.py\", line 75, in raise_for_status\r\n raise APIError(cause, response=self._response, explanation=message)\r\npodman.errors.exceptions.APIError: 500 Server Error: Internal Server Error (getting container from store \"1127b70a453e15c7b5e2ba8da307f8b17791e6a23fb2b2e94a4d5dd5fce59907\": container not known)\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1 } Regards, William

1 0

PTG October 2024 Team Signup
by Kendall Nelson 30 Aug '24

30 Aug '24

Hello Everyone, Hopefully you have seen by now, the next OpenInfra PTG[1] which will take place October 21-25, 2024 virtually! Registration is now open[2]! To sign up your team, you must complete the survey[3] by August 30th at 7:00 UTC. We NEED accurate contact information (email and IRC nickname ideally) for the moderator of your team’s sessions. This is because the survey information will be used to organize the schedule signups which will be done via the PTGBot. If you are not on IRC, please get setup[4] on the OFTC network and join #openinfra-events. You are also encouraged to familiarize yourself with the PTGBot documentation[5] as well. If you have any questions, please reach out to ptg(a)openinfra.dev! Information about signing up for time slots will be sent to moderators after the team signup deadline. Continue to visit openinfra.dev/ptg for updates. -Kendall (diablo_rojo) [1] PTG Site: https://openinfra.dev/ptg/ [2] PTG Registration: http://ptg.openinfra.dev/ [3] Team Survey: https://openinfrafoundation.formstack.com/forms/oct2024_ptg_survey [4] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [5] PTGBot README: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst

1 2

[all][elections][tc] TC Election Campaigning Kickoff
by Ian Y. Choi 29 Aug '24

29 Aug '24

Developers, The TC Election Campaigning Period has now started[1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms[2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform[2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. [1] https://governance.openstack.org/election/ [2] https://opendev.org/openstack/election/src/branch/master/candidates/2025.1/…

1 0

[publiccloud-sig] Cancelling next weeks meeting - Sept 4th
by Felix Kronlage-Dammers 29 Aug '24

29 Aug '24

Hi, a lot of the frequent participants of the publiccloud-sig are going to be travelling next wednesday. As such, Tobias and I decided that we will skip the call next week. Next regular call will then be on September 18th. felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[swift] Sync rings automatically
by Mark Kirkwood 29 Aug '24

29 Aug '24

The familiar process for ring modification is: 1/ Create or amend corresponding builder file 2/ Rebalance it 3/ (R)sync the newly modified ring to all hosts in the cluster Recently I was wondering about removing the need for 3/. A very simple minded approach would be to make a cron job on each host to periodically rsync from one of the proxies (designated as the 'master' where we modify rings).. However, I then decided that it would be nicer to make a new Swift daemon and add it to the code. I have coded this up (I'm looking at adding a patch to Swift's Gerrit but thought I'd mention it here first). the basic design is: - New daemon swift-ring-syncer - Backend code in common/ring_syncer.py - Conf file ring-syncer.conf One host is designated the authoritative source (config 'ringbuilder'). All hosts can run this daemon (including the ringbuilder), Rings will be rsync'd at a configurable interval (e.g 300s).. This is safe to do even when the rings are being modified as the current code does a temp file write plus atomic rename (If it is desired to sync the builder files too then their 'save' function would need to use this sane logic instead of writing to them directly). Does this sound like something that would be good in the main Swift code? Let me know and I'll setup Gerrit if so! Regards Mark

1 0