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

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-12)

by Goutham Pacha Ravi

Hello Stackers, We're officially in the second half of the OpenStack 2025.2 "Flamingo" release cycle [1]. Starting on 2025-08-06, election officials will begin merging nominations for Project Team Leads for the 2026.1 release cycle and to fill four seats on the OpenStack Technical Committee. If you're interested in leading a project or joining the OpenStack TC, I'd encourage you to submit a nomination through the openstack/election repository [2]. The Call for Proposals soliciting project team updates and Forum sessions at the OpenInfra Summit (17–19 October 2025) in Paris-Saclay will be closing on 2025-07-08 at 23:45 PST [3]. The schedule for the event is live and contains some exciting material [4]. In the past week, the OpenStack Technical Committee didn't merge any significant governance changes. However, some proposals are open for the community's review. === Weekly Meeting === The last weekly meeting of the OpenStack TC was held simultaneously on Video (Meetpad) and IRC (OFTC's #openstack-tc channel) on 2025-07-01. The recording of the meeting was posted to the TC's YouTube channel [5], and meeting notes were logged on IRC [6]. The meeting was brief yet efficient, covering updates on various ongoing initiatives. TC members were glad to see the smooth implementation of the Developer Certificate of Origin (DCO) enforcement, with minimal issues reported and proactive steps taken to manage tooling changes. Key action items from the previous week, such as addressing inactive projects and the Eventlet deprecation, were discussed. We noted progress on Cyborg's potential revitalization through new and returning maintainers. We discussed the critical and impending bug in PBR [7] due to upstream changes in Setuptools. The OpenStack user survey remains open until August [8], and the TC would like broader community participation. Lastly, we made plans for a "meet-and-greet" forum session with the OpenStack TC at the upcoming summit. This would be a valuable opportunity for community engagement and discussion of TC responsibilities. We do hope to have at least half of the current TC at the summit. The next meeting of the OpenStack TC is on 2025-07-07, and will be hosted on the #openstack-tc channel on OFTC at 1700 UTC. Please find the agenda and other details on the meeting's wiki page [9]. I hope you'll be able to join us there! === Governance Proposals === ==== Merged ==== - Remove mentions of CLA in licensing guide | https://review.opendev.org/c/openstack/governance/+/953843 ==== Open for review ==== - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Add service-types-authority to SDK deliverables | https://review.opendev.org/c/openstack/governance/+/953548 - Deprecate shade, os-client-config | https://review.opendev.org/c/openstack/governance/+/953549 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ - 2025-07-26: OpenInfra Days, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] Submit a PTL/TC candidacy: https://governance.openstack.org/election/#how-to-submit-a-candidacy [3] CFP for Forums/Project Updates: https://cfp.openstack.org/app/2025summit [4] OpenInfra Summit Schedule: https://summit2025.openinfra.org/a/schedule [5] TC Meeting Video Recording, 2025-07-01: https://youtu.be/eJ03g0w8Ers [6] TC Meeting IRC Log 2025-07-01: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-01-17.00.html [7] pbr setuptools incompatibility: https://bugs.launchpad.net/pbr/+bug/2107732 [8] Take the OpenStack user survey: https://www.openstack.org/user-survey [9] TC Meeting Agenda, 2025-07-08: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

5 months, 3 weeks

Re: [oslo] Remove eventlet from openstack.

by smooney＠redhat.com

