March 2024 - openstack-discuss - lists.openstack.org

Openstack trove Error launching instance
by Shameem Farhath 23 Mar '24

23 Mar '24

Hi Team, Myself Shameem, on behalf of NerveDigital i am writing this mail. We are provisioning the trove database as a service in our existing infrastructure, and we got an ERROR on launching a DB instance. We have been troubleshooting it for a while and find no hope. Please help us to find a proper resolution for the issue. Please find the attached ERROR while launching the instance. Openstack version: yoga Operating system used: Ubuntu 22.04 Guest operating system: ubuntu jammy (downloaded from opendev tarball) Configuration files: Attached ERROR from the log: Attached *Regards,* *Shameem Farhath A* *9562440781* *www.NerveDigital.net* <http://www.NerveDigital.net>

1 0

[openstack-ansible][horizon][keystone] multidomain - LDAP admins unable to see Horizon Admin Dashboard
by Janet 'Saoirse' Sullivan 22 Mar '24

22 Mar '24

Hi, I have a multi-domain setup (LDAP and Default) and while LDAP users can see the Projects and Identity tabs in the Horizon dashboard, they can't see the Admin tab, even if they are assigned the admin role. The Default domain admin user can see this dashboard just fine. Is there a policy that needs to be changed so LDAP users with the admin role can see the Admin tab in Horizon? Openstack 2023.2.

1 0

[TC][all] Recheck analysis
by Sławek Kapłoński 22 Mar '24

22 Mar '24

