- openstack-discuss - lists.openstack.org

Cinder Bug Report 2024-01-31
by Jon Bernard 31 Jan '24

31 Jan '24

Hello Argonauts, Apologies for the hiatus. Between holidays, snow days, and sick days, January has been quite a month. Here are current bugs for this week, we will resume the bug meetings after the weekly upstream meeting next week. Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - Support for the "bring your own keys" approach for Cinder <https://bugs.launchpad.net/cinder/+bug/2051108> - Status: New - Documentation of Ceph auth caps for RBD clients used by Cinder / Glance / Nova is missing or inconsistent <https://bugs.launchpad.net/cinder/+bug/2051244> - Status: New - Dell PowerMax driver issues restapi version 92 for Unisphere 10.1 <https://bugs.launchpad.net/cinder/+bug/2051828> - Status: In Progress - Dell PowerMax: Add timeout when PowerMax does not return RESTAPI call <https://bugs.launchpad.net/cinder/+bug/2051830> - Status: In Progress - Fibre channel not scanning all targets <https://bugs.launchpad.net/os-brick/+bug/2051237> - Status: In Progress Thanks, -- Jon

1 0

What are the correct auth caps for Ceph RBD clients of Cinder / Glance / Nova
by Christian Rohmann 31 Jan '24

31 Jan '24

Hey openstack-discuss, I am a little confused about correct and required Ceph authx permissions for the RBD clients in Cinder, Glance and also Nova: When Glance is requested to delete an image it will check if this image has depended children, see https://opendev.org/openstack/glance_store/src/commit/6f5011d1f05c99894fb8b…. The children of Glance images usually are (Cinder) volumes, which therefore live in a different RBD pool "volumes". But if such children do exist a 500 error is thrown by Glance API. There also is an bug about this issue on Launchpad [3]. Manually using the RBD client shows the same error: > # rbd -n client.glance -k /etc/ceph/ceph.client.glance.keyring -p > images children $IMAGE_ID > > 2023-12-13T16:51:48.131+0000 7f198cf4e640 -1 > librbd::image::OpenRequest: failed to retrieve name: (1) Operation not > permitted > 2023-12-13T16:51:48.131+0000 7f198d74f640 -1 librbd::ImageState: > 0x5639fdd5af60 failed to open image: (1) Operation not permitted > rbd: listing children failed: (1) Operation not permitted > 2023-12-13T16:51:48.131+0000 7f1990c474c0 -1 librbd::api::Image: > list_descendants: failed to open descendant b7078ed7ace50d from pool > instances:(1) Operation not permitted So it's a permission error. Following either the documentation of Glance [1] or Ceph [2] on configuring the ceph auth caps there is no mention of granting anything towards the volume pool to Glance. So this is what I currently have configured: > client.cinder > key: REACTED > caps: [mgr] profile rbd pool=volumes, profile rbd-read-only > pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=volumes, profile rbd-read-only > pool=images > > client.glance > key: REACTED > caps: [mgr] profile rbd pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=images > > client.nova > key: REACTED > caps: [mgr] profile rbd pool=instances, profile rbd pool=images > caps: [mon] profile rbd > caps: [osd] profile rbd pool=instances, profile rbd pool=images > When granting the glance client e.g. "rbd-read-only" to the volumes pool via: > > # ceph auth caps client.glance mon 'profile rbd' osd 'profile rbd > pool=images, profile rbd-read-only pool=volumes' mgr 'profile rbd > pool=images, profile rbd-read-only pool=volumes' > the error is gone. I am wondering through if this is really just a documentation bug (at OpenStack AND Ceph equally) and if Glance really needs read-only on the whole volumes pool or if there is some other capability that covers asking for child images. All in all I am simply wondering what the correct and least-privilege ceph auth caps for the RBD clients in Cinder, Glance and Nova would look like. Thanks Christian [1] https://docs.openstack.org/glance/latest/configuration/configuring.html#con… [2] https://docs.ceph.com/en/latest/rbd/rbd-openstack/#setup-ceph-client-authen… [3] https://bugs.launchpad.net/glance/+bug/2045158

6 15

[cinder] This week's meeting will be in video+IRC
by Rajat Dhasmana 31 Jan '24

31 Jan '24

Hello Argonauts, As we keep last meeting of the month in video + IRC mode, this week's meeting (today) will be held in video + IRC mode with details as follows: Date: 31st January, 2024 Time: 1400 UTC Meeting link: https://meet.google.com/mmb-fhtd-sjm IRC Channel: #openstack-meeting-alt Make sure you're connected to both the gmeet meeting and IRC. Thanks Rajat Dhasmana

1 0

[all][oslo][ironic][tc] Eventlet version bumps (topic:bump-eventlet in gerrit)
by Jay Faulkner 31 Jan '24