replacing oslo.service was not in the set of thing we were condierign doing in nova this cycle but if we compelte the ohter work and i finish the other feature im ment to work on i might try swaping in Cotyledon if anyone trys that for any other service or feels like trying it in nova the i owuld be happy to review to see what that looks like. looking at the gaps im not sure how much of them actully matter at the end of the day i.e. we planned ot remoe the eventlet backdoor debuging supprot with the removal of eventlet anyway so thet fact Cotyledon does not hook that up is fine. similarly we talked about removing the standaloen wsgi console script for nova-api or replacing it with something else like flask ectra so the wsgi supprot might not be an issue either. we will just have to asses those gaps when it comes to proting and if there is an upgrade impact that we can or cannot accept. teh fact that ceilometer and aodh use Cotyledon is at least encuraging espically since that implies the distor packageing shoudl already be in place but i just wanted ot make it clear i was not focusing on the governace question but also the technical gaps i was expeict that oslo.service would not be released as part of the eventlet removal and instead would have been ported to not depend on eventlet. i.e. have oslo.service perodici tasks just delegate to futurist providing the same api with a diffent backend. so i was kidn of surprised to see this topic come up. ill see if i can find time to do a poc but it wont happen until at least late july or august based on the other thing on my plate so if other do have a poc to share of portign ironic or neuton or cinder ectra that might fill in some of the gaps. On Tue, 2024-06-11 at 23:11 +0100, smooney(a)redhat.com wrote: > On Tue, 2024-06-11 at 22:36 +0200, Andriy Kurilin wrote: > > Hi! > > > > вт, 11 черв. 2024 р. о 16:26 <smooney(a)redhat.com> пише: > > > > > On Tue, 2024-06-11 at 14:09 +0000, Dmitry Tantsur wrote: > > > > Hi, > > > > > > > > On 6/10/24 10:30 PM, Daniel Bengtsson wrote: > > > > > > > > > > > > > > > On 2024-06-10 16:28, Dmitry Tantsur wrote: > > > > > > If we go with this proposal (which sounds reasonable), we need to > > > > > > carefully look at cotyledon's maintenance. It seems to be on life > > > > > > support by only one volunteer: > > > > > > https://github.com/sileht/cotyledon/commits/main/ > > > > > You're right but he is pretty active and I don't think it's a big > > > issue. > > > > > > > > How do you judge that? Herve mentioned a PR merging quickly, but that's > > > > not a perfect criteria. I have a pet project (rust-openstack) where I > > > > also tend to merge PRs quickly. Except when I'm on a vacation or very > > > > busy at work, then I can forget about PRs for a month or more. > > > > > > > > Note that I'm not saying "let's not use it". I think a reasonable next > > > > step, if we decide to research this part, would be to get in touch with > > > > the maintainer, understand their plans and their position on adding more > > > > maintainers in the future. > > > > > > i think in one of the other replies they mentioned propsoing it as a > > > deliverbale > > > under the oslo project so if that happens i think the maintainer ship and > > > co installablity (use of upper constratits) issues as well as goverance > > > issues > > > go away > > > > > > > Why do we still rely on SQLAlchemy and do not request Michael Bayer to move > > the library under OpenStack governance? Most contributions come from a > > single maintainer. The project already uses Gerrit, so the contribution > > flow will be similar, right? > > > > Also, do you believe that moving projects under OpenStack governance > > magically increases project aliveness? > > Let's discuss the "ldappool" library. It is under OpenStack governance and > > is required for LDAP integration in Keystone. Is it alive? The last release > > was on February 26, 2021. This release includes a bug: the usage of a > > dependency that is missed in requirements.txt - the "six" library. > > The fix waited for two years to be merged > > https://review.opendev.org/c/openstack/ldappool/+/805495 , and there is no > > new release with it. > > Hm... So, magic OpenStack governance did not help?! How did this happen? > > > > Sorry for these sarcastic questions. I only tried to say that independently > > of project governance, the project may die and become unmaintained. The > > only valuable thing is the contributors. > > Asking a project maintainer to move from "his" development flow to work > > under OpenStack governance before reducing "his real maintainer's costs" > > sounds strange. > > If openstackers start actively contributing to Cotyledon, moving under > > OpenStack governance as Cotyledon community decision sounds reasonable to > > me. Otherwise, it doesn't sound nice. It is not "a chicken&egg problem"; > > the primary action should be obvious. > > its not about being in or out of openstack or opendev governance. > when i looked at the repo and swap it was using different build tooling > was not using upper constraint and may or may not be co installable. > > for practial pourpuses we would need to make depend-on work in ci which > means usign the github zuul integration and ensuring that devstack libs_form_git funcitionatliy > works to be able to test changes before they merge. that woudl be simpler if it was hosted on opendev > but its not a blocker. > > cotyledon is using pytest as a test runner instead of stestr so im not sure if that > will integrate well with our ci tooling, i.e. we wont have subunit output to render test report for. but that porbaly > less problmatic then if it was actully using pytest as the test framework. > pytest can produce some nice html report but form normal openstack contibutor point > of view a proejct that is not aligned to the PTI will add a slight learing curve especially if > contirbutions is via github prs. > > there is enough divergance form what we normally use in the rest of openstack > to potentially be problemaitc in the furutre. for exmaple its not using oslo.logging for logging, > its using the pythong logging framework directly so we would need to ensure that it integrated > properly with oslo.logging and our exiting log cofniguration that provides. > > on the doc front it has very little docs in tree > and doees not appear to have a 1:1 mapping to the apis provided by oslo serviece. > > so my initial read is that it probably isn't a suitable drop in replacement in its current state. > > as oslo.service is a very core part of the services and we expect things like GMR ectra to ingenerate with > specific behavior related to the use of sig_user2 so we need to evaluate how Cotyledon is > operating system singles given the libary claims > > "Reload API (on SIGHUP) hooks work in case of you don't want to restarting children > A separated API for children process termination and for master process termination > " > > i think this is the relevnet code so it looks like it does not touch sig_user2 > https://github.com/sileht/cotyledon/blob/main/cotyledon/_service.py#L221-L2… > so the GMR aspect is proably fine > > what im less sure about is Cotyledon states it does not > > " > facilitate the creation of wsgi application (sockets sharing between parent and children process). Because too many > wsgi > webserver already exists. > " > > however nova does use that functionality in oslo.service > https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi_app.py > so that is a potentially a blocker for nova to use it unless we rewirte how our wsgi applicaiton works. > > for what its worth iwould nto be agaissnt replaceign our current usage with flask or similar but > a project that was built to replce oslo.service for celimiter is not nesssiasarly a good fit for > all other openstack porjects that use oslo.service. > > so to me Cotyledon has a lot of open question that woudl need to be answered not related to the > governance > > > > > > > > > > > > Dmitry > > > > > > > > > > > > > > -- > > > > > Daniel Bengtsson > > > > > Software Engineer > > > > > > > > > > > > > > > > > >

1 year, 6 months

Re: debugging eventlet services in vscode.

