Search results for "#eventlet-removal" - openstack-discuss

[neutron] Disable fullstack CI job

by Rodolfo Alonso Hernandez

Hello Neutrinos: As commented yesterday in the Neutron meeting [1], the "fullstack" CI is blocking the eventlet removal. This CI FW is also blocking the SDK migration [2]. The refactor of this CI is now not possible due to time constraints. Because of this, we are going to disable it and migrate the tests implemented to other FWs, if possible. The coverage of this CI is important but limited. The advantage of this FW is the possibility of, for example, restarting services or agents; this is something achieved by other FWs like "tobiko". Another advantage is the possibility of testing with different configurations, but that could also be achieved by using the same CI job with different static configurations; it is also possible to change the API configuration and restart it using "whitebox-neutron-tempest-plugin". I've created a bug to track these efforts [3]. In the next few hours I'll send a patch to remove the "fullstack" FW from our CI. Regards. [1] https://meetings.opendev.org/meetings/networking/2025/networking.2025-06-24… [2]https://review.opendev.org/c/openstack/neutron/+/947851 [3]https://bugs.launchpad.net/neutron/+bug/2115327

6 months, 1 week

[neutron] Bug deputy report (week starting on February 3)

by Bernard Cafarelli

Hey neutrinos, here are the reported during the first week of February All bugs have a fix (merged in several cases) or assignee. Only pending one is the last one reported on neutron-vpnaas (but on EOL branch) Critical * [OVN] Neutron OVN metadata agent broken - https://bugs.launchpad.net/neutron/+bug/2097273 Fixed by https://review.opendev.org/c/openstack/neutron/+/940679 * networking-bagpipe CI is broken since linuxbridge driver removal - https://bugs.launchpad.net/neutron/+bug/2097367 Mentioned in last week team meeting, picked up by Lajos High * test_async_process_respawns_with_race_condition functional test fails randomly - https://bugs.launchpad.net/neutron/+bug/2097284 Recent new functional test failure - fixed with https://review.opendev.org/c/openstack/neutron/+/940687 * test_async_process_respawns functional test failing in fips functional job - https://bugs.launchpad.net/neutron/+bug/2095598 Another recent failure - fixed in the end with previous fix + https://review.opendev.org/c/openstack/neutron/+/939627 Medium * [eventlet-removal] Use ``ThreadPoolExecutor`` for ``periodics.PeriodicWorker`` - https://bugs.launchpad.net/neutron/+bug/2097257 Title says it all - reported and picked up by Rodolfo * devstack-tobiko-neutron failing in zed and 2023.1 with missing designate - https://bugs.launchpad.net/neutron/+bug/2097286 Tobiko job failures in unmaintained branches since job config cleanup - should be good with https://review.opendev.org/c/x/devstack-plugin-tobiko/+/940694 * [OVN] OVN metadata agent should build the response according to the content - https://bugs.launchpad.net/neutron/+bug/2097431 Fix when body response is empty with merged https://review.opendev.org/c/openstack/neutron/+/940679 Untriaged * No connection from outside host to VPNaaS host after upgrading from Ussuri to Victoria/Wallaby - https://bugs.launchpad.net/neutron/+bug/2097610 VPNaaS issue on EOL branch - I did not close immediately in case vpnaas experts have an idea -- Bernard Cafarelli

10 months, 3 weeks

Re: [all][tc] Eventlet migration: Call to action

by smooney＠redhat.com