Hi Stackers, Some time ago I started monitoring something what we have called "bare rechecks" which are "recheck" comments without any reason given. I was also asking various teams to improve that, try to check failures of the CI jobs and put some kind of reason in the recheck comment. That went pretty well and currently most of the teams are doing pretty good job there. See stats from last 30 days: +--------------------+---------------+--------------+-------------------+ | Team | Bare rechecks | All Rechecks | Bare rechecks [%] | +--------------------+---------------+--------------+-------------------+ | OpenStackSDK | 8 | 8 | 100.0 | | OpenStack-Helm | 41 | 41 | 100.0 | | cloudkitty | 1 | 1 | 100.0 | | monasca | 6 | 6 | 100.0 | | skyline | 2 | 2 | 100.0 | | trove | 1 | 1 | 100.0 | | rally | 1 | 1 | 100.0 | | watcher | 1 | 1 | 100.0 | | mistral | 5 | 8 | 62.5 | | kuryr | 1 | 2 | 50.0 | | zaqar | 1 | 2 | 50.0 | | horizon | 6 | 15 | 40.0 | | swift | 9 | 25 | 36.0 | | manila | 5 | 14 | 35.71 | | kolla | 14 | 68 | 20.59 | | cinder | 15 | 77 | 19.48 | | ironic | 10 | 53 | 18.87 | | glance | 11 | 59 | 18.64 | | requirements | 13 | 73 | 17.81 | | Telemetry | 2 | 12 | 16.67 | | nova | 16 | 105 | 15.24 | | OpenStackAnsible | 5 | 40 | 12.5 | | magnum | 1 | 9 | 11.11 | | neutron | 13 | 118 | 11.02 | | Quality Assurance | 3 | 30 | 10.0 | | Release Management | 1 | 12 | 8.33 | | octavia | 2 | 34 | 5.88 | | keystone | 0 | 1 | 0.0 | | OpenStack Charms | 0 | 1 | 0.0 | | oslo | 0 | 8 | 0.0 | | Puppet OpenStack | 0 | 95 | 0.0 | | barbican | 0 | 2 | 0.0 | | designate | 0 | 4 | 0.0 | | heat | 0 | 7 | 0.0 | | tacker | 0 | 63 | 0.0 | | tripleo | 0 | 4 | 0.0 | +--------------------+---------------+--------------+-------------------+ Now I though that it's time for the "next step" so I spent some time looking at the reasons of the rechecks done in last 30 days. I collected those reasons with script [1] and here are some top reasons found: +----------------------------------------------------------+----------------------+ | Recheck comment | Number of occurences | +----------------------------------------------------------+----------------------+ | recheck unrelated failure | 48 | | recheck irrelevant failure | 45 | | recheck unrelated test failure | 9 | | recheck testing | 9 | | recheck infra-failure | 9 | | recheck tempest-slow-py3 | 8 | | recheck nova-next | 8 | | recheck timeout | 7 | | recheck neutron-functional-with-uwsgi | 7 | | recheck failure not related to this change | 7 | | recheck ovn-octavia-provider-functional-master unrelated | 7 | | recheck jobs running too early | 6 | | recheck dependency updated | 5 | | recheck random failure | 5 | | recheck - bifrost bug | 5 | +----------------------------------------------------------+----------------------+ Those comments as they were put in the gerrit. Of course there was much more different comments there. I just wanted to highlight here some of the most common ones. I also asked ChatGPT to group all of them in some common groups. Below are some of the main categories of the reason found by the ChatGPT: CI/Testing Issues: Timeouts in various tests (e.g., tempest tests, tox tests). Infrastructure failures impacting CI. Kernel panics or guest panics during testing. Dependency-related failures (merged or updated). Unexpected failures or intermittent issues. Dependency Management: Dependency patches merged or updated. Dependency-related failures. Release/Documentation Updates: Release note fixes or updates. Content cleanup or removal. Documentation-related failures. Infrastructure/Tooling: Infrastructure mirror issues. Tooling updates or fixes (e.g., grub2-tools, proliantutils). Issues related to mirror servers. Specific Project/Component Issues: Nova-related failures (e.g., nova-ceph-multistore). Cinder-related failures (e.g., cinder-plugin-ceph-tempest). OpenStack SDK related failures. Configuration/Setup Problems: Problems with deployment or setup (e.g., grub2-tools missing, bifrost bug). Issues with configurations (e.g., host patterns). Network/Connection Problems: DNS resolution issues. Timeout errors related to network operations. Post-Failure Analysis: Attempts to reproduce failures. Investigation into infrastructural problems. Finally some conclusion from this analysis. It seems that our most common reason of the gate instability is something called "unrelated/irrelevant failure" and also things like "infra failure". In both cases we can't really do much to try to improve that as this information is not enough. So I would like to ask all of You to try to be more precise in the recheck comments and give more detailed reasons why You recheck Your patch. If for example You have to recheck the patch due to "unrelated failure", please write there also bug number which cause failure or simply give there name of the unrelated failed test or something like that. That way when I will do similar analysis in e.g. month from now maybe it will be easier to identify most common bugs which are causing "unrelated failures" and try to prioritize somehow work on fix of that bug. [1] https://github.com/slawqo/rechecks-stats/blob/main/rechecks_stats/rechecks_… -- Slawek Kaplonski Principal Software Engineer Red Hat

8 16

[ironic]Server does not accept power operations when running OpenStack Ironic on Redfish
by Junya Noguchi (Fujitsu) 22 Mar '24

22 Mar '24