by Herve Beraud

Hey Sean, Thanks for sharing it with us. Do you want to add it in a more formal way in our toolbox/materials related to Eventlet? Maybe in a dedicated section inside https://wiki.openstack.org/wiki/Eventlet-removal or in a parallel document linked into the wiki? As you want. Le mar. 5 nov. 2024 à 02:37, Sean Mooney <smooney(a)redhat.com> a écrit : > > hi folks i recently had to debug a problematic interaction between > eventlet and a native thread in watcher. > while i probably could have printed my way though that eventually i > decided to try and get debugging working > in vscode instead. > > > in this case i happened to be looking at watcher but this should apply > to any eventlet service installed with devstack. > > > in my .vscode directoy i created a launch.json that looks like this. > > { > // Use IntelliSense to learn about possible attributes. > // Hover to view descriptions of existing attributes. > // For more information, visit: > https://go.microsoft.com/fwlink/?linkid=830387 > "version": "0.2.0", > "configurations": [ > { > "name": "Python Debugger: watcher-applier", > "type": "debugpy", > "request": "launch", > "program": "/opt/stack/data/venv/bin/watcher-applier", > "console": "integratedTerminal", > "args": [ > "--config-file", > "/etc/watcher/watcher.conf" > ], > "gevent": true, > "env" : { > "PYTEST_CURRENT_TEST": "true" > } > }, > { > "name": "Python Debugger: watcher-decision-engine", > "type": "debugpy", > "request": "launch", > "program": "/opt/stack/data/venv/bin/watcher-decision-engine", > "console": "integratedTerminal", > "args": [ > "--config-file", > "/etc/watcher/watcher.conf" > ], > "gevent": true, > "env" : { > "PYTEST_CURRENT_TEST": "true" > } > } > ] > } > > > there are a few odd things about this config. > > first the program i am launching is the console script run in the > devstack@* systemd service file. > you can find what that is using systemctl show devstack@<name> > to make this work without conflict do `sudo systemctl stop > devstack@<name>` first. > after your done debugging you can just start the systemd service again. > > second when using vscode to view the source of a project select the > devstack global virtual env as the project virtual env. > > third im telling vscode to enable gevent support. > now this will raise a warning/error as gevent is not installed but you > can ignore that. > for those of you not familiar with gevent its a fork of eventlet that > actually has much better integration > with debuggers due to its wider usage outside of openstack. > eventlet and gevent both use greenlet and the eventlet implementation is > close enough that when you enable gevent debugging > it mostly works. > > forth to fix the "mostly" part, specifically the fact that dajngo will > explode on import, we set "PYTEST_CURRENT_TEST": "true" in the terminal > env. > > PYTEST_CURRENT_TEST is an undocumented environment variable intended > only for unit testing that is check by eventlet > > https://github.com/eventlet/eventlet/blob/8637820f468268ffb0b8504561ea4772d… > when we set that to true we skip this `isinstance(o, rlock_type)` check > > https://github.com/eventlet/eventlet/blob/8637820f468268ffb0b8504561ea4772d… > which crashes the debugpy debugger because it tries to load setting form > the danjgo module which get loaded into > the python interpreter as a side effect of debugpy. > > i have not tried this on other project yet but it enables me to single > step debug, run to breakpoints and many of the normal > debug action like using the debug console to inspect the current > function scope. > all of the above worked without any code change to watcher or running in > a specal debug mode in the service code. > > we occasionally get questions on this list about how to debug openstack > services and i usually respond with > > "its possible to do, is often fragile and need a lot of context to do > right" > > in this case it seam to work reasonable ok in the limited usage i have > made of it so far. > given the current incantation is pretty simple and non invasive i > decided to share this > in case others find it useful. > > keep in mind however most service are distributed systems so if you > leave it stopped > on a break point for 5 mins while you inspect things, what ever you were > originally doing will probably time out and > it might fail in odd ways but for local development that may still be > fine. please don't try this in production. > > i have not tried this with a wsgi app. that probably will work fine with > the eventlet wsgi web-server via the console scripts > > i.e. nova-api binary but probably wont work for uwsig/Apache. > > > regards > > sean > > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year, 1 month

sean speak and you! was Re: Eventlet and debugging

by smooney＠redhat.com