On Thu, 2024-05-16 at 10:27 +0200, Herve Beraud wrote: > Thanks Jay for this thread and for summarizing the T.C feeling. > My following sentences are not directly addressed to you (Jay), but to > others T.C members. > > Le mar. 14 mai 2024 à 18:28, Jay Faulkner <jay(a)gr-oss.io> a écrit : > > > Hi all, > > > > As you may have read in Goutham's TC summary, the existing eventlet > > goal[0] is unlikely to gain consensus to merge. This appears to be due to > > the difference in needs between OpenStack projects, and belief that it's > > unlikely a single solution would serve them all. > > > > I might agree with the fact it's unlikely a single solution would serve > them all. I was going to update some sentence to make this optionality more > stronger: > https://review.opendev.org/c/openstack/governance/+/902585/comment/bb363bda… > > Also, I was going to propose some adaptations to introduce futurist and > executors: > https://review.opendev.org/c/openstack/governance/+/902585/comment/6b23377c… speaking of executors for nova we have approved a specless bluepirnt to adress some of the low hanging fruit https://blueprints.launchpad.net/nova/+spec/eventlet-removal-part-1 which is implemented here https://review.opendev.org/q/topic:%22eventlet-removal-part-1%22 although i will be revising that at least once more before its ready to merge. the last two patches in the series remove eventlet.tpool and replace its use with futurist a thread pool executor instead for our specific usage https://review.opendev.org/c/openstack/nova/+/917962/4/nova/storage/rbd_uti… that's a relatively simple transformation. there are one our too outer uses of eventlet.tpool in nova and i will also adress the usage in the guestfs module but i will likely no touch its usage in the libvirt driver as we have a rather complex code dedicated to how we interact libvirt that need careful thought to untangle. > > But, rather than speaking of "a single solution", I'd suggest speaking > about "a solution by default". > > Indeed, many comments made in this proposal strongly adopt Nova's > perspective. > Nova is a major piece of Openstack, but Openstack is not only Nova. > By updating that sentence (see the previous links), we would make this > proposal optional for teams who have the capabilities to design their own > alternatives. Nova. > > Teams like Nova have resources that other teams may not have. yes and no. the nova teams capacity is fairly limited these days. we have between 5-10 active contributors depending on how you look at it. refining that by the people that understand our use of eventlet and can review the code and factor in have the time rewrite the relevnet code while being upstream consistently enought to actually make progress that probably means about 3-5 people could actually do this. at lesat 2 of those people are actively working on finisnhing multi cycle efforts and the rest including myself are heavily engaged in dowstream work or work in other projects that limits our upstream review and development time for at least the next 3-6 months. Nova is trying to be pragmatic that we do not have enough contributor to rewrite the part of nova that would require it to asyncio without heavily impacting the projects viablity. so we are looking at using futurist executors instead because its a lot less work to achieve the goal of not using eventlet while not prohibiting us form exploring asyncio or other options eventually if it makes sense. if we had to replace eventlet with asyncio im not confident we could complete that for nova in the next 12 -18 months. not without effectively stopping all other development. we just don't have the review or code writing capacity to do something that large and complex while actually ensuring we don't introduce regressions if we were doing anything else. > T.C members should consider this difference in resources between teams. > > T.C members are elected to adopt a global point of view, and not a team > based point of view: > https://governance.openstack.org/tc/reference/principles.html#openstack-fir… > > Else, without any default optional solution, teams with lower resources > will be deprived of any solutions... > > Teams should not consider the use of their surplus as legitimate when other > teams are deprived of what is necessary. > > As a community member, this is the kind of mindset that I expect from the > Openstack governance. > > > > Our current situation is: > > 1) Eventlet usage must be discontinued. The temporary maintainers are just > > that -- temporary -- and we should not expect eventlet to continue to be a > > valid path moving forward. > > 2) We have basic agreement that shared tooling, such as oslo libraries, > > should not dictate a specific threading model. > > > > If by "should not dictate a specific threading model", you mean that Oslo > forced the use of async/await, then I STRONGLY disagree about 2)... > Please show me where, in the proposed goal, oslo libraries dictate a > specific threading model? => > https://review.opendev.org/c/openstack/governance/+/902585 that more a refence ot not forcing async await rather then the internal impelmations. i.e. dont require your users to use asynio > > FYI the libs migration is detailed in the "How to migrate a library" > section (around line 646 of the proposed goal). > And a living example of how the libs would work is available at > https://github.com/4383/snippets/blob/main/python/facade/facade.py that snipit seams to assume its oke to create an asyncio eventlop on the fly in any geiven invocation which is proably going to be too slow for many usecases i.e. if oslo log did that every time we logged that would be a problem. i have not messuered the startup time of the asynio eventloop but i expect its more expensive then a trival python function call. if that loop was reused between calls to the lib or even kicked out into its own thread perhaps with a graceful shutdown if noting is run for an extended period of time like privsep, then i can see that variation fo the facade pattern working. we ould have to mussure the overhad of _iter_coroutine https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.get_runnin… does appear to be thread safe so in principal it should not cause any cross thread interactions. that was one of my concerns when lookign at the snipit initally. > > To conclude, is it still worth it to spend time updating this proposal > again or is your decision definitive? >