31 Jan '24

Hi all, https://review.opendev.org/q/topic:%22bump-eventlet%22 was pushed recently, to bump eventlet versions to a consistent lower bound across OpenStack projects. I saw some concerns about this across various OpenStack IRC channels, and wanted to start a larger conversation around the changes rather than having what would be my third separate small conversation about it :). I cannot speak to exactly why Herve pushed these changes, but I think they are a good idea and should be merged. If you're unaware or haven't read up on the context; versions of eventlet before 0.34 were released with minimal/failing CI, and done so with known bugs in many cases. A group of developers has taken the last months to improve the state of eventlet considerably, enhancing and improving CI, discovering and fixing known issues and enabling support for Python 3.12. From my perspective; this is a significant enough improvement to warrant our community moving forward generally[0] with setting a new higher low bound for eventlet -- the versions that are maintained. I do think that we can do a better job of advertising the value of this change in gerrit to other OpenStack contributors; simply stating it's for python 3.12 support downplays the significant improvements made across that project and the overall value of landing the version bump. I am unsure if we should advertise the improvements in a user/operator facing manner; I lean towards not doing so. From a single project perspective (with my Ironic PTL hat on): I have no desire to troubleshoot bugs in Ironic, or related projects, that only occur in eventlet versions prior to 0.34. This leads me to believe landing those changes in Ironic are the good path forward, and I'll be advocating for that inside Ironic. Thanks, Jay Faulkner OpenStack TC Chair OpenStack Ironic PTL 0: I'll note this should not be read as a suggestion of a mandate; only that it's a good idea to bump this requirement in OpenStack projects and should be done unless cores for that project see a specific reason why not.

2 6

[cinder] qos don t keep modifications
by garcetto 31 Jan '24

31 Jan '24

good evening, i was trying qos on cinder volumes, and it is working fine, BUT i found that if i modify the qos limits, or update or even remove them the actual vols that already have the previous iops limits do NOT thake new values...the newly created vols yes, the old ones not...is it a bug or is it normal? here i create a 100 iops limit, set on volumes type, THEN modify it, even reboot istance, BUT old value persisist... [image: image.png] thank you.

3 3

Openstack-Ansible External Networking OVN (Br-ex)
by jjjamesg 31 Jan '24

31 Jan '24

I can't for the life of me get external connectivity working, openstack itself works i just cant get external connectivity working, I can see ovs has created br-ex with bond1 attached. ovs-vsctl get open . external_ids:ovn-bridge-mapping shows: "physnst1:br-ex" I have tried creating the network with both: openstack network create --share --external --provider-physical-network physnet1 --provider-network-type vlan --provider-segment 233 public openstack network create --share --external --provider-physical-network physnet1 --provider-network-type flat publicnet-flat Only errors i can see is in the neutron container when i try and either create an instance on said network or attach a fip is is: (similar errors from a vlan type network this is just the error i pulled at the time) ERROR neutron.plugins.ml2.managers [req-de7f1cb8-ac8e-4dd6-ad2a-e14afdb152b5 req-c6a2aaff-ccf9-4ef3-9ef 7-1a8e4c7a1e41 9c27de6bdc4449abbbbcd5e5c4951bb9 2fced1ff77f5428eb2b63879bdd608cc - - default default] Failed to bind port 03cc1708-d4a2-4b11-bca2-40ebe0acff60 on host 02 for vnic_type normal using segments [{'id': '2ef64682-b5ff-472b-935d-a3c2b615d70f', 'network_type': 'flat', 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': '52b4f4e9-47f3-431b-8c45-ec8cc17f561d'}] WARNING neutron.scheduler.dhcp_agent_scheduler [None req-aafa81d9-479c-4f56-be6f-54d4ab3b42aa 1b29a 2297a224cdcaaba84e0eac30205 bafabcf2414d4adf98cab165c3f3de12 - - default default] No more DHCP agents WARNING neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api [None req-aafa81d9-479c-4f56-be6f-54d4ab3b42aa 1b29a2297a224cdcaaba84e0eac30205 bafabcf2414d4adf98cab165c3f3de12 - - default default] Unable to schedule network 5fa049f5-0ed4-4287-9c63-dd753c853c35: no agents available; will retry on subsequent port and subnet creation events. I just cant figure out WHY this isn't working.. Below is my config: ############# ### /etc/network/interfaces: ############# auto bond1 iface bond1 inet manual bond-slaves eno2 eno4 bond-mode 802.3ad bond-miimon 100 bond-downdelay 200 bond-updelay 200 bond-lacp-rate 1 mtu 9000 auto bond1.30 iface bond1.30 inet manual vlan-raw-device bond1 ## (br-pubv is for my public vip) auto bond1.232 iface bond1.232 inet manual vlan-raw-device bond1 auto br-overlay iface br-overlay inet static bridge_stp off bridge_waitport 0 bridge_fd 0 bridge_ports bond1.30 address auto br-pubv iface br-pubv inet static address gateway bridge_stp off bridge_waitport 0 bridge_fd 0 bridge_ports bond1.232 ############# ### openstack_user_config.yml: ############# - network: container_bridge: "br-ex" network_interface: "bond1" type: "vlan" range: "232:332" net_name: "physnet1" group_binds: - neutron_ovn_controller ############# ### user_variables.yml ############# neutron_plugin_type: ml2.ovn neutron_plugin_base: - ovn-router - qos - neutron.services.ovn_l3.plugin.OVNL3RouterPlugin - neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin - vpnaas - metering - firewall_v2 neutron_ml2_drivers_type: "vlan,local,geneve,flat" neutron_provider_networks: network_types: "geneve" network_geneve_ranges: "1:1000" network_vlan_ranges: "physnet1" network_mappings: "physnet1:br-ex" network_interface_mappings: "br-ex:bond1" Bond1 is a trunk port (no native vlan), that has access to both overlay vlan and the 232:332 vlan range which both work when setting either network as a bridge on bond1 so connectivity is there. I have network-northd/gateway_hosts defined as well as: neutron_neutron_conf_overrides: ovn: enable_distributed_floating_ip: True openstack_host_specific_kernel_modules: - name: "openvswitch" pattern: "CONFIG_OPENVSWITCH" This should by all accounts just work, but for some reason for me it's not, what steps have i missed?