On Thu, 2024-08-15 at 17:36 +1000, Mike Carden wrote: > In almost a decade of reading smooney(a)redhat.com's Lysdexic posts, this is > the longest one I have ever read. No criticism intended at all - none > whatsoever. > > BUT... I am still absolutely Gobsmacked that anyone can possibly write even > vaguely working code, if their written English communications are so > comprehensively broken. How does anyone get away with ignoring Spelling and > Grammar in Code? > > I love your work Sean, but I do struggle to understand almost everything > you type. no worries short answer is i have more tooling to help when im writing code if im not in a rush or its a more formal topic i heavily rely on things like grammerly or spellcheckers to fix what i typed. as my typeing speed has increased the things i used to only do when writing i.e. swapping/skipping letters or writing a word other then the one i intended have unfortunately increased as i am now more or less using muscel memory for typing and that allow my dyslxia to propagate to my typing in a way that does not otherwise happen. when im coding i actually type much slower as i am mentally thinking more about the code and my ide will also complain at me. i even added codespell checking to nova recently with pre-commit to prevent future typos form being introduced to the codebase as they do get missed in review. tools like codepoilt can also help. when i use it is more or less like auto correct/spellchecking on steroids then actually for code generation. just be careful if you start a comment with NOTE(sean-k-mooney): i have seen it emulate how i write comment including typos before :) you hopefully wont have that problem but i have started to use it to help me write comments because its mostly less error prone then when is entrily write it by hand. in this case the main reason for all the typos is it was almost midnight and i was tired. the more tiered i am the more this happens, the same if i am distracted. effectively the more i rely on my touch typing ability and dont look a the keyboard the more mistakes i will make as when i read back what i typed I'm not actually reading. i think i am but what I'm actually doing is skiming the text and filling in the blanks form my working memory and not seeing what i typed. when it comes to code that is mitigated because i see the code in my editor, then i see it presented differently wiht git diff and finally after i push it i open it in gerrit and see it presented differently again there. that 3 phase reivew has enough visual different that i will actully read the text instead of rememebering it. the fact that copilot can help mask my dyslxia is actully the main reaon i didnt cancel my yearly description because i does help with that alot. i proably should pay for grammerly premium however. especially since if im not in a rush i used it to write all my specs after the initially draft. when i don't people have issues comprehending them :) and rightly so i sometime wonder how i typed what i typed and didnt notice :) if anyone has recommendation for email clients or plugins that can help let me know. i have been holding of actually using an IDE/Emacs for email but maybe i should. currently i use evolution but i used Thunderbird for years. in case its not obvious i spend about 15 mins actually fixing the typos in this email and im sure i have missed some. i find that incredible tiring but im always looking for ways to make my written communication better, so i welcome any suggestions. > > -- > MC > > > > On Thu, 15 Aug 2024 at 08:07, <smooney(a)redhat.com> wrote: > > > On Thu, 2024-08-15 at 01:49 +0530, engineer2024 wrote: > > > Thanks to both of you for the response . I try to insert pdb breakpoint > > at > > > some point in the code files and start the service. Then I issue a nova > > > command to check how the flow works. From then on I use the pdb commands > > to > > > check the function calls. This to me gives a very convenient way of > > > learning the code connections, since I don't have an idea of how these > > > functions and modules r related. U people as developers have a design to > > > start with and work on from there. So u may know the purpose of each > > > function, class, etc. > > > > > > Since nova api doesn't support pdb becos of eventlet design, I learned to > > > print those objects and find their information. > > > > > > But with pdb, it's a smooth flow to inspect the class attributes, their > > > functions, arguments, types etc. I can even test those objects the python > > > way since pdb supports python prompt as well. Of course I do all this on > > > dev systems though... > > > > this is going to be a long responce and its a bit rambely but im goign to > > provide > > you with the context and poitn er try and figure out how to do this for > > your self. > > > > first thing to note is while its possibel it not trivial and the payoff is > > proably not > > worth it in the long run. we do not have up to day docs for how to do this > > because > > this is not how peole learn, contibute to ro develop nova in genral. > > > > > > nova does have a remote debug facilitate that is sepreate for the eventlet > > backdor to enable > > you to use an ide to debug remotely. > > that was added around 2012 and has worked on an off to vering degrees > > since then. > > > > the first thing to understand about nova and several other project is that > > they are a distibuted system > > i.e. the applciaiton that compise a given service like nova run in > > multiple service which are interconnected > > vai a message bus with in a service and rest apis are exposed for inter > > service comunication. > > > > when you enable a debugger and stop on a breakpoitn only one of the > > process is stop and the other contiue > > to exsculte which means that RPC calls, heathbeats and other asynconos > > tasks can and will timeout and fail. > > > > you cannot debug a distibuted system in teh same way as you woudl a simple > > applction where all state > > is executed in a signle main loop. > > > > the act of observing the internal behavior of the nova api or nova-comptue > > agent will change its behavior. > > > > nova has suppoort for remote debugging that was added about 12 years ago > > https://wiki.openstack.org/wiki/Nova/RemoteDebugging > > https://github.com/openstack/nova/blob/master/nova/debugger.py > > > > with that supprot you can use an idea like pycharm to connect to the > > remote debugger and attempt to > > debug a process. > > > > im currently propsoing removing that as part of the removal of eventlet > > partly because it shoudl not be needed > > when we dont have enventlet and mainly because it didnt work very well > > when i last used it. > > > > some ides have supprot fo gevent > > > > gevent is a fork of eventlet which was forked form some of hte libiares in > > stackless python > > eventlet converts a single thread python interperater in a cooperative > > concurent multi userland process. > > > > what does that mean , each python function is not operating in a seperate > > os stackframe, it has heap allcoated > > stack frames that allow context swtichs between userland thread at any > > tiem a funnction woudl do blocking io > > > > the reason single step debugging does not work well with gdb is that when > > you single step the eventlet engine > > is often going to end up context switching into the midel of another > > function. > > > > to work around this you just set breakpoint at the line you want to go to > > next and use continue instead fo single step > > > > one of the rules when using eventlet is that if your going to monkey > > patch you need to monkey patch everyting early > > > > in addtion too the remote debuging facilites we can disabl mokey patching > > entirly. > > you can do that by settign OS_NOVA_DISABLE_EVENTLET_PATCHING=1 > > https://github.com/openstack/nova/blob/master/nova/monkey_patch.py#L87 > > > > this will entirly break nova-compute and several other nova process as > > they have > > effectivly infinity loops to pool for rpc messags, monitor hyperviors > > ectra. > > > > if the remote debugger is used it disables patching the thread lib > > https://github.com/openstack/nova/blob/master/nova/monkey_patch.py#L44-L46 > > > > that is prartly why usign the remote debugger is kind fo buggy in itsself. > > the code is not inteded to work that way. > > > > these fucntionlatiy mainly exist to allow debuging tests not the actulaly > > running code. > > > > if i need to debug test i normaly jsut comment out > > https://github.com/openstack/nova/blob/master/nova/monkey_patch.py#L83-L89 > > and run the test in my ides(pycharm,vscodes) test debbuger. > > i normally code in nano/emacs but is do use ides if i really cant figure > > out what happening > > however i genreally start with just adding log lines. > > > > when i first started workign on opentack in 2013 i very much liked using > > an ide and debugger > > and i woudl often spend time trying to get nova to work in a debugger. > > > > over tiem i generally found that that was not worth the effort. > > keepign a devstack deployment working that way was often more work then > > doing print staement > > or better writing functional or unit test to repoduce the problem. > > > > you previous mails ask about debuging nova's api. > > > > if you want to do that its one of the easiest thigns to debug. > > first do _not_ use the wsgi script > > adding apache of modwsgi is just going to make your life harder. > > > > just disable eventlet monkey patching, by commetiing or usign the env > > varible > > and run the nova-api console script directly under pdb or your debugger of > > choice. > > that will allow you to basiclly single step debug without any issues as it > > will not be using eventlet > > anymore and it has not infinitly loops or perodic tasks so it mostly just > > works when not using eventlet. > > > > that becase it didnt use eventlet at all in the api until about 2016 and > > even today it only really uses it in one place > > in my eventlet removal serise i split nova in to the part that use > > eventlet directly and the parts that dont in the > > second path > > > > https://review.opendev.org/c/openstack/nova/+/904424 > > > > anything under nova/cmd/eventlet/ needs eventlet today > > everything under nova/cmd/standalone/ does not. > > > > the approch of doign an api call and following it in a debugger is not a > > good way in my expericne to learn how somethign > > like nova really works. it can hellp to a limtied degree but you cant > > eaislly debug across multipel processes. > > a minium nova deployment has 4 process typically more. > > > > you can try but each openstack service (nova, neutorn, cinder, ...) is > > typically compised of several micocservices > > some like keystone and palcement are just rest apis in front of a db and > > dont use eventlet at all so are trivial to > > debug as a result. the rest have non tirival runtime interactions that > > cant be as eaislly decompsed. > > becuase of that nova and other project invest in our functional tests to > > allwo ues to emulate that multi process env > > and better reason about the code. > > > > the debugging functionality is documetned in the contibutor guide > > > > https://github.com/openstack/nova/blob/master/doc/source/contributor/develo… > > but we dont really adverstise that because none of the core maintainers > > use that any more and it has not been maintained > > for the better part of a decade. since we cant use this type of debugging > > with our ci system > > if we cant debug why a failure happens form the ci logs we add more logs > > because thyat will be useful for future us > > and operators in production. so our focus is on logging/monitoring for > > production rather then for developer eases > > simply because of the large techdebt that eventlet creates in this aready. > > > > i know nuetorn has had some better look with using debuggers then nova has, > > > > keystone/placmnet are eventlest free adn are just python web apps/rest > > apis so should "just work" > > in any python debugger. > > > > nova is prehaps the hardest to debug because of the legacy of the proejct > > so its not the best palce to start looking > > how this works. too be clear i have ran nova api, nova-conductor, nova > > scheduler and nova-compute all in 4 ide windows > > with 4 debuggers at once > > it was proably 3 year of working on openstack before i understood how to > > hack that ot work and since i learned > > how to properly debug without a debuggger, logs, code inspection, > > unit/fucntioal testing > > i have nver really need to do that again. > > > > > > gaining the ablity to run openstack in a debugger simply again, in a > > maintainable way is deffienly one of the reason im > > looking forward to removing eventlet but its still a lot of work. > > im not sure how helpful this was but this is proably as clsoe to a blog > > post as you will get. > > > > > > > > On Thu, 15 Aug 2024, 01:04 Jeremy Stanley, <fungi(a)yuggoth.org> wrote: > > > > > > > On 2024-08-14 22:38:43 +0530 (+0530), engineer2024 wrote: > > > > > How many more releases are you planning to include eventlet in > > > > > them? Seems they are removing any support for further development > > > > > according to their official website. So, is the community thinking > > > > > of any alternatives? > > > > [...] > > > > > > > > Just to expand on the first part of Sean's reply, most of what you > > > > want to know is probably answered here: > > > > > > > > > > https://governance.openstack.org/tc/goals/proposed/remove-eventlet.html > > > > > > > > -- > > > > Jeremy Stanley > > > > > > > >