1 year, 7 months

Re: [PTG] Call for Summaries, Attendance Numbers, and Team Photos

by Kendall Nelson

Hello Everyone! I want to do one more call for attendance numbers. I am still missing data from the following teams: - Barbican - Blazar - Cascade - Cloudkitty - Glance - Heat - Ironic - Magnum - Neutron - OpenStack-Ansible - OpenStack-Helm - Sunbeam - Swift - Tacker - Telemetry A much shorter list than last time, but still about 1/3 of the overall number of teams that met during the PTG. If you were a moderator (or know the moderator of the team and can give them a gentle nudge), please send me approximate attendance numbers for your meetings ASAP. Thanks! -Kendall On Wed, Nov 5, 2025 at 1:26 AM Kendall Nelson <kennelson11(a)gmail.com> wrote: > Hello Folks! > > I am working on a summary post for our OpenInfra Blog as usual and I am > missing A LOT of attendance numbers from OpenStack teams. > > Specifically, I am missing attendance numbers from: > > - Barbican > - Blazar > - Cinder > - Cloudkitty > - Cross Deploy > - Designate > - Eventlet Removal > - Glance > - Heat > - Horizon > - i18n > - Ironic > - Keystone > - Kolla > - Magnum > - Neutron > - OpenStack Ansible > - OpenStack Helm > - Sunbeam > - Swift > - Tacker > - Telemetry > - Watcher > > If you were a moderator for this session please send me your approximate > attendance to ptg(a)openinfra.org ASAP. If you simply attended one of these > sessions, and you would be so kind as to remind the moderator to send me > the info I would be very grateful! > > Additionally, I will happily accept any team photos that were taken and > links to blog posts or other summaries that I can include in OpenInfra Blog > post as well. There are a lot of open source communities outside of the > OpenInfra Foundation that are curious about how we conduct our PTGs and > these posts are incredibly helpful at educating others on how to follow the > four opens and build a stronger community. > > Thank you for all of your support! Looking forward to the next PTG! > > -Kendall >

1 month, 3 weeks

#eventlet-removal Thank you for 2024

by Herve Beraud

You are no doubt aware that we are currently facing a real challenge. We are living in a complex situation where we have to engage resources to exit from a problematic technology, eventlet, without especially gaining new features. This migration, although without immediate direct functional value, represente for us a considerable investment in time and resources. But such context is not far different from the Python 2/Python 3 migration. Remember that era. The core Python maintainers found themselves in a difficult situation: continue to maintain their code on Python 2, which had become insecure and unsupported, or go through the effort of completely migrating their codebase and toolchain to Python 3. All the community had to make a choice. Third-party libraries, frameworks were also on the edge case, to be upgraded or replaced with Python 3 compatible equivalents. At the time of the decision, these efforts appeared to represent a "non-value-added burden". These efforts did not bring any new functionality, did not respond to any new customer need, and even slowed down other more innovative developments. The Python maintainers could have chosen the easy way. They could have chosen to continue to support Python 2 again for years, they could have chosen to live in statu-quo, but that's not what happened [1]. They chose to fight the problem and they chose to engage strong efforts in this migration. They ensured the security and the perenniality of the Python programming language. Once the migration was completed, the benefits quickly became apparent. The innovation cadence increased. The community united behind one uniq major version. Better performances. More innovations. And last but not the least, a simpler life for the distros maintainers and for end-users, and so a reinforced confidence in Python by our industry. Python is now the number 1 technology, leaving Java and C in the dust [2]. This is the lesson we must learn. Necessary actions without immediate direct functional value can ultimately hide treasures of innovation. Engagement and dedication is the key to a sustainable future. It guarantees the long-term viability of a project, reduces risks, and opens the way to faster and more peaceful innovation. Today, I can tell you that I'm proud that our community engaged the same way. I'm proud to see all the milestones we reached during this exciting year. I'm proud to observe so much engagement coming from every side, from everybody, and from all our companies. That's a strong signal of trust from our industry. Our companies support this initiative, our companies support open source, our companies invest in the future of OpenStack. On behalf of this community initiative, let me thank you very much for all your efforts and engagements in 2024. Let me wish you happy holidays and enjoy your loved ones. [1] https://devguide.python.org/versions/ [2] https://www.tiobe.com/tiobe-index/ -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year