To whom it may concern. My name is Junya Noguchi. We have the following problems and questions. Please respond. 1. Problems and Questions When we use OpenStack Ironic Redfish driver to manage Redfish capable server, the server may not accept power on operations. Server may or may not power on. We want to clarify whether this is a server-specific issue or an OpenStack Ironic bug. Occurrence event ・Auto-cleaning or instance startup failed. ・Ironic does not power on via Redfish driver (see log) ・We tried increasing the power_state_change in ironic.conf to 30 minutes, but it didn't resolved. ・It does not happen when changing Redfish to IPMI 2. Server information R272-P31 (GIGABYTE Arm Server) CPU : Ampere Altra Max 2.8GHz-3.0GHz 1/128 Memory : 256GB Disk : 1TB/SSDx3/RAID1 Server firmware : MegaRac SP-X：https://www.ami.com/megarac/ ※It states that it is compatible with IPMI/Redfish Openstaack ver : Zed Hardware interface : redfish Power interface : redfish Boot interface : pxe Deploy interface : direct Network interface : flat 3. Log File : /var/log/ironic/ironic-conductor.log 2023-12-19 10:24:47.677 384940 DEBUG sushy.connector [-] HTTP request: GET "Server FQDN"/redfish/v1/Systems/Self; headers: {'OData-Version': '4.0'}; body: None; blocking: False; timeout: 60; session arguments: {}; _op /usr/lib/python3.9/site-packages/sushy/connector.py:118 2023-12-19 10:24:49.975 384940 DEBUG sushy.connector [-] HTTP response for GET "Server FQDN"/redfish/v1/Systems/Self: status code: 200 _op /usr/lib/python3.9/site-packages/sushy/connector.py:226 2023-12-19 10:24:49.976 384940 DEBUG sushy.resources.base [-] Received representation of System /redfish/v1/Systems/Self: {'_actions': {'reset': {'allowed_values': None, 'operation_apply_time_support': {'_maintenance_window_resource': {'resource_uri': '/redfish/v1/Systems/Self'}, 'maintenance_window_duration_in_seconds': 600, 'maintenance_window_start_time': None, 'mapped_supported_values': [<ApplyTime.IMMEDIATE: 'Immediate'>, <ApplyTime.AT_MAINTENANCE_WINDOW_START: 'AtMaintenanceWindowStart'>], 'supported_values': ['Immediate', 'AtMaintenanceWindowStart']}, 'target_uri': '/redfish/v1/Systems/Self/Actions/ComputerSystem.Reset'}}, '_oem_vendors': ['Gbt'], '_settings': None, 'asset_tag': 'Free form asset tag', 'bios_version': 'F31h (SCP: 2.10.20220531)', 'boot': {'allowed_values': ['None', 'Pxe', 'Floppy', 'Cd', 'Usb', 'Hdd', 'BiosSetup', 'Utilities', 'UefiShell', 'UefiTarget', 'SDCard', 'UefiHttp', 'RemoteDrive', 'UefiBootNext'], 'enabled': <BootSourceOverrideEnabled.ONCE: 'Once'>, 'mode': <BootSourceOverrideMode.UEFI: 'UEFI'>, 'target': <BootSource.PXE: 'Pxe'>}, 'description': 'System Self', 'hostname': None, 'identity': 'Self', 'indicator_led': <IndicatorLED.OFF: 'Off'>, 'links': {'oem_vendors': None}, 'maintenance_window': None, 'manufacturer': 'GIGABYTE', 'memory_summary': {'health': 'OK', 'size_gib': 256}, 'name': 'System', 'part_number': '000000000001', 'power_state': <PowerState.OFF: 'Off'>, 'serial_number': 'XXXXXXXXXXXXXX', 'sku': '01234567890123456789AB', 'status': {'health': <Health.OK: 'OK'>, 'health_rollup': <Health.CRITICAL: 'Critical'>, 'state': <State.ENABLED: 'Enabled'>}, 'system_type': <SystemType.PHYSICAL: 'Physical'>, 'uuid': '00000000-0000-4000-8000-D85ED387A8B3'} refresh /usr/lib/python3.9/site-packages/sushy/resources/base.py:689 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall [-] Dynamic backoff interval looping call 'ironic.conductor.utils.node_wait_for_power_state.<locals>._wait' failed: oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 1490.91 seconds 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall Traceback (most recent call last): 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall File "/usr/lib/python3.9/site-packages/oslo_service/loopingcall.py", line 154, in _run_loop 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall idle = idle_for_func(result, self._elapsed(watch)) 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall File "/usr/lib/python3.9/site-packages/oslo_service/loopingcall.py", line 349, in _idle_for 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall raise LoopingCallTimeOut( 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 1490.91 seconds 2023-12-19 10:24:49.976 384940 ERROR oslo.service.loopingcall 2023-12-19 10:24:49.977 384940 ERROR ironic.conductor.utils [None req-60791dc1-85c6-44c6-a3b7-a60e3242607d 4cb102fe974543b19c3e39916c7e61c1 00cfc520ffcb4533861e005a9a1e694f - - default default] Timed out after 1200 secs waiting for power on on node a357fdab-d8d5-4260-8e72-b444fa7c5cb9.: oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 1490.91 seconds 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils [None req-60791dc1-85c6-44c6-a3b7-a60e3242607d 4cb102fe974543b19c3e39916c7e61c1 00cfc520ffcb4533861e005a9a1e694f - - default default] Failed to prepare node a357fdab-d8d5-4260-8e72-b444fa7c5cb9 for cleaning: Failed to set node power state to power on.: ironic.common.exception.PowerStateFailure: Failed to set node power state to power on. 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils Traceback (most recent call last): 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/utils.py", line 183, in node_wait_for_power_state 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils return timer.start(initial_delay=1, timeout=retry_timeout).wait() 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/eventlet/event.py", line 125, in wait 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils result = hub.switch() 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/eventlet/hubs/hub.py", line 313, in switch 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils return self.greenlet.switch() 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/oslo_service/loopingcall.py", line 154, in _run_loop 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils idle = idle_for_func(result, self._elapsed(watch)) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/oslo_service/loopingcall.py", line 349, in _idle_for 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils raise LoopingCallTimeOut( 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 1490.91 seconds 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils oslo_service.loopingcall.LoopingCallTimeOut: Looping call timed out after 1490.91 seconds 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils During handling of the above exception, another exception occurred: 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils Traceback (most recent call last): 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/cleaning.py", line 91, in do_node_clean 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils prepare_result = task.driver.deploy.prepare_cleaning(task) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic_lib/metrics.py", line 59, in wrapped 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils result = f(*args, **kwargs) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/drivers/modules/agent_base.py", line 726, in prepare_cleaning 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils result = deploy_utils.prepare_inband_cleaning( 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py", line 732, in prepare_inband_cleaning 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils manager_utils.node_power_action(task, states.REBOOT) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/task_manager.py", line 153, in wrapper 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils return f(*args, **kwargs) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/utils.py", line 341, in node_power_action 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils notify_utils.emit_power_set_notification( 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils self.force_reraise() 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils raise self.value 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/utils.py", line 329, in node_power_action 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils task.driver.power.reboot(task, timeout=timeout) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/task_manager.py", line 153, in wrapper 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils return f(*args, **kwargs) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/drivers/modules/redfish/power.py", line 166, in reboot 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils _set_power_state(task, system, next_state, timeout=timeout) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/drivers/modules/redfish/power.py", line 68, in _set_power_state 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils cond_utils.node_wait_for_power_state(task, target_state, 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils File "/usr/lib/python3.9/site-packages/ironic/conductor/utils.py", line 189, in node_wait_for_power_state 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils raise exception.PowerStateFailure(pstate=new_state) 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils ironic.common.exception.PowerStateFailure: Failed to set node power state to power on. 2023-12-19 10:24:49.989 384940 ERROR ironic.conductor.utils 2023-12-19 10:24:49.991 384940 DEBUG ironic.conductor.utils [None req-60791dc1-85c6-44c6-a3b7-a60e3242607d 4cb102fe974543b19c3e39916c7e61c1 00cfc520ffcb4533861e005a9a1e694f - - default default] Node a357fdab-d8d5-4260-8e72-b444fa7c5cb9 is not fast-track-able because it has an error: Failed to change power state to 'power on' by 'rebooting': Failed to set node power state to power on. is_fast_track /usr/lib/python3.9/site-packages/ironic/conductor/utils.py:1146 ---------------------------------------------------------------- 富士通株式会社先端技術開発本部ソフトウェア開発統括部基盤ソフト開発部野口惇矢(Noguchi Junya) 外線：070-3052-0998 内線：72-6042-3844 mail：noguchi.junya(a)jp.fujitsu.com