1 year, 4 months

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

by Jay Faulkner

Hey Kendall, I sent Ironic's team photo and what info we had on PTG attendance on Wednesday, November 5th to ptg(a)openinfra.org -- if you need I can resend. -Jay On 11/9/25 6:26 PM, Kendall Nelson wrote: > 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

[manila] 2026.1 Gazpacho PTG summary

by Carlos Silva

Hello, Zorillas and interested stackers. Here's a summary of all the discussions, decisions, action items and plans we came up with during last week's PTG. All of the recordings are available in this playlist [10] from the OpenStack Manila Youtube channel. In case you missed something and would like to get back to the discussions, please refer to it. Flamingo Retrospective ================== We discussed what went well and what needs some attention in the upcoming cycles. - Bugsquash events and collaborative review sessions are having a positive impact on bugs being closed and features being reviewed faster. - The mid cycle helped with the reviews of the changes prior to the feature freeze. - We had several interns working on Manila UI, OpenAPI patches and fixing other known issues in Manila, providing good opportunities for community engagement. - We had enhancements on the review bandwidth but we should keep looking on adding more core reviewers to Manila and help share the load on reviews. We didn't manage to cover all topics, so the retrospective will continue in the next Manila upstream weekly meeting, November 13th. All Things CephFS: Status and Gazpacho Plans ===================================== Status updates ------------------------ - Allocated Capacity GiB fixes and thin provisioning improvements are being backported to older releases. - fs_name metadata is now also used in Manila CSI [2] - Patches to introduce CI testing for CephFS manage/unmanage operations will be included in the Gazpacho cycle. Plans for 2026.1 Gazpacho ------------------------------------ - We started testing with Ceph Tentacle release candidate images in the devstack jobs and will merge these jobs once the official Ceph Tentacle release is out. *QoS:* NFS Ganesha v7 supports QoS, i.e., throughput throttling (iops and bandwidth) Manila team intends to start the CephFS NFS driver implementation during this cycle. The implementation is expected to support the new proposed QoS types alongside driver-scoped share type extra specs. *Share encryption (BYOK):* NFS-Ganesha and Ceph communities are working on Bring-Your-Own-Key subvolume encryption. The team will work on a Proof of Concept (PoC) to extend the existing BYOK Encryption feature in Manila to support shares encryption with CephFS. *OVN extension targeting NFS-Ganesha* Discussion is ongoing with the Neutron project team for adding an extension to the OVN agent [3], which aims to improve usability and security in a cloud that relies on NFS-Ganesha to provide RWX storage volumes to end-user workloads. [NetApp] Sync snapmirror support and Async snapmirror enhancements ======================================================= NetApp is adding support for zero RPO (i.e., synchonous mirroring) with Share Replication - a feature that's been supported by this driver since the Mitaka release. Doing this will involve some more tenant-visible directives. The Manila team considered it as a good enhancement, but suggested implementing share replicas metadata as the vehicle for this change, as this will make it more extensible and reusable in the future. The NetApp team agreed with this approach and will work on implementing share replicas metadata in the Gazpacho cycle. Graduating Migration and Backup APIs ============================== Share backup APIs -------------------------- The Share Backup APIs are mostly feature complete. We're missing a way to force backup deletion and the ability to set backup quota via the CLI and UI. Some improvements are planned for the Share Backup driver abstraction as well. We are also evaluating the possibility of adding testing with CERN's CBACK utility and Backup driver in the CI, and Zac is working on further enhancements for targeted restores. Share migration APIs status ------------------------------------- The share migration APIs have been stable for a while and well tested. We believe that this API is ready to be graduated and we need a contributor to help drive this to completion. Share Encryption follow up ==================== The Manila team discussed the known issues and gaps noted while reviewing and merging this feature in the flamingo cycle: - Inability to unmanage/manage share servers with encrypted shares: the NetApp team will investigate how to implement the changes to the manage share servers workflow. - We agreed that this should also follow steps similar to the creation workflow, as, for example, checking if the barbican key exists, if the user can manipulate it, and if it matches the one from the share server. - Inability to migrate share servers and setup share replication: the NetApp team will look into the required next steps. NetApp - NAE (NetApp Aggregate Encryption) Support ========================================== NetApp is planning to add support for encrypted pools (aggregates) to Manila when DHSS=True is in use [4]. It will allow customers to encrypt the shares (volumes) data by assigning the encryption key to aggregate level. The Manila team is okay with this proposal and the NetApp team will start this implementation in the Gazpacho release cycle. Adding new/failure notification ======================= We currently have notifications for share operations (create, shrink, delete). eunkyung, a contributor from Samsung would like to add notifications for other operations in Manila (creating snapshots, reverting to snapshots and others). The team agreed that this is a great addition, as we started with notifications for shares but didn't have the cycles for adding notifications to other resources. This change will be proposed to Manila and the Manila team will share feedback. Add mount_point_name option to managing share ====================================== It is currently possible to define a custom mount point name to a share export location, but while managing a share, it is not possible. We discussed the possibility of extending this feature to the manage workflow and agreed that this is will be a great improvement for the operators. This feature will be proposed during the Gazpacho cycle and the Manila team will review. QoS enhancements =============== Kiran shared a proposal for introducing QoS types in Manila, with the possibility of having multiple QoS types being linked to a share type. The QoS types will be added to the share servers and shares created. The team agrees that this is a nice addition, and we asked more details in the specification [5] seeking clarifications on spec conflicts and to elaborate on the need to tie the QoS types to the share type itself, instead of using an approach to tie them directly to shares or share servers. Eventlet Removal ============= The manila team is actively working on removing eventlet. We used this topic to talk about the progress from the team, share our plans, roadmap and discuss an issue shared by Eric from the Cinder team, where sqlalchemy objects shared by multiple threads were affected when dropping eventlet from the cinder-volume service. damani joined us for the discussion and has started on changes that are going to address this behavior [6][7]. The Manila team intends to support running all manila components without eventlet by the end of the Gazpacho release. Dropping the v1 API =============== The Manila v1 API was deprecated ~10 years ago and we intend to remove it during the Gazpacho Cycle. Removing it will clean up our code and make enhancements such as the JSON Schema Validation work easier. This work will help us with the OpenAPI schema and documenatation enhancements that we've been slowly closing the gap on for the past few releases. AI: carloss will send an email to the mailing list announcing the removal. JSON Schema Validation =================== We shared the current status of the JSON Schema validation changes in Manila and also talked about the lack of reviews in the open changes. We decided to split changes up into smaller chunks, making it more friendly to new contributors, and to reviewers. AI: carloss will organize a Review Jam to help making progress, as well as unify the tracking of the current issues being worked on in a Taiga board [8]. Manila client removal + merging manilaclient's OSC functionality into OSC ======================================================== The Manila CLI utility was deprecated several release cycles ago and we intend to remove it in the Gazpacho cycle. We also discussed moving Manila's OSC functionality from python-manilaclient into openstackclient itself. Doing this will reduce the burden to discover and import command modules at runtime, significantly improving performance of OSC. We discussed the work that would be needed and how it would affect the release process. NetApp REST/ZAPI situation ====================== Retirement of NetApp's ONTAPI is currently on hold [9]. Many OpenStack users are still heavily relying on ZAPI because of how the NetApp drivers in Cinder and Manila integrate with the product. All new ONTAP features will be added only to REST, with no fallback approach to ZAPI. So, the drivers in OpenStack have started seeing implementation changes over several releases to support NetApp's REST API where available. The NetApp team is also putting efforts into identifying the gaps between REST and ZAPI in Manila. As for CI Testing: Stabilizing CI runs with REST is a priority for the NetApp team, with an engineer actively working on the necessary fixes. Improvements for managing shares/snapshots =================================== The proposal is to update the snapshot's created_at field to reflect the creating time on the storage backend during the manage operation, rather than the time recorded by Manila. We agreed with the proposal but also think this should be applied for the shares. A blueprint will be registered and inyonghong will work on the fix. Dell's PowerScale driver roadmap ========================== We heard requests for a couple of features in the Dell PowerScale drivers: - manage/unmanage for shares and snapshots - revert to snashot - custom mount point names - QoS. We noted that the revert to snapshot feature is already being worked on by the Dell team and the Manila team will review the changes and target them for the gazpacho cycle. [1] https://etherpad.opendev.org/p/gazpacho-ptg-manila [2] https://github.com/kubernetes/cloud-provider-openstack/pull/2994 [3] https://review.opendev.org/c/openstack/neutron-specs/+/936063/3/specs/2025.… [4] https://etherpad.opendev.org/p/nteapp_nae_support [5] https://review.opendev.org/c/openstack/manila-specs/+/962706 [6] https://review.opendev.org/c/openstack/oslo.service/+/963742 [7] https://review.opendev.org/c/openstack/oslo.service/+/965208 [8] https://tree.taiga.io/project/gouthampacha-manila-jsonschema-openapi/kanban [9] https://kb.netapp.com/on-prem/ontap/DM/REST-API/REST_API_KBs/Deferral_of_ON… [10] https://www.youtube.com/watch?v=3O3ByYU6gHc&list=PLnpzT0InFrqAf4kRsXDoVpv0V… Lots of positives to take from this PTG and definitely a productive cycle ahead. Thank you for your participation! Regards, carloss