Re: [eventlet-removal]When to drop eventlet support

by Dmitriy Rabotyagov

Also let's keep in mind, that only nova (with placement) will spawn 64 threads on such setup by default. And then all really depends on set of services to launch on such setup. So from deployment tooling protective you have all required data to rollout not instantly oom-ing setup at cost of amount of request services can process in parallel. On Mon, 16 Jun 2025, 15:24 Dmitriy Rabotyagov, <noonedeadpunk(a)gmail.com> wrote: > In case you try to use a 32gb box with 16 cores as a controller for > OpenStack - it will blow off with default amount of workers for wsgi and > /or eventlet apps. > > While you can argue this should not be used as production setup, this can > be totally valid for sandboxes and we wanna provide consistent and reliable > behavior for users. > > But my argument was not in if/how we want to fine-tune deployments, but > also understand and provide means to define what's needed as well as > potential ability to revert in worst case scenario as a temporary > workaround. > So still some variables and logic would be introduced from what I > understand today. > > > On Mon, 16 Jun 2025, 14:43 Sean Mooney, <smooney(a)redhat.com> wrote: > >> >> On 16/06/2025 13:27, Dmitriy Rabotyagov wrote: >> > >> > >> > >> > sayint its FUD is not helpful. >> > >> > we got a driect ask form operator and soem core to not do a hard >> > switch >> > over. >> > >> > and while i wanted to only support one model for each binary at a >> > time >> > we were sepcificly ask to make it configurable. >> > >> > > In the later case, your only available action is help fixing >> > bugs. It >> > > is not up to the operators to double-guess what may or may not >> > work. >> > >> > correct we are not planning to document how to change mode we were >> > planning to only use this configuration in ci and operator would be >> > >> > >> > Well, we'd need to have that communicated so that deployment toolings >> > could adopt their setup to changes, as, for instance, in OSA amount of >> > eventlet workers are calculated based on the system facts, so we'd >> > need to change the logic and also suggest how users should treat this >> > new logic for their systems. >> >> why is OSA doing that at all today? >> we generally don't recommend changing those values from the default >> unless you really know what your doing. >> i don't think other installer do that. >> tripleo, kolla-ansbile and our new golang based installer do not, nor >> does devstack so its surprising to me that OSA would change such low >> level values >> by default. >> >> we will document any new config options we and and we are documentation >> how to tune the new options for thread pools but we do not expect >> installation >> tools to modify them by default. we are explicitly not making the >> options based on the amount of resources on the host i.e. dynamically >> calculated based >> on the number of CPU cores. >> >> for example we are explicitly setting the number of scatter_gather >> thread in the the dedicated thread pool to 5 >> why its a nice small number that will work for most people out of the box. >> >> can you adjust it, yes but it scale based on the number of nova cells >> you have an 99% wont have more then 5 cells. >> >> using information about the host where the API is deployed to infer the >> value of that would be incorrect. >> >> you can really only make an informed decision about how to tune that >> based on monitoring the usage of the pool. >> >> that how we expect most of the other tuning options to go as well. >> >> our defaults in nova tend to be higher then you would actually need in a >> real environment so while it may make sense to reduce >> them we try to make sure the work out of the box for most people. >> >> gibi id building up >> >> https://review.opendev.org/c/openstack/nova/+/949364/13/doc/source/admin/co… >> >> as part of nova move to encode this but our goal is that deployment >> tools shoudl not need to be modifyed to tune these >> valued by defualt. >> >> > >> > So it will be kinda documented in a way after all. >> > >> > >> > told for a given release deploy this way. >> > >> > this is an internal impelation detail however we are not prepared to >> > deprecate usign eventlet until we are convicned >> > >> > that we can run properly without it. >> > >> > > For beginners, this would be a horrible nightmare if default >> > options >> > > simply wouldn't work. We *must* ship OpenStack working by default. >> > no one is suggesting we do otherwise. >> > > >> > > Cheers, >> > > >> > > Thomas Goirand (zigo) >> > > >> > >> >>