4 8

Incorrectly implemented service tokens in kolla-ansible
by Franciszek Przewoźny 30 Jan '24

30 Jan '24

Hi all, Can someone from kolla-ansible development have a look into that: https://bugs.launchpad.net/kolla-ansible/+bug/2049762 ? As for now, the provided configuration is totally different to what's described in manual. Thanks! Franciszek Przewoźny

2 2

[masakari][masakari-monitors] Feature to monitor hosts by kubernetes
by dogyun kim 30 Jan '24

30 Jan '24

Hi team masakari! I'm using openstack on kubernetes and also masakari for HA. I have developed a function monitoring by using kubernetes api internally to masakari-monitors for k8s-native openstack and want to contribute. blueprint link : https://blueprints.launchpad.net/masakari/+spec/host-monitors-by-kubernetes

5 5

[cinder] Inactive 3rd party CIs
by Takashi Kajinami 30 Jan '24

30 Jan '24

Hi, While I was trying to get a fresh restult from DellEMC VNX CI in [1], I noticed that some of the 3rd part CIs are inactive and haven't been posted any results for a long period. # See [2] and the list below. Note that the list may contain CIs for retired drivers. I'm wondering if someone from the cinder team can review the status and reach the vendors maintaining these CIs. If any of these are no longer working and there is no plan to recover these then I believe we have to mark the associated volume drivers unsupported and then remove these in a future release. Thank you, Takashi irc: tkajinam [1] https://review.opendev.org/c/openstack/cinder/+/834805 [2] http://cinderstats.ivehearditbothways.com/cireport.txt $ grep -B 2 -E 'last seen: 20(1|2[0123])' cireport.txt Checking name: Brocade Openstack CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Brocade_Openstack_CI first seen: 2019-03-07 02:43:59 (1781 days, 23:21:11 old) https://review.opendev.org/641539 last seen: 2019-06-17 20:36:40 (1679 days, 5:28:30 old) https://review.opendev.org/562053 -- Checking name: Cloudbase Cinder SMB3 CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Cloudbase_Cinder_SMB3_CI first seen: 2022-08-24 06:02:19 (515 days, 20:03:06 old) https://review.opendev.org/854268 last seen: 2022-11-02 13:32:21 (445 days, 12:33:04 old) https://review.opendev.org/863276 -- Checking name: DataCore CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DataCore_CI first seen: 2018-10-11 20:55:57 (1928 days, 5:09:33 old) https://review.opendev.org/593191 last seen: 2020-02-13 14:16:20 (1438 days, 11:49:10 old) https://review.opendev.org/707643 -- Checking name: DellEMC PowerMAX CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_PowerMAX_CI first seen: 2022-06-17 12:14:23 (583 days, 13:51:32 old) https://review.opendev.org/821745 last seen: 2023-11-29 12:13:36 (53 days, 13:52:19 old) https://review.opendev.org/902106 -- Checking name: DellEMC SC CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_SC_CI first seen: 2022-05-24 00:06:06 (608 days, 2:00:17 old) https://review.opendev.org/839257 last seen: 2023-03-26 19:21:14 (301 days, 6:45:09 old) https://review.opendev.org/877583 -- Checking name: DellEMC VNX CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_VNX_CI first seen: 2021-09-11 03:27:04 (862 days, 22:39:38 old) https://review.opendev.org/760199 last seen: 2022-05-26 21:42:33 (605 days, 4:24:09 old) https://review.opendev.org/842131 -- Checking name: DellEMC XtremIO CI - https://wiki.openstack.org/wiki/ThirdPartySystems/DellEMC_XtremIO_CI first seen: 2021-11-17 06:06:53 (795 days, 19:59:58 old) https://review.opendev.org/818037 last seen: 2022-04-11 17:06:22 (650 days, 9:00:29 old) https://review.opendev.org/836211 -- Checking name: Fungible Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Fungible_Storage_CI first seen: 2023-02-21 10:45:34 (334 days, 15:21:31 old) https://review.opendev.org/843493 last seen: 2023-05-25 11:17:36 (241 days, 14:49:29 old) https://review.opendev.org/880275 -- Checking name: Hedvig CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Hedvig_CI first seen: 2020-11-04 02:16:19 (1173 days, 23:50:53 old) https://review.opendev.org/761160 last seen: 2020-11-20 13:10:00 (1157 days, 12:57:12 old) https://review.opendev.org/762884 -- Checking name: HPE Nimble Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/HPE_Nimble_Storage_CI first seen: 2023-04-20 19:24:38 (276 days, 6:42:42 old) https://review.opendev.org/877755 last seen: 2023-07-31 10:12:19 (174 days, 15:55:01 old) https://review.opendev.org/886456 -- Checking name: HPE Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/HPE_Storage_CI first seen: 2016-07-21 05:02:38 (2740 days, 21:04:54 old) https://review.opendev.org/344766 last seen: 2016-08-09 22:53:51 (2721 days, 3:13:41 old) https://review.opendev.org/318737 -- Checking name: HPMSA CI - https://wiki.openstack.org/wiki/ThirdPartySystems/HPMSA_CI first seen: 2023-06-07 03:02:16 (228 days, 23:05:25 old) https://review.opendev.org/850002 last seen: 2023-12-05 15:15:09 (47 days, 10:52:32 old) https://review.opendev.org/900513 -- Checking name: Huawei FusionStorage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Huawei_FusionStorage_CI first seen: 2019-02-21 15:07:45 (1795 days, 11:00:03 old) https://review.opendev.org/635203 last seen: 2020-07-23 09:23:28 (1277 days, 16:44:20 old) https://review.opendev.org/742136 -- Checking name: Huawei Volume CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Huawei_Volume_CI first seen: 2018-02-09 08:03:20 (2172 days, 18:04:47 old) https://review.opendev.org/542700 last seen: 2018-06-12 10:12:22 (2049 days, 15:55:45 old) https://review.opendev.org/574508 -- Checking name: IBM GPFS CI - https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_GPFS_CI first seen: 2017-08-30 23:39:19 (2335 days, 2:28:56 old) https://review.opendev.org/499271 last seen: 2022-01-25 14:29:37 (726 days, 11:38:38 old) https://review.opendev.org/819011 -- Checking name: IBM Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_Storage_CI first seen: 2021-10-25 15:30:42 (818 days, 10:37:42 old) https://review.opendev.org/809518 last seen: 2023-07-11 09:37:45 (194 days, 16:30:39 old) https://review.opendev.org/880518 -- Checking name: Infortrend CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Infortrend_CI first seen: 2020-01-10 07:03:58 (1472 days, 19:04:35 old) https://review.opendev.org/694379 last seen: 2020-05-01 16:25:58 (1360 days, 9:42:35 old) https://review.opendev.org/722806 -- Checking name: INSPUR CI - https://wiki.openstack.org/wiki/ThirdPartySystems/INSPUR_CI first seen: 2019-08-13 20:31:35 (1622 days, 5:37:05 old) https://review.opendev.org/676274 last seen: 2020-06-09 02:34:51 (1321 days, 23:33:49 old) https://review.opendev.org/734395 -- Checking name: Intel RSD CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_RSD_CI first seen: 2020-08-22 20:40:00 (1247 days, 5:28:49 old) https://review.opendev.org/747540 last seen: 2020-09-30 20:50:30 (1208 days, 5:18:19 old) https://review.opendev.org/746267 -- Checking name: Kaminario K2 CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Kaminario_K2_CI first seen: 2019-09-03 21:12:51 (1601 days, 4:56:06 old) https://review.opendev.org/679785 last seen: 2020-05-02 20:21:51 (1359 days, 5:47:06 old) https://review.opendev.org/724548 -- Checking name: openstack lightbits - https://wiki.openstack.org/wiki/ThirdPartySystems/openstack_lightbits first seen: 2023-01-18 14:02:54 (368 days, 12:06:19 old) https://review.opendev.org/865429 last seen: 2023-10-30 15:55:42 (83 days, 10:13:31 old) https://review.opendev.org/792209 -- Checking name: LINBIT LINSTOR CI - https://wiki.openstack.org/wiki/ThirdPartySystems/LINBIT_LINSTOR_CI first seen: 2019-12-23 08:12:07 (1490 days, 17:57:14 old) https://review.opendev.org/700296 last seen: 2020-04-04 21:33:05 (1387 days, 4:36:16 old) https://review.opendev.org/717383 -- Checking name: MacroSAN Volume CI - https://wiki.openstack.org/wiki/ThirdPartySystems/MacroSAN_Volume_CI first seen: 2019-06-21 02:47:54 (1675 days, 23:21:27 old) https://review.opendev.org/666477 last seen: 2019-08-21 12:59:52 (1614 days, 13:09:29 old) https://review.opendev.org/674156 -- Checking name: Mellanox CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI first seen: 2021-12-02 22:17:29 (780 days, 3:51:59 old) https://review.opendev.org/733622 last seen: 2022-01-27 23:20:17 (724 days, 2:49:11 old) https://review.opendev.org/818830 -- Checking name: NetApp SolidFire CI - https://wiki.openstack.org/wiki/ThirdPartySystems/NetApp_SolidFire_CI first seen: 2022-01-07 03:00:03 (744 days, 23:09:43 old) https://review.opendev.org/796114 last seen: 2022-12-27 10:41:51 (390 days, 15:27:54 old) https://review.opendev.org/853126 -- Checking name: Nexenta CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Nexenta_CI first seen: 2023-05-18 19:46:37 (248 days, 6:23:16 old) https://review.opendev.org/881470 last seen: 2023-12-18 12:42:24 (34 days, 13:27:29 old) https://review.opendev.org/903883 -- Checking name: ProphetStor CI - https://wiki.openstack.org/wiki/ThirdPartySystems/ProphetStor_CI first seen: 2018-04-05 22:54:14 (2117 days, 3:15:54 old) https://review.opendev.org/559172 last seen: 2018-11-27 18:08:32 (1881 days, 8:01:36 old) https://review.opendev.org/603283 -- Checking name: qnap-ci - https://wiki.openstack.org/wiki/ThirdPartySystems/qnap-ci first seen: 2016-12-01 08:58:50 (2607 days, 17:11:33 old) https://review.opendev.org/313140 last seen: 2019-03-27 21:38:37 (1761 days, 4:31:46 old) https://review.opendev.org/648174 -- Checking name: Quobyte CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI first seen: 2020-08-05 14:17:31 (1264 days, 11:53:01 old) https://review.opendev.org/742491 last seen: 2020-10-26 22:12:30 (1182 days, 3:58:02 old) https://review.opendev.org/754728 -- Checking name: SandStone Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/SandStone_Storage_CI first seen: 2019-09-04 11:39:43 (1600 days, 14:30:51 old) https://review.opendev.org/679970 last seen: 2020-04-19 05:55:57 (1372 days, 20:14:37 old) https://review.opendev.org/720678 -- Checking name: Seagate CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Seagate_CI first seen: 2023-01-27 08:03:49 (359 days, 18:06:55 old) https://review.opendev.org/851640 last seen: 2023-05-25 22:32:18 (241 days, 3:38:26 old) https://review.opendev.org/884253 -- Checking name: Synology DSM CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Synology_DSM_CI first seen: 2020-09-04 18:45:57 (1234 days, 7:25:05 old) https://review.opendev.org/749996 last seen: 2020-11-20 08:17:25 (1157 days, 17:53:37 old) https://review.opendev.org/757082 -- Checking name: TOYOU TYDS CI - https://wiki.openstack.org/wiki/ThirdPartySystems/TOYOU_TYDS_CI first seen: 2021-11-20 16:22:53 (792 days, 9:48:15 old) https://review.opendev.org/818098 last seen: 2023-10-18 01:25:34 (96 days, 0:45:34 old) https://review.opendev.org/898600 -- Checking name: Veritas Access CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Veritas_Access_CI first seen: 2018-12-11 02:38:26 (1867 days, 23:32:48 old) https://review.opendev.org/624193 last seen: 2019-03-15 10:56:07 (1773 days, 15:15:07 old) https://review.opendev.org/643555 -- Checking name: Virtuozzo Storage CI - https://wiki.openstack.org/wiki/ThirdPartySystems/Virtuozzo_Storage_CI first seen: 2019-08-09 21:32:36 (1626 days, 4:38:47 old) https://review.opendev.org/664860 last seen: 2019-09-25 02:45:11 (1579 days, 23:26:12 old) https://review.opendev.org/639180

