May 2023 - openstack-discuss - lists.openstack.org

swift container retention
by Geert Geurts 05 Jun '23

05 Jun '23

Hallo, I've gotten the assignment to implement a backup solution using openstack swift containers. What we want is that the files of customers are kept in the customers own container and for those files to retain their versions on updates of the file. So far so good, this is all possible, and extensively documented online. Now, the second part is more complicated it appears where I thougth this would be a quite common usage example of object storage. I cannot find how I can automagically delete versions of files that are older then X days. There is the X-delete-after header, but this header needs to be added for each transaction. What I want is for all objects in a container to get deleted after X days without having to add a header once the object is uploaded. Does anyone have suggestions on how I could implement this requirement? Please find below a grafical repesentation of what I want Versioning disabled Automated add headers delete-after Versioning enabled Usage on the account of LF Usage on the account of client │ │ │ │ │ │ ▼ ▼ ┌────────────────────────┐ ┌────────────────────────┐ │ │ │ │ │ Versions-container │ │ Current-container │ │ │ │ │ ├────────────────────────┤ ├────────────────────────┤ │ │ │ │ │File1 v123456 │ │ File1 │ │File1 v567899 │ │ File2 │ │ │ │ File3 │ │File3 v234567 │ │ ... │ │ │ │ FileN │ └────────────────────────┘ └─────────────┬──────────┘ ▲ │ │ │ └────────────────────────────────────────┘ Modifications cause current to be moved to Versioned-container Best regards, Geert

2 1

Kubernetes Conformance 1.24 + 1.25
by Kendall Nelson 05 Jun '23

05 Jun '23

