August 2022 - openstack-discuss - lists.openstack.org

Security vulnerabilities in Horizon dashboard | Openstack Wallaby | Tripleo | Openstack Horizon
by Swogat Pradhan 09 Aug '22

09 Aug '22

Hi, I am setting up an openstack wallaby cloud for a client using tripleo. After setting everything up the client ran a WEB scan and found some vulnerabilities (attached snapshot for reference). Can you please guide me on how to fix these vulnerabilities in the dashboard service? With regards, Swogat pradhan

2 3

[openstack-ansible] Meeting on August 16 is cancelled
by Dmitriy Rabotyagov 09 Aug '22

09 Aug '22

Hi everyone, Since several core participants won't be able to present at the meeting it was decided to cancel the Team meeting on 16th of August 2022.

1 0

[nova] Review guide for PCI tracking for Placement patches
by Balazs Gibizer 09 Aug '22

09 Aug '22

Hi Nova, The first batch of patches are up for review for the PCI tracking for Placement feature. These mostly covers two aspects of the spec[1]: 1) renaming [pci]passthrough_whitelist to [pci]device_spec 2) pci inventory reporting to placement, excluding existing PCI allocation healing in placement This covers the first 4 sub chapters of Proposed Change chapter of the spec[1] up until "PCI alias configuration". I noted intentional deviations from the spec in the spec review [2] and I will push a follow up to the spec at some point fixing those. I tried to do it in small steps hence the long list of commits[3]: #2) pci inventory reporting to placement, excluding existing PCI allocation healing in placement 5827d56310 Stop if tracking is disable after it was enabled before a4b5788858 Support [pci]device_spec reconfiguration 10642c787a Reject devname based device_spec config b0ad05fb69 Ignore PCI devs with physical_network tag f5a34ee441 Reject mixed VF rc and trait config c60b26014f Reject PCI dependent device config 5cf7325221 Extend device_spec with resource_class and traits eff0df6a98 Basics for PCI Placement reporting #1) renaming [pci]passthrough_whitelist to [pci]device_spec adfe34080a Rename whitelist in tests ea955a0c15 Rename exception.PciConfigInvalidWhitelist to PciConfigInvalidSpec 55770e4c14 Rename [pci]passthrough_whitelist to device_spec There is a side track branching out from "adfe34080a Rename whitelist in tests" to clean up the device spec handling[4]: 514500b5a4 Move __str__ to the PciAddressSpec base class 3a6198c8fb Fix type annotation of pci.Whitelist class f70adbb613 Remove unused PF checking from get_function_by_ifname b7eef53b1d Clean up mapping input to address spec types 93bbd67101 Poison /sys access via various calls in test 467ef91a86 Remove dead code from PhysicalPciAddress 233212d30f Fix PciAddressSpec descendants to call super.__init__ ad5bd46f46 Unparent PciDeviceSpec from PciAddressSpec cef0d2de4c Extra tests for remote managed dev spec 2fa2825afb Add more test coverage for devname base dev spec adfe34080a Rename whitelist in tests This is not a mandatory part of the feature but I think they improve the code in hand and even fixing some small bugs. I will continue with adding allocation healing for existing PCI allocations. Any feedback is highly appreciated. Cheers, gibi [1] https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-dev… [2] https://review.opendev.org/c/openstack/nova-specs/+/791047 [3] https://review.opendev.org/q/topic:bp/pci-device-tracking-in-placement [4] https://review.opendev.org/q/topic:bp/pci-device-spec-cleanup

1 2

[publiccloud-sig] A new start for Public Cloud SIG
by Tobias Rydberg 09 Aug '22

09 Aug '22