6 months, 2 weeks

[magnum][all] Magnum PTG summary

by Dale Smith

Hi everyone, thanks to those who joined the Magnum PTG on 28th October. It was held early in the morning for EU, and evening for AU/NZ. Apologies to those who were less likely to make it due to the time slot; please reach out if you'd have liked to join but couldn't and we'll take that into account for the next. Attendees: 9 (6 UK/EU, 3 AU/NZ) Etherpad: https://etherpad.opendev.org/p/oct2025-ptg-magnum The floor was open to discussion topics from the etherpad, and topics were discussed in the order presented. We discussed the current state of drivers, and migration from Heat to CAPI: None planned, rebuild your clusters once CAPI is running. Cluster upgrades after that are easy. Installation of the base Kubernetes system to support CAPI drivers was a topic of interest as Magnum with CAPI drivers is now dependant on having a running Kubernetes cluster and not OpenStack Heat. This is left to deployers, but improved documentation of options and deployers would be helpful. Magnum documentation on docs.openstack.org was brought up and agreed to be in a poor state with out of date and very old references. The consensus was we should **remove** the existing documentation and rewrite it without references to Heat driver (which is deprecated and slated for removal; making this decision easier in G). Older documentation for old releases would still be available on docs.openstack.org. As with the past few cycles, the CI system needing to cover CAPI was raised. mnasiadka is planning to work on this in the G cycle. Eventlet removal patches have been created last cycle, and the core team agrees to push forward with reviewing and merging these early in the cycle so any problems can be found. and finally, discussion on a longer term feature proposals around labels[1][2] was continued with specs linked (which are noted as needing an update to current thinking). The current state of labels in Magnum is in need of an update to support more features of Cluster API; allow end users to modify these labels for a running cluster, discover valid labels, and provide a more structured format for defining these per ClusterTemplate, Cluster and NodeGroup. References: [1] https://review.opendev.org/c/openstack/magnum-specs/+/943358 Propose label normalisation spec. [2] https://review.opendev.org/c/openstack/magnum-specs/+/955549 Add spec for api-validation-with-driver -- DALE SMITH Cloud Engineer Catalyst Cloud <https://catalystcloud.nz> Aotearoa New Zealand's cloud provider e dale(a)catalystcloud.nz w catalystcloud.nz <https://catalystcloud.nz> Follow us on LinkedIn <https://www.linkedin.com/company/catalyst-cloud-limited/> Level 6, Catalyst House, 150 Willis St, Wellington 6011 Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267 <tel:+6444992267>.

1 month, 2 weeks

[tc][ptg] OpenStack Technical Committee 2025.2 Flamingo PTG summary

by Goutham Pacha Ravi