1 month, 3 weeks

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

by Herve Beraud

Le jeu. 16 mai 2024 à 13:31, <smooney(a)redhat.com> a écrit : > 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 Nice to see this initiative, maybe we could reference it (in the proposal or elsewhere) and give additional details to offer a way to go to others. Again, I'm not married to asyncio. To initiate this topic we had to choose a solution, I chose Asyncio, but any proposed solution is welcomed, as long as it helps to exit from the Eventlet dead end. > > 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. > Another option for libraries, would be to implement in various oslo libraries, new drivers/backends fully based on third parties libs who are based on asyncio, and in parallel to continue to maintain the current existing drivers/backends. Mike Bayer suggested that oslo.db may provide an asyncio interface for applications that want to make use of this. To that end the main working interface in oslo.db is oslo_db.sqlalchemy.enginefacade, so we would propose a layer on top called oslo_db.sqlalchemy.asyncio_enginefacade or similar. it would provide the async versions of SQLAlchemy objects as well as provide for asyncio context managers. The existing interface will remain there in parallel. Oslo.messaging may implement a new rabbitmq driver based on https://github.com/Polyconseil/aioamqp and keep the existing driver around. I agree we should not want to close the door for alternatives like threads and futurist, If futurist avoid us wasting too much time removing Eventlet, then let's go with this kind of option, but in all cases I think we should not close the door to asyncio either. Using Asyncio may make sense in many scenarios. If libraries do not provide async based interfaces in parallel with the sync based interfaces, then, I think we more or less definitely close the door of using Asyncio in Openstack or at list we really limit its introduction. > > > > > To conclude, is it still worth it to spend time updating this proposal > > again or is your decision definitive? > > > > Thanks Sean -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year, 7 months