4 4

[kolla-ansible] [cinder] how to add 2nd storage?
by garcetto 30 Jan '24

30 Jan '24

good morning, how can i add a second storage (for example another ceph, or nfs...) to my openstack kolla ansible cluster? thank you.

3 5

[cinder][nova] server create boot volume choosing
by garcetto 30 Jan '24

30 Jan '24

good afternoon, i have multiple backend types, so also different volumes types; is there an option on "openstack server create" to also specify the volume type on instance creation time? thank you.

3 4

[kolla-ansible] Static haproxy configuration for manually deployed services
by Jan Wasilewski 29 Jan '24

29 Jan '24

Hi, I wanted to inquire about the possibility of configuring the haproxy service for a non-standard OpenStack service. Specifically, I'm referring to Vault, which I use as a backend for the Barbican service. I would like to configure the haproxy settings somewhat "statically," but I want this configuration to be applied during deployment with kolla-ansible. While inserting non-standard configurations for OpenStack services like Cinder or Barbican in the directory */etc/kolla/config/<openstack_service>/<openstack_service.conf>* works, the same approach doesn't seem to work for haproxy. I have created a configuration for vault.cfg as outlined in [1], but when executing: kolla-ansible -i multinode --tags common,haproxy deploy the configured settings are not being read into the haproxy settings. Am I doing something wrong, or is this functionality not possible in this manner, requiring a different configuration approach? I would appreciate any advice and guidance on this matter. Best regards, /JW References: [1] https://paste.openstack.org/show/bU3ytwRvAopM78S7lg34/