Hello All! First of all, I want to say a huge thanks to Guilherme Steinmuller for all his help ensuring that OpenStack Magnum remains Kubernetes Certified [1]! We are certified for v1.24! However, in digging into the set of conformance tests this round, it appears that we will not be able to get 1.25 certified with the current Magnum. This means that in May when we have to re-cert (every 3 months they reach an EOL because that's k8s release cadence) we will not be able to maintain this which is the other part of why I wanted to write this email - to raise awareness and ask for help digging into what needs to happen to make sure we can retain this. Tangentially related, Guilherme has posted a patch with documentation for how to run the conformance tests for yourself and it could use some reviews [2]. And one last thing, I have begun conversation with the opendev folks about what it might take to setup jobs to run the conformance tests periodically so that we don't have to manually run them when it's time to recert. I am planning on submitting a forum topic for this for those interested :) Long live LOKI! - Kendall Nelson [1] https://github.com/cncf/k8s-conformance/pull/2446 [2] https://review.opendev.org/c/openstack/magnum/+/849156

5 10

[nova] hw:numa_nodes question
by hai wu 02 Jun '23

02 Jun '23

Is there any concern to enable 'hw:numa_nodes=1' on all flavors, as long as that flavor can fit into one numa node?

4 18

[ironic][stable] Proposing EOL of ironic project branches older than Wallaby
by Jay Faulkner 02 Jun '23

02 Jun '23

Hi all, Ironic has a large amount of stable branches still in EM. We need to take action to ensure those branches are either retired or have CI repaired to the point of being usable. Specifically, I'm looking at these branches across all Ironic projects: - stable/queens - stable/rocky - stable/stein - stable/train - stable/ussuri - stable/victoria In lieu of any volunteers to maintain the CI, my recommendation for all the branches listed above is that they be marked EOL. If someone wants to volunteer to maintain CI for those branches, they can propose one of the below paths be taken instead: 1 - Someone volunteers to maintain these branches, and also report the status of CI of these older branches periodically on the Ironic whiteboard and in Ironic meetings. If you feel strongly that one of these branches needs to continue to be in service; volunteering in this way is how to save them. 2 - We seriously reduce CI. Basically removing all tempest tests to ensure that CI remains reliable and able to merge emergency or security fixes when needed. In some cases; this still requires CI fixes as some older inspector branches are failing *installing packages* in unit tests. I would still like, in this case, that someone volunteers to ensure the minimalist CI remains happy. My intention is to let this message serve as notice and a waiting period; and if I've not heard any response here or in Monday's Ironic meeting (in 6 days), I will begin taking action on retiring these branches. This is simply a start; other branches (including bugfix branches) are also in bad shape in CI, but getting these retired will significantly reduce the surface area of projects and branches to evaluate. I know it's painful to drop support for these branches; but we've provided good EM support for these branches for a long time and by pruning them away, we'll be able to save time to dedicate to other items. Thanks, Jay Faulkner

3 5

Add netapp storage in edge site | Wallaby | DCN
by Swogat Pradhan 01 Jun '23

01 Jun '23

Hi, I have a DCN setup and there is a requirement to use a netapp storage device in one of the edge sites. Can someone please confirm if it is possible? And if so then should i add the parameters in the edge deployment script or the central deployment script. Any suggestions? With regards, Swogat Pradhan

2 10

CRITICAL! RabbitMQ PackageCloud repos will be not more available from today - affected Openstack-ansible
by Maroš Varchola 01 Jun '23

01 Jun '23

From today, the PackageCloud repos will be not more available from today. Official information: https://github.com/rabbitmq/rabbitmq-server/discussions/8386 BUG on launchpad: https://bugs.launchpad.net/openstack-ansible/+bug/2021410 -- S pozdravom/Yours Sincerely, Maroš Varchola +421 950 401 060 Astrová 6116/2, 071 01 Michalovce, Slovakia marosvarchola(a)sunray.sk ---- Táto správa bola digitálne podpísaná PGP certifikátom/ This message was digitally signed by PGP certificate

5 7

[ironic] retirement of old bugfix branches
by Riccardo Pittau 31 May '23

31 May '23

Hello everyone! We're going to remove old bugfix branches in the next few weeks, all bugfix branches that are older than 6 months are officially EoL. This includes: - for ironic bugfix/18.0 bugfix/18.1 bugfix/19.0 bugfix/20.2 bugfix/21.0 bugfix/21.2 - for ironic-inspector bugfix/10.7 bugfix/10.9 bugfix/10.12 bugfix/11.0 bugfix/11.2 -for ironic-python-agent bugfix/8.0 bugfix/8.1 bugfix/8.3 bugfix/8.6 bugfix/9.0 bugfix/9.2 Thanks! Ciao Riccardo

1 0

openstack backup volume - error with rootwrap
by garcetto 31 May '23

31 May '23

goodmorning, using kolla-openstack zed cluster, cinder backend is nfs, cinder-backup is another nfs too. when i try to do backup: #openstack volume backup create 43e97a6d-c965-4127-8334-df5b5e8e8a05 (on cinder-backup container) (/var/log/cinder-backup.log) " ERROR oslo_messaging.rpc.server Command: sudo cinder-rootwrap /etc/cinder/rootwrap.conf chown 42407 /var/lib/cinder/mnt/6c827b655049ba4f069fd5f103620555/volume-20f3c72c-0b57-4500-b552-5056d12fd9c7 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server Exit code: 1 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server Stdout: '' 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server Stderr: "/bin/chown: changing ownership of '/var/lib/cinder/mnt/6c827b655049ba4f069fd5f103620555/volume-20f3c72c-0b57-4500-b552-5056d12fd9c7': Invalid argument\n" 2023-05-31 12:37:37.551 7 ERROR oslo_messaging.rpc.server " could anyone give me advice how to proceed? thank you for your time.

3 3

[kolla-ansible][zed] nfs as backend for nova
by garcetto 31 May '23

31 May '23

good afternoon, it is a clear doc or tutorial on how to configure an nfs share as backend storage for nova root vm volumes? (find for ceph but not for nfs) thank you

1 0

Affinity Group in Open Stack
by Adivya Singh 31 May '23

31 May '23

Hi Guys, Anything i can check on this , more from the server logs and the switch logs Packet drops when using trex traffic generator when device under test and traffic generator are not in same compute node But if we launch the instance using affinity and traffic generator and client on the same node , it works fine Regards Adivya Singh

1 0