Re: [all][elections][tc] TC Election Campaigning Kickoff

by Chandan Kumar

On Tue, Aug 26, 2025 at 12:58 PM Sylvain Bauza <sbauza(a)redhat.com> wrote: > > > > Le mar. 26 août 2025 à 08:16, Goutham Pacha Ravi <gouthampravi(a)gmail.com> a écrit : >> >> Hello Candidates, >> Thank you Goutham for starting the discussion. >> I'd like your view on handling a project team that is essential to the >> OpenStack ecosystem but is struggling with a lack of active >> contributors or a sustainable governance? >> > > That's a very good but also tough question, and we’ve had experiences in the past related to it — including one very active as we speak. There are actually different approaches to this problem, depending on the overall nature of the project: > Indeed, it is a tough question. > If there are only one-off contributors and a lack of governance, I think we can reasonably identify that dependency as part of the OpenStack ecosystem if it is essential, and then determine whether we should propose the project to join the integrated release — based also on feedback from the release management team. > > If the project itself is lacking support, then there is no magic bullet (in terms of finding “white knights” to save the project). In that case, we (as the TC) should evaluate the dependency needs: Is it a shared dependency across our OpenStack projects? Do we have an alternative that is very close to the existing project? Could another project volunteer to take it over (for example, the Nova team accepted to take back responsibility for the Placement service)? The eventlet removal effort also shows us that the larger the change, the more difficult and risky it can be so another identical situation would require us to get feedback from the teams but also from the operators in order to come up with a reasonable plan. > I agree with Sylvain that the Technical Committee must mitigate risk by evaluating dependencies and alternatives for a critical project. Alongside that, I believe we must proactively help projects avoid reaching such a situation. Based on my involvement with the Watcher Project, I would like to suggest two approaches that can help mitigate the lack of active contributors and build sustainable governance: - We should promote the Distributed Project Leadership (DPL) model [1] to empower active contributors to share project responsibilities. We did this for the Watcher project; it distributes ownership and empowers more people to lead, making the project more resilient. - To attract more contributors, we must clearly connect a project's work to the bigger picture. For example, linking the Watcher project to the VMware migration initiative gives potential contributors a compelling reason to get involved. The TC can help projects articulate their value and link it to these larger goals. These are the strategies I would bring to the TC to help the current project to thrive. Links: [1]. https://governance.openstack.org/tc/reference/distributed-project-leadershi… With Regards, Chandan Kumar