Hello Stackers, Here’s a summary of the OpenStack Technical Committee’s discussions at the 2025.2 “Flamingo” Virtual PTG held April 7–11, 2025. Find detailed notes in our discussion etherpad [1] and recordings on YouTube [2]. Feedback is welcome on this mailing list or in OFTC’s `#openstack-tc` IRC channel, perhaps during our weekly meetings [3]. == Topic: TC Retrospective == Discussion: - We reviewed the TC’s effectiveness in addressing issues raised during the cycle, including leadership gaps, licensing concerns, project guide updates, and communication practices. - Fewer teams were leaderless following the 2025.2 election cycle—thanks to better outreach and clearer election guidance. - There was consensus that the TC guideline discouraging bare “recheck” comments and the need to address persistent gate issues is now better understood. - Licensing FAQs [4] appear outdated. We noted that the TC can escalate licensing questions to the OpenInfra Foundation’s Legal team and should monitor the `legal-discuss` list more actively. - Teams encouraging non-core contributors to become PTLs was praised as a way to grow the contributor base through mentorship. Action Items: - Update the Project Team Guide, removing obsolete sections (e.g., sprint design/process). - Update licensing references across the Project Team Guide and TC governance site. - Encourage public communication, regular meetings, and the use of team-specific IRC or Matrix channels. == Topic: Goals Retrospective == Discussion: - We reviewed the status of ongoing community-wide goals, including progress, blockers, and next steps. - Migrate CI Jobs to Ubuntu Noble [5] - The goal is complete. Teams should now remove OS version pins in their repositories. - Eventlet Migration [6] - Refer to Hervé’s PTG summary [7] for updates. - Privsep Migration [8] - Progress is slow; some minor activity exists in Gerrit, but tracking doesn’t reflect it. - The Oslo team will de-prioritize removing eventlet from `oslo-rootwrap`, as it’s expected to be retired. - Clear guidance on secure, performant `privsep` usage is needed. - FIPS Compliance [9] - CentOS Stream 10 requires x86_64-v3, unsupported by our nodepool providers. - This hardware/runtime mismatch complicates long-term testing with CS9 or Ubuntu LTS. - Alternatives discussed: Debian, Rocky Linux (but Rocky may inherit CS10's hardware constraints). - Red Hat is evaluating a `paramiko` replacement this cycle. - Consistent and Secure RBAC [10] - Progress tracked [here](https://etherpad.opendev.org/p/rbac-goal-tracking#L14). - Phase 1 (personas + drop system scope): 16 projects complete. - Phase 2 (service role): 3 projects. - Phase 3 (manager role): 3 projects. - Ghanshyam Mann (gmann) continues to chair bi-weekly IRC meetings. Action Items: - Rodolfo Alonso Hernandez (ralonsoh) to send a status update on `privsep` and flag possible `rootwrap` deprecation. - Ade lee (ade_lee) to update FIPS goal status. - SRBAC liaisons must attend bi-weekly meetings and track project progress. - Publish guidance on secure, performant `privsep` usage. == Topic: Revisiting “Unmaintained” Branches == Discussion: - The TC discussed the burden and ambiguity around maintaining aging branches. - Project teams often lack resources or interest to maintain older branches; the Release team has pursued mass EOL as a workaround. - We agreed to reduce scope and prioritize core goals (e.g., eventlet removal, CI stability) rather than preserve old branches without active interest. - TC supports giving `openstack-unmaintained-core` full responsibility for EOL decisions. We may seek volunteers earlier in the branch lifecycle. - Broken jobs in unmaintained branches flood Zuul; fixing in-repo configs may not be viable. OpenDev may opt to ignore failing jobs externally. - There’s an unregistered, unlogged `#openstack-unmaintained` IRC channel on OFTC. Action Items: - Document responsibilities of unmaintained branch liaisons and `openstack-unmaintained-core`. - Propose a new process: `openstack-unmaintained-core` sets deadlines per cycle to solicit maintainers for aging branches. If no one steps up, proceed to EOL. == Topic: TC and Community Leaders Forum == Discussion: - Governance proposal under review to expand the scope of the VMT to cover all OpenStack project teams [11]. - The TC must ensure teams prioritize security. Poor handling of vulnerabilities harms community trust and ethical responsibility. - Ideas were proposed to support the VMT, including a pool of core security contacts from contributing organizations. - Projects were reminded to review community goals and prioritize them. Adding goal timelines and cross-project prioritization was suggested. - Teams should use Stackalytics and Bitergia dashboards to track activity and identify areas needing improvement (e.g., review velocity, core participation). Action Items: - Teams must audit their Launchpad “Bug Sharing” settings and confirm their `coresec` groups contain responsible, active contributors. - PTLs and Security Liaisons should ensure they can manage the `coresec` group or delegate access. - Audit deliverables against [Security Process Requirements][12]. - Benchmark project health using Stackalytics/Bitergia. Reinforce OpenStack code review best practices [13][14]. == Topic: Finding Contributors in Some Projects is Hard == Discussion: - QA, Requirements, and Release Management teams remain understaffed. - Despite upstream investment opportunities for 2025 [15], contributor interest is low. - This is a “Tragedy of the Commons” issue: shared work without clear ownership is often deprioritized. - PTG scheduling didn’t support sufficient cross-project collaboration. - The TC was encouraged to reset perfectionist expectations—approve good-enough changes, and avoid expanding review scope unnecessarily. Action Items: - Explore QA Liaisons: trusted contributors mentored into maintaining QA repos. - Avoid nitpicking or scope creep during code reviews. - Promote and participate in the contributor survey [16]. - Document expectations and best practices in the Project Team Guide. == Topic: Splintered Conversations & Communication Barriers == Discussion: - Operators report more engagement on Reddit, Kubernetes Slack, Discord, etc., than on `openstack-discuss` or OFTC IRC. - Some organizations block Matrix due to regulatory compliance, requiring platforms with retention policies. - The OpenInfra Board will not mandate platforms—projects must choose what suits them. - IRC onboarding is hard for newcomers. - Zuul contributors reported smooth onboarding to Matrix. Its e2e encryption may make it more acceptable for compliance-sensitive orgs. - The conversation continued in the `os-operators` PTG, where there was interest in trying Matrix and Meetpad for better engagement. Action Items: - Explore use of a hosted Matrix homeserver by OpenDev as a short-term workaround for those unable to use IRC. That's a wrap! It was great fun seeing you all at the PTG. I look forward to working on these AIs with you! Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://etherpad.opendev.org/p/r.51cb4e74dd9980932d32e9a9f4e8a0ce (OS TC PTG Etherpad) [2] https://www.youtube.com/playlist?list=PLhwOhbQKWT7XYzqrx21j1uizxNxnbDf5Q (OS TC PTG Recordings) [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee (OS TC Weekly Meetings) [4] https://wiki.openstack.org/wiki/LegalIssuesFAQ (OpenStack Licensing FAQs) [5] https://governance.openstack.org/tc/goals/completed/2025.1/migrate-ci-jobs-… (Migrate to Noble goal) [6] https://governance.openstack.org/tc/goals/selected/remove-eventlet.html (Eventlet removal goal) [7] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… (Eventlet PTG Summary) [8] https://governance.openstack.org/tc/goals/selected/migrate-to-privsep.html (Privsep migration goal) [9] https://governance.openstack.org/tc/goals/selected/fips.html (FIPS compliance goal) [10] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… (SRBAC goal) [11] https://review.opendev.org/c/openstack/governance/+/944817 (TC VMT Resolution) [12] https://security.openstack.org/repos-overseen.html#requirements (Security requirements for OpenStack Projects) [13] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html (Code Reviews in the OpenStack Way) [14] https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatt… (Code Review Antipatterns) [15] https://governance.openstack.org/tc//reference/upstream-investment-opportun… (OpenStack Investment Opportunities) [16] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… (Bridging the Gap)

8 months, 2 weeks

[nova][ptg] Nova sessions on Wednesday

by Sylvain Bauza

Hi, Given most of the nova cores will attend the eventlet-removal session at 1300UTC, we'll defer the nova sessions to start at 1400UTC instead of 1300UTC. Please stay online in #openstack-nova IRC channel or please take a look at https://ptg.opendev.org/ptg.html to see the exact time when we spawn again the nova conversations. Thanks, -Sylvain (who just unbooked the austin room for Wed-B1)

1 year, 2 months

[mistral] meetings during next PTG

by Arnaud Morin

Hey all, Next PTG will take place between April 7 to 10. Is there anyone willing to talk about mistral developement during this PTG? So far, mistral has not evolved that much, but maybe someone is having ideas about it? Also, there is this eventlet-removal topic that could be discussed. Let me know, Cheers, Arnaud.

11 months

openstack-discuss search results for query "#eventlet-removal"