3 3

[kolla-ansible] remove a service and container
by garcetto 29 Jan '24

29 Jan '24

good morning, is it possible to remove a service with kolla-ansible? got the same problems as here ( https://stackoverflow.com/questions/64930136/what-is-the-proper-way-to-remo…) and seems there is no solution ( https://bugs.launchpad.net/kolla-ansible/+bug/1874044) thank you.

2 1

[tc] Technical Committee Meeting Jan 30, 2024 at 1800UTC
by Jay Faulkner 29 Jan '24

29 Jan '24

Hi all, The next meeting of the Technical Committee will be tomorrow, Tuesday January 30 at 1800 UTC in #openstack-tc on OFTC. Please see the proposed agenda below: Agenda - Roll call - Follow up on tracked action items - No action items from Jan 24 meeting. - Gate health check - Implementation of Unmaintained branch statuses - project team guide change: https://review.opendev.org/c/openstack/project-team-guide/+/897505 (in HTML <https://45faea0ad451d95614b7-e39b4e99c90af072f68eb1bcdd078a04.ssl.cf2.rackc…> ) - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

Cinder multi availability_zone, nova lookup problems
by Henrik Hansen 29 Jan '24

29 Jan '24

Good evening, we are currently deploying openstack in a two AZ setup, in this setup we have two different SAN FC Boxes which are only reachable via the corresponding zone. Means, we have two cinder instances, each one is configured with a backend service towards the storage. In cinder.conf [storage] we have backend_availability_zone set, towards the correct zone name. If i create two bootable volumes, cinderis selecting the right cinder-schueduler with the right storage: (venv-kolla)# openstack volume create --size 10 --image cirros --availability-zone DUS --bootable DUS_1 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | DUS | | bootable | false | | consistencygroup_id | None | | created_at | 2024-01-23T22:22:21.979063 | | description | None | | encrypted | False | | id | 217943c3-44dd-4a8c-aad7-2ab33b17bab3 | | migration_status | None | | multiattach | False | | name | DUS_1 | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | __DEFAULT__ | | updated_at | None | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | +---------------------+--------------------------------------+ (venv-kolla)# openstack volume create --size 10 --image cirros --availability-zone LEV --bootable LEV_1 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | LEV | | bootable | false | | consistencygroup_id | None | | created_at | 2024-01-23T22:23:12.327244 | | description | None | | encrypted | False | | id | 7850da99-43d0-4b58-9134-a7e7bc930cf0 | | migration_status | None | | multiattach | False | | name | LEV_1 | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | __DEFAULT__ | | updated_at | None | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | +---------------------+--------------------------------------+ if i create servers with boot-from-volume and a availability-zone, the job failed. (venv-kolla)# openstack server create --image cirros --boot-from-volume 10 --network fw --flavor m1.tiny --availability-zone DUS DUS1 +-------------------------------------+--------------------------------------+ | Field | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | DUS | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | gKsNQTfC6vYe | | config_drive | | | created | 2024-01-23T22:29:47Z | | flavor | m1.tiny (1) | | hostId | | | id | a838b078-cda0-47de-bf5d-0b6cc632425c | | image | N/A (booted from volume) | | key_name | None | | name | DUS1 | | progress | 0 | | project_id | e435c2936cbf4eb9abc38a48181ab9bf | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2024-01-23T22:29:47Z | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | | volumes_attached | | +-------------------------------------+--------------------------------------+ (venv-kolla)# openstack server create --image cirros --boot-from-volume 10 --network fw --flavor m1.tiny --availability-zone LEV LEV1 +-------------------------------------+--------------------------------------+ | Field | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | LEV | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | L6vDvCoevTBC | | config_drive | | | created | 2024-01-23T22:30:11Z | | flavor | m1.tiny (1) | | hostId | | | id | 2434f84f-08f3-4e8d-8c8d-67a6b78f2cbe | | image | N/A (booted from volume) | | key_name | None | | name | LEV1 | | progress | 0 | | project_id | e435c2936cbf4eb9abc38a48181ab9bf | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2024-01-23T22:30:11Z | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | | volumes_attached | | +-------------------------------------+--------------------------------------+ in cinder-scheduler.log i see following: Task 'cinder.scheduler.flows.create_volume.ExtractSchedulerSpecTask;volume:create' (93b2aa0f-5cdb-4f13-abdf-416c2b226917) transitioned into state 'SUCCESS' from state 'RUNNING' with result '{'request_spec': RequestSpec(CG_backend=<?>,availability_zones=['nova'] ... The creation of a bootable volume, results in the following log entry: Task 'cinder.scheduler.flows.create_volume.ExtractSchedulerSpecTask;volume:create' (7d6130e8-f9d9-4d3b-bca1-e899690e7855) transitioned into state 'SUCCESS' from state 'RUNNING' with result '{'request_spec': RequestSpec(CG_backend=<?>,availability_zones=['LEV']... So from my understanding, the create request towards nova, results in AvailabilityZone=nova, which the cinder AvailabilityZoneFilter can't handle. Does someone have a idea, how i can fix this behaviour? Thanks in advance! -- Mit freundlichen Grüßen Henrik Hansen

2 1

[devstack] how to change from ovn to ovs?
by garcetto 29 Jan '24

29 Jan '24

good morning, devstack by default install ovn (and in particular l3 ovn agent), BUT i would like to install fwaas v2, that does NOT support ovn, so i would like to set devstack to use plain old ovs, IS IT POSSIBLE? thank you.

3 3

[masakari] How to add blueprint link on masakari meeting agenda?
by 김도균 29 Jan '24

29 Jan '24

3 2

VMs shut themselves down
by Karera Tony 28 Jan '24

28 Jan '24

Hello Team, I have an openstack environment with 4 compute Nodes however yesterday out of the blue, the Instances on one of the compute nodes started shutting themselves down. Then I realized the the compute service was disabled when I checked in Horizon. I enabled it and restarted the instances and all was well but I cant figure out what caused it. I have attached the nova_compute logs here incase someone would like to support https://paste.openstack.org/show/bxqpgjvqT3DlOYWoeejc/ Regards Tony Karera

3 6

[tc][releases][ptl][all] Yoga transition to 'Unmaintained' status
by Brian Rosmaita 26 Jan '24

26 Jan '24

Hello Stackers, The release team has proposed patches to all projects to transition Yoga to Unmaintained status: https://review.opendev.org/q/topic:%22yoga-unmaintained%22 These patches tag stable/yoga with 'yoga-eom' and create the unmaintained/yoga branch. Here is the key takeaway from this email: PLEASE DO NOT MERGE ANYTHING INTO stable/yoga in the short period after it's been tagged yoga-eom and before the stable/yoga branch is deleted. Other to-dos/info: Abandon any open reviews on stable/yoga immediately. (The release team called for final yoga releases back in November 2023 [0].). Feel free to leave a note that abandoned patches can be re-proposed to unmaintained/yoga if the proposer is still interested. This will speed up the branch deletion process. Otherwise, the release team will have to abandon reviews before stable/yoga can be deleted, which obviously will dump more work on the release team that they'll have to squeeze in around all their normal activities. The stable/yoga branches will be deleted by the release team. The global openstack-unmaintained-core team will, by default, handle maintenance of unmaintained/yoga branches (both CI and merging patches). If your project wants to have its own <project>-unmaintained-core team, it's allowed, but you have to create it yourself. For an example, see https://review.opendev.org/c/openstack/project-config/+/902796 More information about Unmaintained branches is contained in this patch to the project-team-guide: https://review.opendev.org/c/openstack/project-team-guide/+/897505 (Given that this is the first time we're doing the transition-to-Unmaintained process, it would be helpful for all interested people to look at the above patch and leave comments and/or requests for clarifications.) Thanks for your attention to this email! [0] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

Instances Shutting down themselves
by Karera Tony 26 Jan '24

26 Jan '24

Hello Team, For some reason today morning VMs on one of my compute Nodes started shutting down themselves. When I checked in Horizon, I realized that that particular Compute was disabled and I enabled it. I restarted the Instances and all is well now. I have attached the Logs for nova-compute in case someone would like to help. Regards Tony Karera

2 1

[masakari] [masakari-monitors] Feature to monitor hosts by kubernetes
by 김도균 25 Jan '24

25 Jan '24

1 0

[masakari] [masakari-monitors] Feature to monitor hosts by kubernetes
by 김도균 25 Jan '24

25 Jan '24

1 0

[masakari] [masakari-monitors] Feature to monitor hosts by kubernetes
by d0gyun.kim＠samsung.com 25 Jan '24

25 Jan '24

Hi team masakari I'm do-gyun kim working on SAMSUNG SDS in Seoul. We are using openstack on kubernetes and also masakari for HA. We have developed a function internally to masakari-monitors for k8s-native openstack and want to contribute! blueprint: https://blueprints.launchpad.net/masakari/+spec/host-monitors-by-kubernetes

1 0

[swift][acl][s3api] Manage Container ACL
by Thiago De Moraes Teixeira 25 Jan '24

25 Jan '24

Hi, How can I grant access for other users in my bucket, using s3api, using tempauth (locally tests) and keystone? With: *aws s3api put-bucket-acl --bucket bucket --grant-full-control id=test:tester* (tempauth) I can confirm that this acl was updated inside the container metadata, in container.db, like this *"X-Container-Sysmeta-S3Api-Acl": [ "{\"Owner\":\"thiago:th\",\"Grant\":[{\"Permission\":\"FULL_CONTROL\",\"Grantee\":\"test:tester\"}]}", "1706210273.48975" ]* But when authenticated by test:tester, I can't read/write to that container. -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

1 0

[neutron][antelope] neutron has error "/neutron-rootwrap: Unauthorized command: ip netns" after switch from openvswitch to linuxbridge
by dieter.dorra＠hsnr.de 25 Jan '24

25 Jan '24

Initially I've installed Antelope with openvswitch as described in the docs, but after switching back to linuxbridge neutron fails with errors on control: neutron-l3-agent.log: 2024-01-23 21:54:07.364 192544 ERROR neutron_lib.callbacks.manager neutron_lib.exceptions.ProcessExecutionError: Exit code: 99; Cmd: ['ip', 'netns', 'exec', 'qrouter-ce46ba37-9b08-4c08-a31c-0d38ff3d1438', 'env', 'PROCESS_TAG=haproxy-ce46ba37-9b08-4c08-a31c-0d38ff3d1438', 'haproxy', '-f', '/var/lib/neutron/ns-metadata-proxy/ce46ba37-9b08-4c08-a31c-0d38ff3d1438.conf']; Stdin: ; Stdout: ; Stderr: /usr/bin/neutron-rootwrap: Unauthorized command: ip netns exec qrouter-ce46ba37-9b08-4c08-a31c-0d38ff3d1438 env PROCESS_TAG=haproxy-ce46ba37-9b08-4c08-a31c-0d38ff3d1438 haproxy -f /var/lib/neutron/ns-metadata-proxy/ce46ba37-9b08-4c08-a31c-0d38ff3d1438.conf (no filter matched) 2024-01-23 21:54:07.364 192544 ERROR neutron_lib.callbacks.manager neutron-dhcp-agent.log 2024-01-23 21:58:38.754 192061 ERROR neutron.agent.linux.utils [None req-64a0a2f6-ec71-4288-900f-f86f0bd903e0 - - - - - -] Exit code: 99; Cmd: ['ip', 'netns', 'exec', 'qdhcp-ce84c378-6260-455f-8816-bb1d640aa42c', 'env', 'PROCESS_TAG=haproxy-ce84c378-6260-455f-8816-bb1d640aa42c', 'haproxy', '-f', '/var/lib/neutron/ns-metadata-proxy/ce84c378-6260-455f-8816-bb1d640aa42c.conf']; Stdin: ; Stdout: ; Stderr: /usr/bin/neutron-rootwrap: Unauthorized command: ip netns exec qdhcp-ce84c378-6260-455f-8816-bb1d640aa42c env PROCESS_TAG=haproxy-ce84c378-6260-455f-8816-bb1d640aa42c haproxy -f /var/lib/neutron/ns-metadata-proxy/ce84c378-6260-455f-8816-bb1d640aa42c.conf (no filter matched) Any help appreciated.

2 2