- openstack-discuss - lists.openstack.org

[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

[all][tc] Technical Committee next weekly meeting on 2022 Sept 1 at 1500 UTC
by Ghanshyam Mann 01 Sep '22

01 Sep '22

Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting * Roll call * Follow up on past action items * Gate health check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * Checks on Zed cycle tracker ** https://etherpad.opendev.org/p/tc-zed-tracker * 2023.1 cycle PTG Planning ** TC + Leaders interaction sessions *** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 ** TC PTG etherpad *** https://etherpad.opendev.org/p/tc-2023-1-ptg ** Schedule 'operator hours' as a separate slot in PTG(avoiding conflicts among other projects 'operator hours') *** https://twitter.com/osopsmeetup/status/1561708283492196353 *** https://doodle.com/meeting/participate/id/bD9kR2yd * 2023.1 cycle Technical Election ** https://governance.openstack.org/election/ * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann

1 0

[cinder] Extending Feature Freeze Deadline by 1 week
by Rajat Dhasmana 01 Sep '22

01 Sep '22

Hi All, As discussed in the cinder meeting today, due to the abundance of features proposed[1] and the shortage of review bandwidth, we are planning to extend the feature freeze by one week. Current feature freeze date (for cinder): 01 September 2022 New feature freeze date (for cinder): 08 September 2022 Kindly let me know if there are any objections to the above proposal else all the features proposed are eligible for the feature freeze exception of 1 week. [1] https://etherpad.opendev.org/p/cinder-zed-features Thanks and regards Rajat Dhasmana

1 0

[election][manila] PTL Candidacy for Antelope cycle
by Carlos Silva 01 Sep '22

01 Sep '22

Greetings, Zorillas and interested stackers, I would like to announce my candidacy to be the Manila PTL during the Antelope cycle. I have been the PTL for Manila since the Zed cycle, and have been contributing to OpenStack since the Stein release. It has been an awesome experience. Over the Zed cycle my focus was to continue mentoring and adding new core reviewers to the Manila repositories; Pursuing feature parity and complete support for manila in OSC (also increasing our functional tests coverage), tackling the tech debt; enhancing the documentation to help third party drivers to set up their CI systems; promoting events to gather the community members and getting bugs fixed and implementations moving faster. I am happy with the progress we made in those areas, but I still think there is room for improvement. During the Antelope cycle, I would like to focus on: - Continue our efforts to mentor contributors and increase the amount of active reviewers through engaging them in the community, teaching the OpenStack way and making it collaboratively as we did in the past cycles, promoting hackathons, bug squashes and collaborative review sessions. - Getting more features already available in the Manila core to Manila UI and get more attention to our changes to OpenStack SDK; - Continue pushing Manila to cover the tech debt areas we identified over the past cycles; - Enforcing maintainers to collaboratively cover the lack of documentation we have on third party CI setups for Manila, helping potential new vendors to quickly setup up their CI systems; Thank you for your consideration! Carlos da Silva IRC: carloss

3 2

[cinder] Antelope PTG Planning
by Rajat Dhasmana 01 Sep '22

01 Sep '22

Hi All, The virtual PTG for Antelope/2023.1 cycle will be held between 17-21 October 2022. The proposed schedule for cinder is as follows: Dates: Tuesday (18th October) to Friday (21st October) 2022 Time: 1300 to 1700 UTC Etherpad: https://etherpad.opendev.org/p/antelope-ptg-cinder-planning Please add topics to the etherpad as early as possible since that will help arrange the topics day wise in the actual PTG etherpad. Thanks and regards Rajat Dhasmana

1 0