August 2024 - openstack-discuss - lists.openstack.org

[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

[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

[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

[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

Can not work on Dashboard(throwing 504-Timed out) on Openestack-on-ansible environment
by sudeb ghosh 02 Sep '24

02 Sep '24

Hi Team , We have an 'Openstack on Ansible' Private cloud environment with 3 controllers & 35 Compute host nodes. Age of this environment is around 4 yrs. DISTRIB_RELEASE: 21.2.1 DISTRIB_CODENAME: Ussuri DISTRIB_DESCRIPTION: Openstack-Ansible Top of this Linux containers are there where the services are running inside such as neutron, galera, horizon, keystone, etcd, nova-api, utility etc for all 3 controllers. Current Set Up: We find in haproxy config file only controller2 & controller3 are configured. So the galera container along with Mariadb Services are running fine within controller2(Primary) & controller3. But Galera container in controller1 is stopped & mariadb service not running here. Issue Started with: All of suddent we faced, user not able to log in dashboard 5 days back. The dashboard page is not getting loaded. Action Taken: We find Maria-DB in controller2 is non-primary & DB on controller-3 is down. Made Maria-DB in controller2 primary & DB on controller-3 up which resulted to load the page & log in. Current Issue: 1) But the Dashboard page is too slow to work. Sometime throwing 504-Timed out error 2) VM Console(VNC) not working for any VM 3) NOt able to create any VM(Showing 'Scheduling' continuously) 4) 25/35 Hypervisons are showing down in Dashboard within 'Hypervisor list' tab but those are up as per CLI 5) Not able to create any volume Request you to go through the Problem description & Can anybody help me out providing the solution for the same? Pl do intimate me if any more info is required. Regards, Sudeb Ghosh sudeb_ece(a)yahoo.co.in BR// Sudeb Ghosh 7044064878 9332034788

2 3

[nova][ci] openstack-tox-docs job failing, hold your rechecks
by melanie witt 01 Sep '24

01 Sep '24

Hey all, Just a heads up... The last several openstack-tox-docs job runs on the master branch have failed, both gate and check queues: https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-docs&pro… because of AFAICT the following warning which is treated as an error: 2024-08-28 19:24:04.604443 | ubuntu-jammy | /home/zuul/src/opendev.org/openstack/nova/.tox/docs/lib/python3.10/site-packages/openstackdocstheme/page_context.py:70: RemovedInSphinx90Warning: Sphinx 9 will drop support for representing paths as strings. Use "pathlib.Path" or "os.fspath" instead. 2024-08-28 19:24:04.649996 | ubuntu-jammy | src_file = full_src_file[len(str(app.builder.env.srcdir)):].lstrip('/') The error looks like it's coming from Sphinx and I did find an upper-constraints bump of Sphinx happened earlier today: https://review.opendev.org/c/openstack/requirements/+/927358 The version was bumped from 7.4.6 to 8.0.2 -- which may possibly be related to the failures. I will look more into the failure but if anyone else knows how to fix this, please feel free to propose something. -melwitt

2 3

