- openstack-discuss - lists.openstack.org

[ironic] Call for maintainers: terraform-provider-ironic
by Dmitry Tantsur 25 Jul '24

25 Jul '24

Hi folks! In OpenShift, we used to use https://github.com/openshift-metal3/terraform-provider-ironic to drive Ironic and Inspector during the initial installation process before the control plane is up. Now that we have moved away from Terraform for this purpose, the project is on minimal support with the intention of completely abandoning it once no stable versions of OpenShift use it to provision the control plane. Are there any parties interested in maintaining terraform-provider-ironic after that point? It supports several features like inspection, BIOS settings, RAID. It does not, to the best of my knowledge, support Keystone authentication and has not been migrated away from Inspector. Dmitry

1 0

[cinder] No meeting today (7/24)
by Jon Bernard 24 Jul '24

24 Jul '24

Hello all, I failed in my effort to secure adequate childcare today, so I need to cancel today's meeting. Hope to see you in the next one. -- Jon

1 0

[horizon][puppet-openstack] Proper Python snippets placement
by Francesco Di Nucci 24 Jul '24

24 Jul '24

Hello, some time ago I found that on EL9 Horizon searches for extra Python snippets in "/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.d", while puppet-horizon places dashboards snippets in "/etc/openstack-dashboard/local_settings.d", so these are not loaded. At the same time, "/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py" is a symlink to "/etc/openstack-dashboard/local_settings". Of the following, what should be adopted as proper approach on a machine? * Having symlinks to /etc/openstack-dashboard for both local_settings.py and local_settings.d * Editing files in /usr/share/openstack-dashboard without having symlinks * Using a symlink for local_settings.py but placing snippets under /usr/share/openstack-dashboard Best regards -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

4 4

[kolla-ansible]Material choices for ephemerals
by Franck VEDEL 24 Jul '24

24 Jul '24

Hello. I would like your opinion regarding a hardware configuration and my Openstack cluster project. I have the possibility of purchasing 6 servers to build this cluster for students, my current Openstack being too small. I have a proposition from the manufacturer (DELL): 6 servers with characteristics per server: - BOSS-N1 controller card + with 2 M.2 960GB (RAID 1) - 5 x 3.84TB Data Center NVMe Read Intensive AG Drive U2 Gen4 with Carrier - 12 x 64GB RDIMM, 4800MT/s Dual Rank My problem is: BOSS is used to install the system (Ubuntu 22.04 in my case). But, various tests on a small cluster with SSD disks showed that the solution with ephemerals was really the most interesting for what I want to do. Problem: I don't believe you can have the system on the BOSS and the ephemerals on the NVMe disks. So my questions are: 1) am I wrong and ephemerals are possible on NVMe (I use kolla-ansible to deploy, I haven't seen how to do that)? 2) or the solution is to create a Ceph cluster on the NVME of the 6 servers 3) or a better solution exists Thank you in advance if you can help me make these choices. Franck

2 2

Unrestricted AC Access Rules: "You must upgrade keystonemiddleware on all services"
by openstack＠tr.id.au 24 Jul '24

24 Jul '24

