September 2022 - openstack-discuss

[all][elections][tc] TC Election Non-Candidacy ...
by Jay Bryant 02 Sep '22

02 Sep '22

All, I wanted to take a moment to let everyone know that I am not going to be running for the TC, this time around. The last two years on the TC have been a great experience and I am grateful for the trust the community put in me. At this point, however, I think it is best to let others who may want to join the TC have the opportunity to do so. Again, thank you for this opportunity to support the community over the last couple of years! Sincerely, Jay Bryant (jungleboyj)

3 2

[manila] Feature freeze exceptions
by Carlos Silva 02 Sep '22

02 Sep '22

Hello, Zorillas and interested stackers! During today's Manila weekly meeting we went over the status of our open changes that are eligible for feature freeze. Some candidates for the deadline were successfully merged over the course of this week, but there are also a few other changes that are receiving feedback from reviewers. Those changes will need some extra time to get in. We are in a shortage of reviewers to take care of all of the changes at once, and we are extending the deadline by one week. The changes yet to be merged and receiving the feature freeze exception are: *Metadata for share snapshots [1]* During the Yoga cycle, Manila metadata APIs were changed to be more generic and be able to accommodate metadata for other resources. For Zed, we planned to have metadatas being added to the snapshot resources. This change has received some reviews and seems to be quite close to being merged. During the tests, the manipulation of metadata for share snapshots seems to work just fine, and we are only getting some final tweaks to the implementation. *Refactor the Ceph NFS driver to use Cephadm NFS [2]* This is a driver-only change and it does not impact the Manila core itself. It is important for people consuming the Ceph drivers, and does not impact the current driver implementation. *Support share transfer between project [3]* This change is currently under review and is a good addition to the Manila core. Due to the shortage of reviewers, we only got more people looking at the change and testing the functionality late in the cycle. The three changes aforementioned should be merged by next Thursday (08 september 2022). [1] https://review.opendev.org/c/openstack/manila/+/825008 [2] https://review.opendev.org/c/openstack/manila/+/848987 [3] https://review.opendev.org/c/openstack/manila/+/843832 In case you have questions or concerns, please let me know. Thank you, carloss

1 0

[all] [oslo.messaging] Interest in collaboration on a NATS driver
by Tobias Urdin 01 Sep '22

01 Sep '22

Hello everyone, Before continuing on, yes this kind of is a massive effort but it doesn’t have to be, it would be very cool to get a replacement for RabbitMQ as I’m probably not the only one not satisfied with it. I've proposed a very bare POC in [1] but it's long way from being finished, but atleast some basic devstack is passing. NATS [2] is a cloud-native scalable messaging system that supports the one-to-many and pub-sub methods that we can use to implement it as a oslo.messaging driver. This would make OpenStack easier to deploy in a highly available fashion, reduce outages related to RabbitMQ, free up memory and CPU usage by RabbitMQ (it’s insane when using clustering) and embrace a more cloud-native approach for our software that runs the cloud, alternatives is also welcome :) The POC has a lot of things that could be improved for example: • Do retries and acknowledgements in the library (since NATS does NOT persist messages like RabbitMQ could) • Handle reconnects or interruptions (for example resubscribe to topics etc) • Timeouts need to be implemented and handled • Investigate maximum message payload size • Find or maintain a NATS python library that doesn't use async like the official one does • Add a lot of testing • Cleanup everything noted as TODO in the POC code Now I couldn’t possibly pull this off myself without some collaboration with all of you, even though I’m very motivated to just dig in and do this for the rest of the year and migrate our test fleet there I unfortunately (like everyone else) is juggeling a lot of balls at the same time. If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I’m hoping somebody will bite but atleast I’ve put it out there for all of you. Best regards Tobias [1] https://review.opendev.org/c/openstack/oslo.messaging/+/848338 [2] https://nats.io

4 7

[neutron] Drivers meeting - Friday 02.09.2022 - cancelled
by Lajos Katona 01 Sep '22

01 Sep '22

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

[cinder] experiences with S3 cinder-backup driver // client-side encryption feature
by Christian Rohmann 01 Sep '22

01 Sep '22

Hello openstack-discuss and cinder-backup users! There is an S3 driver available for cinder-backup since the Wallaby release already, see https://docs.openstack.org/releasenotes/cinder/wallaby.html#relnotes-18-0-0…. 1) I was wondering if anybody already used that on a somewhat larger scale and what you experiences are about performance, stability and compatibility? 2) What object storage implementation or external service were / are you using? 3) While there are options like "backup_s3_sse_customer_algorithm" and "backup_s3_sse_customer_key" make use of server-side-encryption (SSE), there seems to be no way to encrypt the data before actually sending it to the remote S3 (read: client-side encryption). Since the boto3 Python SDK by AWS is used, which does not actually implement CSE, like other language SDKs do (see my issue: https://github.com/boto/boto3/issues/3395) it seems obvious why that is not a totally low-hanging fruit. But there are ways to add this, check out the references to e.g. https://github.com/StephenSorriaux/s3-encryption in the mentioned boto3 issue. Encrypting data before sending it off to a potentially externally operated service seems like a nice feature. Even a single encryption key would then protect that data from having to trust a 3rd party. I know encrypted cinder volumes would also work, but they are not as commonly used. * Is CSE something that others would also like to see for the S3 driver? * Cinder devs, would this maybe be worth a spec for the next cycle? Regards Christian

1 0

[ovn-bgp-agent][neutron] - expose_tenant_networks bug
by Satish Patel 01 Sep '22

01 Sep '22

Folks, I am setting up ovn-bgp-agent lab in "BGP mode" and i found everything working great except expose tenant network https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-testing-setup/ Lab Summary: 1 controller node 3 compute node ovn-bgp-agent running on all compute node because i am using "enable_distributed_floating_ip=True" ovn-bgp-agent config: [DEFAULT] debug=False expose_tenant_networks=True driver=ovn_bgp_driver reconcile_interval=120 ovsdb_connection=unix:/var/run/openvswitch/db.sock I am not seeing my vm on tenant ip getting exposed but when i attach FIP which gets exposed in loopback address. here is the full trace of debug logs: https://paste.opendev.org/show/buHiJ90nFgC1JkQxZwVk/

2 9

help: set ironic inspect autodiscovery failed
by 陈薇 01 Sep '22

01 Sep '22

Hi All, I'm trying the ironic inspect autodiscovery but failed. What I did: Set the inspector.conf 1. [discovery] enroll_node_driver = ipmi [processing] permit_active_introspection = true processing_hooks = $default_processing_hooks,extra_hardware,lldp_basic Configure the python agent: inspection_callback_url: There's no node automatically added. I enter the host and read the log of python agent, no inspect related log. Could anybody give any advice about how to triage or setup correctly? Thanks & Regards, Wei

1 1

[election][openstack-ansible] PTL candidacy for Antelope cycle
by Dmitriy Rabotyagov 01 Sep '22

01 Sep '22

Hello. I want to self-nominate for the role of OpenStack-Ansible PTL for the Antelope release cycle. As always, my goal will be to constantly improve existing code, make deployments and further operations as reliable as possible. For the previous cycle we have reached some of previously defined goals, like adding a `service` role, finally implementing service_token_roles and support of CentOS 9 Stream, but there is still room for improvement for role testing. With the return of live events I will do my best to ensure project presence on them and get in touch with operators to gain feedback for project future improvement. -- Kind regards, Dmitriy Rabotyagov

2 1