4 months, 1 week

Re: [nova] Image Encryption patch

by Dan Smith

> > One of the things that is not supported in your series is direct booting > of an encrypted image. I could be wrong, but I think this is just a simplistic read of the first addition in the patch. AFAIK, the direct-boot abort is already in the tree, and they are just adding an additional check for the new key id parameter to mirror the same (existing) behavior. That is, of course, fine. > In April 2024 we had a cross project session with Nova and Glance at the PTG [4]! > There was a big discussion around the encryption format initiated by Dan Smith (Nova). He proposed to move away from GPG and use LUKS instead because this would streamline it with existing functionality and formats that are already available in Nova and Cinder. > Due to this proposal from Nova, we agreed to discard our existing patchsets [5] and rewrite our image encryption feature with new patchsets [6] with LUKS as the encryption format, as suggested by Dan Smith (Nova). > We also talked specifically about the cryptographic key differentiation (hexlify vs. non-hexlify) which materialized in the os-brick change that you mentioned. Yep, this and the rest of your history summary matches my recollection as well. I know I've been on the hook to review this stuff and just keep getting pulled in different directions on more important stuff. My apologies, but there are some pretty important things up for review right now (like eventlet removal). Your patch to use brick for the passphrase extraction seems like a fine thing to merge at this point, especially because the earlier we merge it the better from the compatibility point of view. I'll try to make time today to look at it in detail. --Dan

4 months, 2 weeks

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

by Kendall Nelson

Hi Jay! Yeah, strangely, I don't see it in the solved or open tickets, can you resend? Sorry for the trouble! -Kendall On Mon, Nov 10, 2025 at 10:26 AM Jay Faulkner <jay(a)gr-oss.io> wrote: > Hey Kendall, > > I sent Ironic's team photo and what info we had on PTG attendance on > Wednesday, November 5th to ptg(a)openinfra.org -- if you need I can resend. > > -Jay > On 11/9/25 6:26 PM, Kendall Nelson wrote: > > 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

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