[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 30 Aug '24

30 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 30 Aug '24

30 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 30 Aug '24

30 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 29 Aug '24

29 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

[all][elections][ptl][tc] Combined PTL/TC 2025.1 cycle Election Nominations End
by Ian Y. Choi 29 Aug '24

29 Aug '24

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 4 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Kuryr, Mistral, Swift, Watcher There is 1 project that will have elections: Cinder. -- TC Election Details -- The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and the electorate may debate their statements. Polling will start Sep 04, 2024 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#ptl-candidates [1] https://governance.openstack.org/election/#tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[election][cloudkitty] PTL candidacy for the 2025.1 release cycle
by Rafael Weingärtner 28 Aug '24

28 Aug '24

Hi all, I would like to self-nominate for the role of PTL of CloudKitty for the 2025.1 release cycle. I have been PTL since the Victoria cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. I have opened the patch with my candidacy: https://review.opendev.org/c/openstack/election/+/927392 -- Rafael Weingärtner

1 0

[nova] Next Sep 3 meeting is CANCELLED
by Sylvain Bauza 28 Aug '24

28 Aug '24

I'll be traveling to the OpenInfra Asia Summit this week. See you there if you go too. Thanks, -Sylvain

1 0

[Glance][Image Encryption] Problem with data-migration in db
by Josephine Seifert 27 Aug '24

27 Aug '24

Hi, I am currently trying to implement the upgrade path for the image encryption in Glance. This should change all rows in the image_properties table where the names star with `cinder_encryption*` to `os_encrypt*` The patch is: https://review.opendev.org/c/openstack/glance/+/926905 When I try to execute the data-migration on my devstack it does not work. I wonder why? What do I have to do to make it work? Here is what I tried: ``` stack@devstack:~/devstack$ nano ../glance/glance/db/sqlalchemy/alembic_migrations/data_migrations/2024_2_migrate01_rename_encryption_metadata.py stack@devstack:~/devstack$ source /opt/stack/data/venv/bin/activate (venv) stack@devstack:~/devstack$ glance-manage db migrate 2024_2_migrate01 INFO dbcounter [-] Registered counter for database glance DEBUG oslo_db.sqlalchemy.engines [-] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_ENGINE_SUBSTITUTION {{(pid=1782997) _check_effective_sql_mode /opt/stack/data/venv/lib/python3.10/site-packages/oslo_db/sqlalchemy/engines.py:342}} DEBUG dbcounter [-] [1782997] Writer thread running {{(pid=1782997) stat_writer /opt/stack/data/venv/lib/python3.10/site-packages/dbcounter.py:102}} INFO alembic.runtime.migration [-] Context impl MySQLImpl. INFO alembic.runtime.migration [-] Will assume non-transactional DDL. Database is up to date. No migrations needed. (venv) stack@devstack:~/devstack$ glance-manage db sync INFO dbcounter [-] Registered counter for database glance DEBUG oslo_db.sqlalchemy.engines [-] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_ENGINE_SUBSTITUTION {{(pid=1783029) _check_effective_sql_mode /opt/stack/data/venv/lib/python3.10/site-packages/oslo_db/sqlalchemy/engines.py:342}} DEBUG dbcounter [-] [1783029] Writer thread running {{(pid=1783029) stat_writer /opt/stack/data/venv/lib/python3.10/site-packages/dbcounter.py:102}} INFO alembic.runtime.migration [-] Context impl MySQLImpl. INFO alembic.runtime.migration [-] Will assume non-transactional DDL. Database is up to date. No migrations needed. (venv) stack@devstack:~/devstack$ openstack image show enc-cirros +------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | checksum | 581caa530df8ceecfe5d4a87b847d8fa | | container_format | bare | | created_at | 2024-06-21T08:10:23Z | | disk_format | raw | | file | /v2/images/137d3237-3096-4b3f-b2c9-400819211b67/file | | id | 137d3237-3096-4b3f-b2c9-400819211b67 | | min_disk | 0 | | min_ram | 0 | | name | enc-cirros | | owner | db05e1116cb04ac689d82c738a5f103c | | properties | *cinder_encryption_key_deletion_policy*='on_image_deletion', *cinder_encryption_key_id*='cf3d7b02-c82c-4a95-b866-9a22af9f87f1', hw_rng_model='virtio', locations='[{'url': | ``` thank you Josephine (Luzi)

2 2

VM fails to start in OpenSUSE for aarch64
by Junya Noguchi (Fujitsu) 27 Aug '24

27 Aug '24

To whom it may concern I tried to use OpenSUSE aarch64 VM in OpenStack environment but failed. Do you know how to solve one of the following two problems? I look forward to your reply. 1. VM startup of OpenSUSE for OpenStack on ARM fails When I deployed a VM in an OpenStack environment using OpenSUSE 15.1 for OpenStack on ARM, the VM was successfully created but failed to start. When I checked the console log from the browser, it seems that the OS boot process is not completed. What could be the cause of this? OpenSUSE image "openSUSE-Leap-15.1-OpenStack.aarch64.qcow2" https://download.opensuse.org/repositories/Cloud:/Images:/Leap_15.2/images/… Status is Active +--------------------------------------+------------------------------+---------+ | ID | Name | Status | +--------------------------------------+------------------------------+---------+ | eb653de7-68b4-4fd8-9fe5-515d1753fd5f | OpenSUSE-Leap-Arm | ACTIVE | -------- console log -------- UEFI firmware (version edk2-20230524-4.el9_3.2 built at 00:00:00 on Feb 20 2024) Tpm2SubmitCommand - Tcg2 - Not Found Tpm2GetCapabilityPcrs fail! Tpm2SubmitCommand - Tcg2 - Not Found [2J[01;01H[=3h[2J[01;01H[2J[01;01H[=3h[2J[01;01HBdsDxe: failed to load Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0): Not Found BdsDxe: loading Boot0002 "EFI Internal Shell" from Fv(64074AFE-340A-4BE6-94BA-91B5B4D0F71E)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1) BdsDxe: starting Boot0002 "EFI Internal Shell" from Fv(64074AFE-340A-4BE6-94BA-91B5B4D0F71E)/FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1) [2J[01;01H[01;01HUEFI Interactive Shell v2.2 EDK II UEFI v2.70 (EDK II, 0x00010000) [1m[33m[40mMapping table[0m[37m[40m [1m[33m[40m BLK0:[0m[37m[40m [1m[37m[40mAlias(s):[0m[37m[40m PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0) [1m[33m[40m BLK1:[0m[37m[40m [1m[37m[40mAlias(s):[0m[37m[40m PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/HD(1,MBR,0xE6E9E590,0x800,0x13FF800) [09;01HPress [1m[37m[40mESC[0m[37m[40m in 5 seconds to skip [1m[33m[40mstartup.nsh[0m[37m[40m or any other key to continue.[09;01HPress [1m[37m[40mESC[0m[37m[40m in 4 seconds to skip [1m[33m[40mstartup.nsh[0m[37m[40m or any other key to continue.[09;01HPress [1m[37m[40mESC[0m[37m[40m in 3 seconds to skip [1m[33m[40mstartup.nsh[0m[37m[40m or any other key to continue.[09;01HPress [1m[37m[40mESC[0m[37m[40m in 2 seconds to skip [1m[33m[40mstartup.nsh[0m[37m[40m or any other key to continue.[09;01HPress [1m[37m[40mESC[0m[37m[40m in 1 seconds to skip [1m[33m[40mstartup.nsh[0m[37m[40m or any other key to continue. [10;01H[1m[33m[40mShell> [0m[37m[40m ----------------------------- 2. About Login with Non-OpenStack Images When I deployed a VM using an image without "OpenStack" in the image name, it booted successfully but I could not login. Is there a way to login to a VM created using an image like this? OpenSUSE image "openSUSE-Leap-15.2.aarch64-NoCloud" https://download.opensuse.org/repositories/Cloud:/Images:/Leap_15.2/images/… Best regards, Junya Noguchi.

2 4

[all][elections][ptl][tc] Combined PTL/TC 2025.1 cycle Election Nominations Last Days
by Sławek Kapłoński 27 Aug '24

27 Aug '24

Hi, A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Aug 28, 2024 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at[1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. All members of the community are encouraged to confirm their email address and opt in to the CIVS election as described at: https://governance.openstack.org/election/#electorate Election statistics[2]: Nominations started @ 2024-08-14 23:45:00 UTC Nominations end @ 2024-08-28 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 1 day, 16:27:24 Nominations progress : 87.96% --------------------------------------------------- Projects[1] : 41 Projects with candidates : 13 ( 31.71%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 28 (Adjutant Barbican Cinder Cloudkitty Cyborg Designate Glance Heat Keystone Kuryr Magnum Manila Masakari Mistral Nova Octavia OpenStackAnsi ble OpenStackSDK Puppet_OpenStack Quality_Assurance Rally Skyline Storlets Swift Telemetry Venus Vitrage Watcher) --------------------------------------------------- TC Candidates : 3 (4 Required) =================================================== Stats gathered @ 2024-08-27 07:17:36 UTC This means that with approximately 2 days left, 28 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.opendev.org/q/project:openstack/election+is:open+file:candid… have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for… -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

How to debug port down issue on kolla ansible
by William Muriithi 27 Aug '24

27 Aug '24

Hello I am stuck for days on network setup issues and would be grateful if you could provide any pointer on how best to proceed. We have an existed vlan based network. I would like to set up the openstack to be vlan based, that is, each project would be on a separate vlan. To achieve this, I went about doing this: - Converted the port connected to neutron_external_interface to trunk on the HP switch. I am planning to use openstack to provision VM on vlan 20 * Created network ->openstack network create --project=eng --provider-network-type=vlan --provider-physical-network=sriovtenant1 --provider-segment=20 eng --gateway 192.168.20.252 --dns-nameserver 192.168.20.1 * Created subnet -> openstack subnet create --network=eng --subnet-range=192.168.20.0/24 --allocation-pool start=192.168.20.1,end=192.168.20.220 --gateway 192.168.20.252 --dns-nameserver 192.168.20.1 eng_sub1 * Created port ->openstack port create --network eng --vnic-type=direct eng_port1 [kolla@ostack-40 tmp]$ openstack network show eng | grep provider | provider:network_type | vlan | | provider:physical_network | sriovtenant1 | | provider:segmentation_id | 20 | [kolla@ostack-40 tmp]$ The issue is however with port status. It always seems to be down: [kolla@ostack-40 tmp]$ openstack port show 511f54fb-d7f2-4e59-98db-8833bb4cf5e4 | grep -i status | data_plane_status | None | | propagate_uplink_status | None | | status | DOWN | [kolla@ostack-40 tmp]$ This is the globals.yml file we are using: --- config_owner_user: "kolla" config_owner_group: "kolla" workaround_ansible_issue_8743: yes openstack_release: "2024.1" kolla_internal_vip_address: "192.168.101.221" kolla_internal_fqdn: "example.openstack.exampletech.com" kolla_external_vip_address: "192.168.102.221" kolla_external_fqdn: "example.vm.exampletech.com" kolla_sysctl_conf_path: /etc/sysctl.d/100-kolla.conf kolla_container_engine: podman network_interface: "enp4s0f0" neutron_external_interface: "enp4s0f1" disable_firewall: "true" enable_external_api_firewalld: "false" enable_neutron_sriov: "yes" neutron_sriov_physnet_mappings: sriovtenant1: enp4s0f1 enable_neutron_dvr: "yes" openvswitch_hw_offload: "yes" enable_neutron_provider_networks: "yes" ceph_version: "reef" external_ceph_cephx_enabled: "yes" ceph_glance_user: "glance" ceph_glance_keyring: "client.{{ ceph_glance_user }}.keyring" ceph_glance_pool_name: "images" ceph_cinder_user: "cinder" ceph_cinder_keyring: "client.{{ ceph_cinder_user }}.keyring" ceph_cinder_pool_name: "volumes" ceph_cinder_backup_user: "cinder-backup" ceph_cinder_backup_keyring: "client.{{ ceph_cinder_backup_user }}.keyring" ceph_cinder_backup_pool_name: "backups" ceph_nova_keyring: "{{ ceph_cinder_keyring }}" ceph_nova_user: "{{ ceph_cinder_user }}" ceph_nova_pool_name: "vms" keystone_admin_project: "example" glance_backend_ceph: "yes" cinder_backend_ceph: "yes" nova_backend_ceph: "yes" We are certain sriov is working due to this observations: [root@ostack-40 ~]# cat /sys/class/net/enp4s0f1/device/sriov_totalvfs 63 [root@ostack-40 ~]# When I look for the string vlan, on the logs, I see this which implies that vlan seem to have been initialized fine. 2024-08-26 14:57:36.933 2 INFO neutron.plugins.ml2.drivers.type_vlan [-] Network VLAN ranges: OrderedDict([('sriovtenant1', [(9, 2000)])]) 2024-08-26 14:57:49.469 2 INFO neutron.plugins.ml2.drivers.type_vlan [None req-8326ea90-01d6-4de4-895c-5a37456e4dde - - - - - -] VlanTypeDriver initialization complete [root@ostack-40 ~]# grep -i "vlan " /var/log/kolla/neutron/neutron-server.log 2024-08-26 14:57:36.933 2 INFO neutron.plugins.ml2.drivers.type_vlan [-] Network VLAN ranges: OrderedDict([('sriovtenant1', [(9, 2000)])]) 2024-08-26 14:57:49.469 2 INFO neutron.plugins.ml2.drivers.type_vlan [None req-8326ea90-01d6-4de4-895c-5a37456e4dde - - - - - -] VlanTypeDriver initialization complete [root@ostack-40 ~]# grep -i vlan /var/log/kolla/neutron/neutron-server.log 2024-08-26 14:57:36.929 2 INFO neutron.plugins.ml2.managers [-] Configured type driver names: ['flat', 'vlan', 'vxlan'] 2024-08-26 14:57:36.933 2 INFO neutron.plugins.ml2.drivers.type_vlan [-] Network VLAN ranges: OrderedDict([('sriovtenant1', [(9, 2000)])]) 2024-08-26 14:57:36.933 2 INFO neutron.plugins.ml2.managers [-] Loaded type driver names: ['flat', 'vlan', 'vxlan'] 2024-08-26 14:57:36.934 2 INFO neutron.plugins.ml2.managers [-] Registered types: dict_keys(['flat', 'vlan', 'vxlan']) 2024-08-26 14:57:37.006 2 INFO neutron.plugins.ml2.managers [-] Initializing driver for type 'vlan' 2024-08-26 14:57:49.469 2 INFO neutron.plugins.ml2.drivers.type_vlan [None req-8326ea90-01d6-4de4-895c-5a37456e4dde - - - - - -] VlanTypeDriver initialization complete 2024-08-26 14:57:49.494 2 INFO neutron.extensions.vlantransparent [None req-72317867-444d-42a7-8421-2ef4460e9aed - - - - - -] Disabled vlantransparent extension. 2024-08-26 14:57:49.597 2 INFO neutron.api.extensions [None req-72317867-444d-42a7-8421-2ef4460e9aed - - - - - -] Extension vlan-transparent not supported by any of loaded plugins What could we possibly be missing? Regards, William

2 1

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

27 Aug '24

Hello Stackers, Milestone-3 of the 2024.2 ("Dalmatian") release cycle is upon us this week [1]. This milestone marks several code freeze deadlines. It's the feature freeze across all OpenStack projects that follow the "cycle-with-rc" release model [2], as well as a client library code freeze and a freeze for the global requirements and constraints. Please refer to Thierry Carrez (ttx)'s email regarding the release team's priorities for this week [3]. Alongside these significant release events, we're also wrapping up the nomination period for the combined PTL/TC Elections for the 2025.1 release cycle on 2024-08-28. If you have been considering nominating yourself for any of these leadership roles, please do not delay any further [4]. I'd like to congratulate the three Outreachy interns who successfully completed their internships this week. I encourage you to read about their experiences through their blogs. Abby Nduta (NdutaRed) [5] worked with Tatiana Ovchinnikova (tmazur) on OpenStack Horizon, while Mohd Ariq (tspyderboy) [6] and Christian Okeke Chima (ccokeke) [7] worked with Carlos Eduardo da Silva (carloss), Ashley Rodriguez (ashrodri), and me on Manila UI. Outreachy interns have been a valuable part of energizing and enriching this community over the years. Their journey in this community wouldn't be possible without generous sponsorship. Currently, the OpenStack community doesn't have funding to secure an intern for Outreachy Internships running between December 2024 and May 2025. If you're able to support this program, or know someone who can, please get in touch with the OpenStack Outreachy coordinators Mahati Chamarthy (mahatic) and Dmitri Tantsur (dtantsur) off-list. You can also ping us on OFTC's #openstack-outreachy channel. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on 2024-08-20. We focused most of this meeting on the implications of testing/shipping non-OSI licensed software within OpenStack. There was consensus that the current TC guidance regarding shipping binary artifacts [8] needs to be extended. A suggestion was made to disallow bundling non-OSI-compatible licensed software within binaries built, tested, and/or shipped/hosted on community infrastructure. We also discussed the need for a policy around reacting to integrated software whose licensing changes to a non-OSI-compatible license over time. This discussion gained prominence due to the Kolla project looking to ship a container image for the Masakari service that recently began supporting the use of HashiCorp's Consul [9]. Consul is one of several HashiCorp "open source" projects licensed under a "Business Source License" [10]. This was a very interesting discussion that involved a lot of questions; I recommend reading through the meeting log for the complete context [11]. Further policy discussion was tabled for an upcoming forum/PTG session with a wider audience. The next meeting of the OpenStack Technical Committee is on 2024-08-27 at 1800 UTC in OFTC's #openstack-tc channel. The agenda is on our meeting wiki [12]. Please consider joining us. Remember, you can always propose topics for this meeting; feel free to edit the wiki [12], but be sure to leave your IRC nickname so we can call on you. === Governance Proposals === ==== Merged ==== - 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 - Opt-in the oslo DPL model for the 2025.1 cycle | https://review.opendev.org/c/openstack/governance/+/926154 ==== Open for Review ==== - Charms: Retire unmaintained charms | https://review.opendev.org/c/openstack/governance/+/926793 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Define testing runtime for the 2025.1 release | https://review.opendev.org/c/openstack/governance/+/926150 === Upcoming Events === - 2024-08-28: Nomination period closes for 2025.1 OpenStack PTL+TC elections - 2024-08-29: Dalmatian-3 milestone - 2024-09-03: OpenInfra Summit Asia, Suwon - 2024-09-06: OpenInfra Days, Tokyo - 2024-09-10: OpenInfra Board Meeting: https://board.openinfra.dev/ Thank you very much 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] Cycle-with-RC release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc [3] Release countdown for week R-5: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] How to submit a candidacy: https://governance.openstack.org/election/#how-to-submit-a-candidacy [5] Abby Nduta's Outreachy Blog: https://dev.to/ndutared/ [6] Mohd Ariq's Outreachy Blog: https://medium.com/@tspyderboy [7] Christian Okeke Chima's Outreachy Blog: https://dev.to/ccokeke/ [8] TC Guidelines for Managing Releases of Binary Artifacts: https://governance.openstack.org/tc/resolutions/20170530-binary-artifacts.h… [9] License question - OpenStack Masakari: https://lists.openstack.org/archives/list/legal-discuss@lists.openstack.org… [10] HashiCorp licensing: https://www.hashicorp.com/license-faq [11] TC Meeting IRC Log, 2024-08-20: https://meetings.opendev.org/meetings/tc/2024/tc.2024-08-20-18.00.log.html [12] TC Meeting Agenda, 2024-08-27: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[all] Please remove sphinxcontrib-*diag from your (docs) dependencies
by Stephen Finucane 26 Aug '24

26 Aug '24

o/ A large number of projects are using the sphinxcontrib-blockdiag, sphinxcontrib- nwdiag and sphinxcontrib-seqdiag projects in their documentation. These packages are no longer maintained and have not seen releases in over 3 years. They are also not compatible with Pillow 10.x and are thus preventing us from bumping Pillow to a version that has pre-built Python 3.12 wheels [1][2]. Please remove these dependencies. In Nova, we decided to just take the build assets (SVG or PNG) and use these directly in our documentation [3]. Absent a better idea, this approach will work for you also. As someone with Python 3.12 (and soon, 3.13) as their default Python version, I would reallyu like to get Pillow bumped early in E, so by doing this work now we avoid broken docs CI jobs when that bump happens. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/927102 [2] https://bugs.launchpad.net/ironic/+bug/2026345 [3] https://review.opendev.org/c/openstack/nova/+/906309

1 0