3 2

[Trove][kolla] trove db instance failed
by jayesh chaudhari 22 Mar '24

22 Mar '24

Hi All, I have enabled trove in my kolla ansible yoga setup. But my trove database instance is getting stuck in build state and then eventually failed after some time with polling timeout error. I have created trove management network which is my vlan network, also my control plane and data plane traffic is segregated through different interfaces. Now when I am creating db instance in admin tenant, my openstack instance in service tenant which is getting created do not have any network. I have tested trove-guest-image manually which is working fine. Am I missing something here ? Please suggest Thanks, Jayesh

1 0

Questi
by Franck VEDEL 22 Mar '24

22 Mar '24

Good morning, I currently have an Openstack cluster made up of 3 nodes, an iscsi bay (10T), 576 G of Ram, 10T, 288vcpus. This cluster is used by around 150 students, but is reaching its limits. Having obtained a budget to set up a larger cluster, I am wondering about the choice of the number of nodes, their role (how many controllers, network, compute, etc.) and above all what solution for storage. Let's imagine a budget to buy 6 servers with good capacities, is the right choice Ceph storage (with cinder and rdb?) on the Openstack cluster nodes? Do we need 3 servers for a Ceph cluster and 3 for the Openstack part (in this case I lose capacity for the "compute" part)... I don't know what the right choices are and above all, I have a little afraid of going in the wrong directions. Could any of you guide me, or give me links to sites that could help me (and that I haven't seen). Thanks in advance Franck VEDEL Dép. Réseaux Informatiques & Télécoms IUT1 - Univ GRENOBLE Alpes 0476824462 Stages, Alternance, Emploi.

7 15

[release] Release countdown for week R-2, March 25-29
by Herve Beraud 22 Mar '24

22 Mar '24

Development Focus ----------------- We are on the final mile of the 2024.1 Caracal development cycle! Remember that the 2024.1 Caracal final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. March 28 is the deadline for final 2024.1 Caracal release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on April 3, 2024. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2024.2 Dalmatian development cycle, including discussing Forum and PTG sessions content, in preparation of the 2024.2 Dalmatian Virtual PTG (April 8-12, 2024).. Actions ------- Watch for any translation patches coming through on the stable/2024.1 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2024.1 branch before triggering a new release. Also merge open release patches like https://review.opendev.org/q/topic:reno-2024.1+status:open. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final 2024.1 Caracal release: April 3, 2024 2024.2 Dalmatian Virtual PTG: April 8-12, 2024 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[watcher][caracal] release critical support for new oslo.db
by James Page 22 Mar '24

22 Mar '24

Hi Watchers Ref: https://bugs.launchpad.net/watcher/+bug/2056181 Watcher 12.0.0 RC1 is not compatible with oslo.db 15.0.0 - the test suite has numerous failures as the DB api module has not been updated for the changes in oslo.db to support SQLAlchemy 2.0+. Raising awareness mainly - I can take a look at this but if anyone else with more experience of this transition can help much appreciated. Cheers James

1 0

[kolla] upgrade from 2023.1 to 2023.2
by Satish Patel 22 Mar '24

22 Mar '24

Folks, I am trying to upgrade kolla-ansible deployment from 2023.1 to 2023.2. During upgrade encounter this error TASK [service-ks-register : cinder | Granting user roles] ******************************************************************************* FAILED - RETRYING: [os-ctrl1]: cinder | Granting user roles (5 retries left). FAILED - RETRYING: [os-ctrl1]: cinder | Granting user roles (4 retries left). FAILED - RETRYING: [os-ctrl1]: cinder | Granting user roles (3 retries left). FAILED - RETRYING: [os-ctrl1]: cinder | Granting user roles (2 retries left). FAILED - RETRYING: [os-ctrl1]: cinder | Granting user roles (1 retries left). failed: [os-ctrl1] (item=cinder -> service -> service) => {"action": "os_user_role", "ansible_loop_var": "item", "attempts": 5, "changed": false, "extra_data": {"data": null, "details": null, "response": "None"}, "item": {"project": "service", "role": "service", "user": "cinder"}, "msg": "No Role found for service"} As per release notes [1] I have noticed it requires a service account but not sure what I have to add in config. [1] https://docs.openstack.org/releasenotes/kolla-ansible/2023.2.html#relnotes-…

2 3

[openstack-helm-infra][mariadb] mysql-exporter installation does not support ServiceMonitor
by mohammadk7798＠gmail.com 21 Mar '24

21 Mar '24

Hi folks. When you enable exporter monitoring, you need to create the ServiceMonitor manually and the whole "enabling monitoring" experience does not feel complete. Do we want to add support for that? I can send a pull request for this feature.

1 0