Hi everyone, In Berlin it became clear that there is a big interest in restarting the Public Cloud SIG. Thank you all for your contributions in that forum session [0] and the interest in participating in the work of this SIG. A lot of good ideas of what we should focus on was identified, with a clear focus of interoperability and standardization, to make the experience of using OpenStack as an end-user even better. Standardization of images and flavors - naming, metadata etc - being one of them, working closely with InterOp WG regarding the checks and governance of the OpenStack Powered Program another. The ultimate goal could be to reach a state where it is possible to start to federate between the public clouds, but for that to be possible on a more global scale we need to start with aligning the simple things. To kick this off, we will start with bi-weekly IRC meetings again, shape the goals kick of some work towards identified goals. Since we have an IRC channel (#openstck-publiccloud) my suggestion is that we will start there. Let's decide on suggestions for day and time for our bi-weekly meetings during the kick off meeting. Kick off meeting =========== When: Wednesday 10th of August at 1400 UTC Where: IRC in channel #openstack-publiccloud I created an etherpad for our first meeting [1], feel free to add items to the agenda or other suggestions on goals etc that you might have prior to the meeting. Hope to see at IRC in August! [0] https://etherpad.opendev.org/p/berlin-summit-future-public-cloud-sig [1] https://etherpad.opendev.org/p/publiccloud-sig-kickoff BR, Tobias Rydberg

2 2

[announcement] [debian] Debian Buster with OpenStack Rocky will receive LTS support
by Thomas Goirand 08 Aug '22

08 Aug '22

Hi! After some discussion with the folks taking care of the Debian LTS project, we decided that we will attempt to support OpenStack Rocky, running on Debian 10 (aka: Buster), for another 2 years, together with the rest of the distribution. In the past, we decided that we wouldn't do it, and that OpenStack would be part of the list of unsupported packages, because it was too difficult to maintain. However, it is my opinion that this has changed, because: - The codebase is evolving slower - I do have all the tooling to re-do a Rocky deployment if needed - There's a lot less CVE per year than it used to be (10 years ago, it was 1 every 2 weeks on average, now we have like 2 grave issue per year...). - I'm confident that if there's a grave issue, I'll be able to find help from the this wonderful community (it happened in the past...). Also, some sponsors of the Debian LTS project are actually running OpenStack Rocky on Debian. So it makes sense to help them. It is to be noted that I will not be the person doing the actual security backports, but I'll be there in case the person doing it needs help from me (for example, to do a deployment and manual regression testing). Hoping this will help OpenStack users running on Debian, Cheers, Thomas Goirand (zigo)

1 0

[all] Automatic update of Python jobs in Zuul project configuration
by Pierre Riteau 08 Aug '22

08 Aug '22

Hello, A patch submitted to python-blazarclient by yoctozepto [1] made me realise the automatic change of Python jobs from yoga to zed missed various repositories [2], mostly python clients. Is there a reason for this? Also, one can easily find projects which are using even older job templates (xena or earlier). Thanks, Pierre Riteau (priteau) [1] https://review.opendev.org/c/openstack/python-blazarclient/+/851903 [2] https://codesearch.openstack.org/?q=openstack-python3-yoga-jobs&i=nope&lite…

3 6

[kolla-ansible] why does not the bootstrap create the docker bridge?
by wodel youchi 08 Aug '22

08 Aug '22

Hi, The bootstrap installs docker but it does not create the docker bridge, why? Regards.

2 1

[Oslo] IRC meeting.
by Daniel Mats Niklas Bengtsson 08 Aug '22

08 Aug '22

Hi there, I'm sorry, I was on vacation and then I had personal problems. We are still in the summer period and I think there are still people on vacation, I suggest resuming meetings in September. What do you think?

1 0

[neutron] Bug Deputy Report August 01 - 07
by Elvira Garcia Ruiz 08 Aug '22

08 Aug '22

Hi, I was the bug deputy last week. Find the summary below: High: ------- - [ovn]router_interface port probability cannot be up https://bugs.launchpad.net/neutron/+bug/1983530 Fix: https://review.opendev.org/c/openstack/neutron/+/851997 - l2_pop does unnecessary db fetches for incompatible network types https://bugs.launchpad.net/neutron/+bug/1983558 Fix: https://review.opendev.org/c/openstack/neutron/+/852089 Medium: ----------- - [OVN] Old DNS servers are served by DHCP after dns_servers option is updated https://bugs.launchpad.net/neutron/+bug/1983270 Assigned to me Low: ------- - Neutron should clean up ACLs in OVN NB DB when a remote security group is deleted https://bugs.launchpad.net/neutron/+bug/1983600 Unassigned Kind regards! Elvira

1 0

[Cinder][NFS][Openstack-Ansible]
by Dave Hall 08 Aug '22

08 Aug '22

Hello, I seem to have gotten myself in a bit of a mess trying to set up Cinder with an NFS back-end. After working with Glance and NFS, I started on Cinder. I noticed immediately that there weren't any NFS mounts in the Cinder-API containers like there were in the Glance-API containers. Also that there were no NFS packages in the Cinder-API containers. In reading some Cinder documentation, I also got the impression that each Cinder host/container needs to have its own NFS store. Pawing through the playbooks and documentation I saw that unlike Glance, Cinder is split into two pieces - Cinder-API and Cinder-Volume. I found cinder-volume.yml.example in env.d, activated it, and created Cinder-Volume containers on my 3 infra hosts. I also created 3 separate NFS shares and changed the storage-hosts section of my openstack_user_config.yml accordingly. After this I found that while I was able to create volumes, the prep_volume part of launching an instance was failing. Digging in, I found: # openstack volume service list +------------------+-------------------------------------------------------+------+---------+-------+----------------------------+ | Binary | Host | Zone | Status | State | Updated At | +------------------+-------------------------------------------------------+------+---------+-------+----------------------------+ | cinder-volume | C6220-9@nfs_volume | nova | enabled | down | 2022-07-23T02:46:13.000000 | | cinder-volume | C6220-10@nfs_volume | nova | enabled | down | 2022-07-23T02:46:14.000000 | | cinder-volume | C6220-11@nfs_volume | nova | enabled | down | 2022-07-23T02:46:14.000000 | | cinder-scheduler | infra36-cinder-api-container-da8e100f | nova | enabled | up | 2022-08-06T13:29:10.000000 | | cinder-scheduler | infra38-cinder-api-container-27219f93 | nova | enabled | up | 2022-08-06T13:29:10.000000 | | cinder-scheduler | infra37-cinder-api-container-ea7f847b | nova | enabled | up | 2022-08-06T13:29:10.000000 | | cinder-volume | C6220-9@nfs_volume1 | nova | enabled | up | 2022-08-06T13:29:10.000000 | | cinder-volume | infra37-cinder-volumes-container-5b9635ad@nfs_volume | nova | enabled | down | 2022-08-04T18:32:53.000000 | | cinder-volume | infra36-cinder-volumes-container-77190057@nfs_volume1 | nova | enabled | down | 2022-08-06T13:03:03.000000 | | cinder-volume | infra38-cinder-volumes-container-a7bcfc9b@nfs_volume | nova | enabled | down | 2022-08-04T18:32:53.000000 | | cinder-volume | infra37-cinder-volumes-container-5b9635ad@nfs_volume2 | nova | enabled | down | 2022-08-06T13:03:05.000000 | | cinder-volume | C6220-10@nfs_volume2 | nova | enabled | up | 2022-08-06T13:29:10.000000 | | cinder-volume | C6220-11@nfs_volume3 | nova | enabled | up | 2022-08-06T13:29:10.000000 | | cinder-volume | infra38-cinder-volumes-container-a7bcfc9b@nfs_volume3 | nova | enabled | down | 2022-08-06T13:03:03.000000 | +------------------+-------------------------------------------------------+------+---------+-------+----------------------------+ Thinking I could save this, I used containers-lxc-destroy.yml to destroy my cinder-volumes containers and deactivated cinder-volume.yml.example. Then I ran setup-hosts.yml, which has restored the cinder-volumes containers even though is_metal: false has been removed. Clearly a stronger intervention will be required. I would like to fully get rid of the cinder-volumes containers and go back to an is_metal: true scenario. I also need to get rid of the unnumbered nfs_volume referenes, which I assume are in some cinder config file somewhere. Below is a clip from my openstack_user_config.yml: storage_hosts: infra36: ip: 172.29.236.36 container_vars: cinder_backends: nfs_volume1: volume_backend_name: NFS_VOLUME1 volume_driver: cinder.volume.drivers.nfs.NfsDriver nfs_mount_options: "rsize=65535,wsize=65535,timeo=1200,actimeo=120" nfs_shares_config: /etc/cinder/nfs_shares_volume1 shares: - { ip: "172.29.244.27", share: "/NFS_VOLUME1" } infra37: ip: 172.29.236.37 container_vars: cinder_backends: nfs_volume2: volume_backend_name: NFS_VOLUME2 volume_driver: cinder.volume.drivers.nfs.NfsDriver nfs_mount_options: "rsize=65535,wsize=65535,timeo=1200,actimeo=120" nfs_shares_config: /etc/cinder/nfs_shares_volume2 shares: - { ip: "172.29.244.27", share: "/NFS_VOLUME2" } infra38: ip: 172.29.236.38 container_vars: cinder_backends: nfs_volume3: volume_backend_name: NFS_VOLUME3 volume_driver: cinder.volume.drivers.nfs.NfsDriver nfs_mount_options: "rsize=65535,wsize=65535,timeo=1200,actimeo=120" nfs_shares_config: /etc/cinder/nfs_shares_volume3 shares: - { ip: "172.29.244.27", share: "/NFS_VOLUME3" } Any advice would be greatly appreciated. Thanks. -Dave -- Dave Hall Binghamton University kdhall(a)binghamton.edu

4 8