Hey there, I'm interested in creating an unrestricted Application Credential (AC) which is still constrained by Access Rules. A use could be allowing admins to use automation to generate read-only ACs for various purposes. The AC for automatically generating other ACs would need to be unrestricted, but should still only have the minimal privileges required to create its children. However, when attempting this with multiple versions of keystone, including 2024.1, I get the following error in the keystone service log: ``` Attempted to use application credential access rules with a middleware that does not understand them. You must upgrade keystonemiddleware on all services that accept application credentials as an authentication method.: NoneType: None ``` A minimal way to reproduce this: 1. Install keystone according to https://docs.openstack.org/keystone/latest/install/keystone-install-ubuntu.…. (I've also tested with keystone running in a virtualenv and in a kolla container.) 2. Generate a "parent" AC using the bootstrap admin: `openstack application credential create --max-width 120 --role admin --access-rules '[ { "path": "/v3/**", "method": "POST", "service": "identity" }, { "path": "/v3/**", "method": "GET", "service": "identity" } ]' --expiration '2024-07-31T23:59:59' --unrestricted test_unrestricted` (This gives expected output, including an AC id and secret.) 3. In another terminal, load the parent AC and then try to generate the child: `openstack application credential create --max-width 120 --role admin --access-rules '[ { "path": "/v3/**", "method": "GET", "service": "identity" } ]' --expiration '2024-07-31T23:59:59' test_read_only`. (This returns `Invalid application credential: Cannot create an application credential with unassigned role` in the client, as well as the earlier error about upgrading middleware in keystone service log.) I've tested that the parent/unrestricted AC *can* generate the child successfully when the parent does *not* have Access Rules. I didn't see anything about these errors or constraints when going through the application credential documentation (eg https://docs.openstack.org/keystone/latest/user/application_credentials.html) or in a web search, or in a search of the openstack-discuss archives. I may raise a bug report/feature request, but before I do that, I just wondered if I have likely overlooked some possible extra configuration or documentation which could explain what I've done wrong? Alternatively, if this were raised as a feature request, would it likely be supported, or would the functionality I'm imagining be too difficult or impossible to implement? Cheers, Tim

1 0

Scheduler and filters
by Gk Gk 23 Jul '24

23 Jul '24

Hi, Can anyone tell me the difference between the schedulers and filters in nova. As per what I grasped, it seems we have the same type of weighers like schedulers. Then what's the difference ? Please explain.. Thanks Y.G

3 2

[OSSA-2024-002] OpenStack Nova: Incomplete file access fix and regression for QCOW2 backing files and VMDK flat descriptors (CVE-2024-40767)
by Jeremy Stanley 23 Jul '24

23 Jul '24

================================================================== OSSA-2024-002: Incomplete file access fix and regression for QCOW2 backing files and VMDK flat descriptors ================================================================== :Date: July 23, 2024 :CVE: CVE-2024-40767 Affects ~~~~~~~ - Nova: <27.4.1, >=28.0.0 <28.2.1, >=29.0.0 <29.1.1 Description ~~~~~~~~~~~ Arnaud Morin (OVH) reported a vulnerability in Nova. By supplying a raw format image which is actually a specially crafted QCOW2 image with a backing file path or VMDK flat image with a descriptor file path, an authenticated user may convince systems to return a copy of the referenced file’s contents from the server resulting in unauthorized access to potentially sensitive data. All Nova deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/924734 (2023.1/antelope) - https://review.opendev.org/924733 (2023.2/bobcat) - https://review.opendev.org/924732 (2024.1/caracal) - https://review.opendev.org/924731 (2024.2/dalmatian) Credits ~~~~~~~ - Arnaud Morin from OVH (CVE-2024-40767) References ~~~~~~~~~~ - https://launchpad.net/bugs/2071734 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-40767 Notes ~~~~~ - The patches linked above should apply cleanly to the public state of their respective branches at time of disclosure, and depend on some commits which merged after the `OSSA-2024-001 <https://security.openstack.org/ossa/OSSA-2024-001.html>`_ fixes as well as the final states of the Nova changes linked from that advisory (those did see some minor adjustments before they merged). - The QCOW2 issue is due to an incomplete fix in OSSA-2024-001 affecting systems where the ``use_cow_images`` configuration option is disabled, while the VMDK issue is a regression of the earlier `OSSA-2023-002 <https://security.openstack.org/ossa/OSSA-2023-002.html>`_ vulnerability reintroduced by the new implementation in OSSA-2024-001. Both problems were identified in the final hours before OSSA-2024-001 publication but, due to time constraints, were redacted from that bug and moved to a separate report. - Neither the methods introduced in these patches nor the fixes for OSSA-2024-001 are capable of blocking malicious images which are already resident in Nova's cache. At this time we do not have useful operator guidance for identifying and removing such existing images from the cache but strongly caution, if you do attempt to use the qemu-img tool to find them, to make sure you're using a version of it patched for `QEMU CVE-2024-4467 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-4467>`_. -- Jeremy Stanley OpenStack Vulnerability Management Team

1 0

[MAGNUM] Fedora Core OS include GPU drivers
by Oliver Weinmann 23 Jul '24

23 Jul '24

Hi all, I'm running OpenStack 2023.2 (Bobcat) deployed with Kolla-Ansible. Currently I'm struggling to get the NVIDIA drivers to work in a FCOS 35 image. I know FCOS 35 is EOL and outdated, but for a K8s 1.21.11 cluster it is the only version that still works with Magnum. So far I managed to get the GPU Passthrough working for two NVIDIA Tesla T4 GPUs. I have attached the GPUs to a Ubuntu instance and ran geekbench without any issues. Then I tried to install the latest NVIDIA drivers in FCOS 35 by running: sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$ (rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$ (rpm -E %fedora).noarch.rpm systemctl reboot rpm-ostree install --apply-live akmod-nvidia akmods pciutils rpmdevtools xorg-x11-drv-nvidia-cuda It fails on: rpm-ostree install --apply-live akmod-nvidia akmods pciutils rpmdevtools xorg-x11-drv-nvidia-cuda I guess the binaries are no longer hosted? Running the same on FCOS 36 and latest FCOS 40 works fine. Next I have taken new images from the FCOS instances with the NVIDIA driver. openstack server image create --name fedora_coreos_36_nvidia_cuda fedora_coreos_35_latest_no_update --wait This takes ages but anyway I can successfully deploy new instances from the images with my gpu flavor and the GPU is working fine. Again tested with geekbench. But now when adding new K8s worker nodes in a fresh nodegroup on an existing cluster 1.21.11 cluster the nodes are not joining the cluster: openstack coe nodegroup create \ --node-count 1 \ --role worker-gpu \ --flavor gpuflavor \ --image fedora_coreos_36_nvidia_cuda \ $CLUSTER_ID worker-gpu But I know from the past that FCOS 35 was the only version that was working fine with K8s 1.21.11. So I tried with FCOS 35 and this works fine, but unfortunately without the NVIDIA drivers. So maybe the problem is related to this and I need to get FCOS 35 working? Or a newer FCOS version? I'm also not sure if this is the best way of doing this. Maybe there is already a ready FCOS image with nvidia drivers? I can find lots of outdated information on the internet. Generally I tend to use Vexxhost CAPI from now on, which works great. This is really just a one off attempt to have a working NVIDIA T4 GPU in a K8s 1.21.11 cluster. Best Regards, Oliver

1 0

[Neutron] - Floating ip allocation in a specific subnet
by MIchele Delli Veneri 23 Jul '24

23 Jul '24

Dear all, My network setup includes a single external network (ext_vlan) with 2 subnets: 10.x.x.0/24 and 193.x.x.0/24. Is there a way to setup the allocation logic such as that given a project, all floating ips in the project are always allocated on one of the two subnets unless the subnet is explicited (as it may happen through the Openstack CLI or the admin horizon interface)? The ideal outcome would be, given the project test-project and test-project2 , that running openstack floating ip create —project test-project ext_vlan always allocate the floating ip on the 193.x.x subnet while openstack floating ip create —project test-project2 ext_vlan always allocates the floating ip on the 10.x.x. subnet. Best regards, Michele

4 4

Not able to find updated repos
by Ashok Thipe 23 Jul '24

23 Jul '24

Hi, We need to install latest community version of openstack but we are unable to get updated repositories. could anyone please help. With regards, Ashok Thipe

3 4