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

Re: [tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)

by Sean Mooney

my personal take on this is it may be a vaild future comunicaty goal but its probably premature. in general most openstack project try to not be in the busyness of Cryptography if we can at all avoid it. our dependicies may have cypto feature like ssh, ssl for our rest apis or similar both the openstack code base in general tries to not implement any cypto logic itself. i.e. we try to delegate to python-cryptography or similar well maintained modules. for example just looking at the nova section you mentioned that nova can genreate ssh keys https://wiki.openstack.org/wiki/Post_quantum_openstack#Nova_.28Compute.29 however we deprecatea and removed that capablity in zed relese in micoversion 2.92 https://docs.openstack.org/nova/latest/reference/api-microversion-history.h… we did that specificly because we did nto want to supprot ssh key generation in nova going forward and defiend that to be out of scope fo our project so that is a non issue in a PQC world because we have decieed as a project not to extend or suprot that api going forward. it has not been removed as we dont do that in nova if its reasonable to keep the code but it shoudl never be used anymore. we only supprot uploading a pre generated public key now. the there two case might be valide ``` Supports validation of Glance image signatures and certificate trust when booting signed images. (link) Metadata path protection with Neutron uses HMAC over Instance-ID to prevent spoofing (shared secret). (link) ``` although for the metadata case that shared secretae is intened to be passed over a https connection so if the ssl encyption for the connection supprot post quantum encyption then the hamc does not really need too but we can likely change that algorhtypme when python cypgoraphy supprot somethign in the future that is a suitable replacement. the glance image verficaiton woudl need glance to support somethign else instead but if they come ups with an updated approch nova coudl adapt. none of the above seem particularly urgent and likely don't need to be addressed in 2026.1 or even 2027.1 but if someone wanted to write a spec for the nova/glance changes and wanted to work on it it could be reviewed via the normal upstream process without needing to make it a comunity goal or have it driven by the TC. you coudl for example create a popup team or sig kind of like the eventlet remvoal work to drive this instead. speaking of which i think the eventlet removal work is gong to take precedence for most team as that is more urgent in terms of real world impact. regards sean. On 27/10/2025 05:14, Goutham Pacha Ravi wrote: > On Fri, Oct 24, 2025 at 1:19 PM Jean-Philippe Jung <jjung(a)redhat.com> wrote: >> Hi, >> >> I am seeking help from the TC to raise the urgency of this work across all OpenStack projects and to help me lead an effort to reduce the number of cryptographic modules used in OpenStack (my personal opinion is that there should be no more than five). >> >> Doing this may involve work in each OpenStack Project team; and I can help organize this effort. I'm seeking the following from the TC and/or project teams: >> Portions of this work will be isolated to specific repositories managed by a project team, while others will involve "cross-project" synchronization. >> What vehicles can we use to have a "call-to-action" for project teams to get someone to look into their specific projects? How can we go about community wide collaboration? >> >> I've created a document [1] that I assembled from AI analysis of part of the OpenStack code. It gives an overall view of the problem we face.\ >> > Thank you for starting this discussion, JP. I've added a topic to the > TC's PTG for 1600 UTC on Friday, 31st Oct 2025. I hope you'll be able > to share your findings there briefly and invite opinions in-sync. Our > vehicle for driving cross project work has been via the Community > Goals framework: https://governance.openstack.org/tc/goals/ > If we have one or more objectives, this can be proposed as one, and > will require a "goal champion" - someone that'll help us gather > requirements, and coordinate efforts to complete the goal. Some goals > in the past have spawned new groups - either as Pop Up Teams or SIGs > (https://governance.openstack.org/tc/reference/comparison-of-official-group-…) >

2 months

[neutron] Bug deputy - week of September 1st

by Sławek Kapłoński

Hi, It was pretty quiet week. Here are details about what happened: ### High - https://bugs.launchpad.net/neutron/+bug/2122065 - ovs agent missing openflow rules due to python error - assigned to Brian, fix proposed https://bugs.launchpad.net/neutron/+bug/2122065 ### Medium - https://bugs.launchpad.net/neutron/+bug/2122110 - [FT] Random errors in OVN ``TestMetadataAgent`` tests - assigned to Rodolfo, fix already proposed, - https://bugs.launchpad.net/neutron/+bug/2122079 - DHCP agent incorrectly releasing leases due to missing client_id - unassigned, Brian already commented there but solution for this may not be that easy to figure out according to the bug report and Brian's comment, ### Low - https://bugs.launchpad.net/neutron/+bug/2121935 - [FT] Random ``DBReferenceError`` errors in the functional tests Edit - assigned to Rodolfo, fix already proposed - https://bugs.launchpad.net/neutron/+bug/2122107 - [FT] Test ``test_initialize_network_segment_range_support_parallel_execution`` failing in the eventlet-removal patch - assigned to Rodolfo, ### To triage - https://bugs.launchpad.net/neutron/+bug/2121961 - Duplicate packet logs with openvswitch driver Edit - I asked Elvira to take a look at it. -- Slawek Kaplonski Principal Software Engineer Red Hat

3 months, 3 weeks

[neutron] Bug Deputy Jul 14 - Jul 28

by Jakub Libosvar

Hi, as I didn’t find the bug deputy report from the last week and confirmed by looking at the IRC meeting logs, I’ve skimmed through the bugs of the last 2 weeks to make sure nothing falls through the cracks. There are a few incomplete bugs that require more info from the reporters in order to find the culprit, seems Brian and Rodolof are on top of it. There is one Critical from today and seems it’s clear what is wrong with it and it seems Yatin is looking at it. Thanks Kuba Critical -------- * tobiko jobs failing while download fedora qcow2 image Edit https://bugs.launchpad.net/neutron/+bug/2118902 Yatin seems to be looking into it Fedora 40 image URL has moved, we need to update the URL to fetch Fedora 41 High —--- * test_subport_delete random failure https://bugs.launchpad.net/neutron/+bug/2117405 Functional test that fails sporadically Assigned to Rodolfo * [tobiko] OVN Metadata agent class failing when using OVN agent https://bugs.launchpad.net/neutron/+bug/2118398 Assigned to Rodolfo Patch proposed: https://review.opendev.org/c/x/tobiko/+/955769 * OVN Neutron agent is being registered as OVN Metadata agent https://bugs.launchpad.net/neutron/+bug/2118876 Rodolfo and Yatin are working on it Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955987 Medium ------- * Horizon shows all prefix lengths when creating subnet from subnet pool https://bugs.launchpad.net/neutron/+bug/2116927 Lajos looked at it as it might be related to the SDK migration, unclear if any fix in Neutron is required * [eventlet-removal] Add N535 hacking check to ban eventlet imports https://bugs.launchpad.net/neutron/+bug/2117373 This is to add the check into Neutron tree but later the check itself was questioned as it might be not working as intended * [neutron-tempest-plugin] Test ``test_create_router_update_external_gateways`` failing https://bugs.launchpad.net/neutron/+bug/2117383 Assigned to Miguel * [unmaintained-only] unknown keyword flow_group_id https://bugs.launchpad.net/neutron/+bug/2117477 Assigned to Bence * [OVN] OVN agents should clean up "Chassis_Private" previous tags https://bugs.launchpad.net/neutron/+bug/2118893 Assigned to Rodolfo Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955998 Low —-- * NotFoundException: 404 error when associating FIP with an unreachable network https://bugs.launchpad.net/neutron/+bug/2118360 Incomplete ---------- * VPN Perfect Forward Secrecy (PFS) is deactivated although configured as active https://bugs.launchpad.net/neutron/+bug/2116723 Rodolfo asked the reporter for more details * Performance Tuning for Nested VXLAN Tunnel in OpenStack (OVS Backend) https://bugs.launchpad.net/neutron/+bug/2116837 Brian asked the reporter for more details * OVN: Intermittent metadata failures for SR-IOV VMs https://bugs.launchpad.net/neutron/+bug/2117078 Rodolfo asked the reporter for more details, the root cause is still unknown * neutron-openvswitch-agent crashes on start https://bugs.launchpad.net/neutron/+bug/2117153 Brian asked the reporter for more details, the root cause is still unknown, happened just once

5 months

[magnum] April vPTG summary and Magnum meeting time change

by Dale Smith

Hello all, I wanted to post a short summary to this list of the vPTG[1] the Magnum team held on April 8th and 9th 2025. These are the topics and a summary of my notes from the discussions. If I missed key details please add these to the etherpad and/or reply here. Thank you all for attending. Please get in touch if the timing of the vPTG did not work for you, as we could propose multiple timezone slots in future. * Heat driver deprecation. o This driver is marked deprecated in Dalmation 2025.1, being replaced by either of the Cluster API drivers, and we discussed when and how we will remove it from Magnum codebase. o We are now looking at removing the Heat driver in this (Flamingo 2025.2) cycle, as waiting longer may imply waiting until 2026.2 due to SLURP release expectations. We would like to hear any feedback on this plan from users of Magnum - either in the mailing list or join one of our IRC meetings[2]. o One option is to move the driver out of tree into its own codebase (perhaps in `x/`), to allow deployers to keep their existing clusters functional and addressable by Magnum while transitioning to a Cluster API driver. This initiative needs effort and a champion to drive it. * Helm charts (magnum-capi-helm driver) o While the driver code is now in opendev the Helm charts live in azimuth-cloud's github. These are a major component of the driver and we discussed the reasoning behind keeping them in github and stability of the Magnum-capi-helm driver. o The current proposal is to snapshot the upstream repo at regular intervals into the opendev repo. This avoids maintenance of a complete fork, but keeps the Magnum-capi-helm driver with a stable internal reference of the helm charts. * CI for the Magnum project was discussed o One big implication of the Heat driver being removed is what we test against. o Including the CAPI drivers (initially non-voting) would give stability, provided external changes wouldn't break the CI. * Normalised labels proposal o Dale has a proposal for Normalised labels[3], aiming for Mutable labels. The video format discussion of the vPTG was very helpful to give context and move the idea forward to cover API backwards compatibility requirements and a better way to implement support labels for different drivers. o The proposal as it stands should be re-worked to look at covering a similar extension pattern that Nova has with drivers, and possibly look to replace labels. * TC initiatives o We discussed the upcoming Eventlet removal and as we are a small team we will wait for guidance and examples to follow before implementing, but we remain aware of this initiative. Finally, I wanted to announce to the list that at last weeks Magnum IRC meeting we proposed and agreed on a new time slot. This is on alternate (every second) Tuesday at 8am UTC starting on the 27th May[2]. See the meeting notes for a full transcript and discussion[4]. Links and references: [1] Magnum vPTG topics and notes can be found on https://etherpad.opendev.org/p/apr2025-ptg-magnum [2] Magnum weekly meeting times and agenda, https://etherpad.openstack.org/p/magnum-weekly-meeting [3] Normalisation of labels proposal, https://review.opendev.org/c/openstack/magnum-specs/+/943358 [4] Magnum meeting 2025-05-14, https://meetings.opendev.org/meetings/magnum/2025/magnum.2025-05-14-09.00.l… Thank you for reading! (or skim reading!) Dale Smith Magnum PTL for Epoxy cycle.

7 months, 1 week

Re: nova-ovs-hybrid-plug CI jobs failing for Nova

by Sean Mooney

so looking at the logs devstack did not compelte on the contoler do it did not even start running on the compute the way these jobs work is we fully deploy the all-in-one controller host, then we copy the data related to the tls or ceph secrets to the subnodes and then finally run devstack on those. once all devstack tasks are complete we then proced to do tempest config and run the tests. the controller failed when creating the inital neutorn netowrks which is not reallse surpisign given the q-svr the nenturon server as not deploysed. 2025-06-29 09:01:01.801 | Error while executing command: HttpException: 500, Request Failed: internal server error while processing your request. 2025-06-29 09:01:01.140 | ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:202 : oscwrap --os-cloud devstack --os-region RegionOne network create private -f value -c id my guess is this is related to the eventlet removal it looks like it has been replaced with the neutron-api wsgi application https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… that has a bunch of sql errors https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… almost as if the schema had not been applied properly. ah yep https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… when it was ran it failed here https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… the hybrid plug job is testing with debian 12 currently and i guess its using 3.11 as a result. the python version might be unrelated but it is a delta form the normal ubuntu 24.04 jobs. the error seams to be sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (1273, "Unknown collation: 'utf8mb4_0900_as_cs'") so it looks liek the version of mariadb/myxql that debian 12 is shiping may not supprot that type. so this is a regression introduced by https://github.com/openstack/neutron/commit/8990dd598f84b9da976d72672c6fd60… debian 12 is one of the testign runtimes so neutron annog uncondionally use that coaltion type this cycle it would be better to use utf8mb4_bin as the case sensitive encoding instead. that is much older then the new _0900_ variants On 29/06/2025 23:16, Michael Still wrote: > Thanks for the pointer. I think its clear that I am not an expert on > this job... However, I note that both the original failed run and > another log this: > > Warning: Permanently added '200.225.47.19' (ED25519) to the list of > known hosts. > rsync: [sender] link_stat > "/var/lib/zuul/builds/12aacd4951a64c0abef5cfe1bf925c2e/work/ca-bundle.pem" > failed: No such file or directory (2) > rsync error: some files/attrs were not transferred (see previous > errors) (code 23) at main.c(1338) [sender=3.2.7] > > Which seems like it might be causing the compute node to not start? I > certainly cannot see any logs from nova on the compute node's zuul output. > > I'll continue to dig. > > Michael > > On Mon, Jun 30, 2025 at 6:15 AM Jeremy Stanley <fungi(a)yuggoth.org> wrote: > > On 2025-06-30 05:36:00 +1000 (+1000), Michael Still wrote: > [...] > > I am unsure who owns 200.225.47.11. Is it possible its offline? > > It's a 2-node job, and that's the address of the controller node > according to: > https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90… > > Maybe check the logs for services collected from the controller to > see if something crashed or failed to start? > -- > Jeremy Stanley >

6 months

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

by Sylvain Bauza

Le mar. 26 août 2025 à 08:16, Goutham Pacha Ravi <gouthampravi(a)gmail.com> a écrit : > Hello Candidates, > > 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: - 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. In any case, whatever the solutions may be, the point is that if something is essential to the OpenStack ecosystem, my personal view is that the Technical Committee has a responsibility to act as a facilitator and help shepherd initiatives that aim to mitigate the risk. -Sylvain Thanks, > Goutham > > > On Wed, Aug 20, 2025 at 4:52 PM Ian Y. Choi <ianyrchoi(a)gmail.com> wrote: > > > > Developers, > > The TC Election Campaigning Period has now started[1]. During the > next > > couple days, you are all encouraged to ask the candidates questions about > > their platforms[2], opinions on OpenStack, community governance, and > anything > > else that will help you to better determine how you will vote. This is > the > > time to raise any issues you wish the future TC to consider, and to > evaluate > > the opinions of the nominees prior to their election. > > > > Candidates, > > Each of you has posted a platform[2], and announced your nomination > to > > the developers. From this point, you are encouraged to ask each other > > questions about the posted platforms, and begin discussion of any points > > that you feel are particularly important during the next cycle. While > you > > are not yet TC members, your voices and opinions about the issues raised > in > > your platforms and questions raised by the wider community will help > ensure > > that the future TC has the widest possible input on the matters of > community > > concern, and the electorate has the best information to determine the > ideal > > TC composition to address these and other issues that may arise. > > > > [1] https://governance.openstack.org/election/ > > [2] > https://opendev.org/openstack/election/src/branch/master/candidates/2026.1/… > > > > > > Ian Y. Choi & Slawek Kaplonski, on behalf of election officials. > >

4 months, 1 week

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

by Goutham Pacha Ravi

Hello Stackers, We're eight weeks away from wrapping up the 2025.2 "Flamingo" release, and three weeks away from its feature freeze (August 28, 2025) [1]. Over the past week, no new governance changes were merged, but some new changes are undergoing community review. The nomination window for Project Team Leads and for four seats on the OpenStack Technical Committee begins on August 6, 2025 [2]. If you have any questions about the process, please post them on this mailing list or hop into #openstack-tc, #openstack-election, or #openstack-dev on OFTC and let's chat. This week, the TC is also looking to refresh the liaisons for projects governed by the "distributed-project-leadership" model—an opportunity for those teams to switch their governance styles, as well. === Weekly Meeting === The TC's weekly meeting focused on two major topics [3]: finalizing the definition of “affiliation” for TC election candidates and the next steps for retiring Monasca. On the affiliation front, we debated whether to reuse the OpenInfra bylaws language or simplify it for our needs. During the meeting, there was a consensus that the definition should focus on contributor intent and a visible employee-employer relationship without getting bogged down in legal technicalities. It's important to share our biases upfront for the sake of transparency and to strive toward the TC's affiliation diversity requirement. We are moving ahead with retiring the Monasca project. After earlier signals of interest in continuing maintenance, the project team now seems comfortable with retirement. The TC consulted this mailing list [4] to seek any further interest in the project. We'll work with the "unmaintained-core" group to clean up deliverables and code branches. We also touched on CI work to test OpenStack with Debian Bookworm and Trixie, which will help us make progress on the Eventlet removal community goal. Finally, a brief discussion ensued on OpenStack for AI, encouraging folks with architectural insight to join the Foundation's AI working group and its mailing list [5]. We wrapped with a shout out to the i18n interns and mentors for their recent progress [6]. The next weekly meeting of the TC is today, August 5, 2025, at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. Please find the meeting's agenda and call details in the wiki [7]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-20: Nominations close for OpenStack elections - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 2025-08-28: Feature Freeze deadline, Milestone-3 of the Flamingo release [1] - 2025-08-29: Colombia OpenInfra User Group Meetup: https://www.meetup.com/colombia-openinfra-user-group/events/307096751/ - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ 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] 2026.1 OpenStack Elections: https://governance.openstack.org/election/ [3] TC Meeting IRC Log 2025-07-29: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.html [4] Call for maintainers for Monasca: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenInfra AI WG List: https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.… [6] i18n Internship with CMU: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, 2025-08-05: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

4 months, 4 weeks

Re: Upstream Oslo IRC Meetings Are Back.

by Herve Beraud

Le mer. 30 oct. 2024 à 13:06, Stephen Finucane <stephenfin(a)redhat.com> a écrit : > On Tue, 2024-10-29 at 15:43 +0900, Takashi Kajinami wrote: > > +1 for using doodle vote to decide the slot. > > > > > > Just dumping my preference here for your refernce but I'll reflect these > > in the vote once it is open. > > > > Regarding the time slot, assuming we have more people from US/EMEA TZ > > attending the meeting, I'm ok with having the meeting late, but I hope > > we can finish it before 16:00 UTC (25:00 JST). > > > > Regarding the day, here in Japan we have more local holidays on Monday > > than the other days of a week, so I hope we can avoid Monday as I > mentioned > > in my reply to the previous thread. I more likely get my own things on > > Friday or Wednesday. So I personally prefer Tuesday and Thursday, and > then > > Wednesday as a fallback. > > Just thinking out loud: is it possible to alternate between (European) > mornings > and afternoons to catch both audiences? I don't think the Doodle captures > this > option. > This is a good idea, I was thinking of maybe doing the same for the IRC meetings related to eventlet-removal. It would leave a chance for everybody to attend. The eventlet meetings are a bit different because they are bimonthly meetings so we could easily shift the time slot between the first and the second meeting. But as Daniel pushed to run it each week, IMO, it would be more complexe to apply it to oslo meetings. I'm far from a doodle expert, but from what I observed, doodle want specific dates so... maybe the trick is to propose 2 time slots on fake dates that more represent days of the week (monday, tuesday, wed...) than real dates, and then to select the both opposite time slots that best cover our extended time zone needs. > Stephen > > > > > On 10/29/24 1:59 AM, Herve Beraud wrote: > > > I don't think we can answer that question here. I'd encourage you to > propose time slots and day and then to run a doodle vote on them. > > > > > > Le lun. 28 oct. 2024 à 17:22, Daniel Bengtsson <dbengt(a)redhat.com > <mailto:dbengt@redhat.com>> a écrit : > > > > > > > > > > > > On 2024-10-28 15:55, Herve Beraud wrote: > > > > If we decide to change the hour, then, the meeting page should > > > > be updated (https://meetings.opendev.org/#Oslo_Team_Meeting < > https://meetings.opendev.org/#Oslo_Team_Meeting> <https:// > > > > meetings.opendev.org/#Oslo_Team_Meeting < > http://meetings.opendev.org/#Oslo_Team_Meeting>>). > > > Yes I will updated but what is the best time and day for everyone? > > > > > > -- > > > Daniel Bengtsson > > > Software engineer > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ <https://github.com/4383/> > > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year, 2 months

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

by Goutham Pacha Ravi

Hello Stackers, This week, the OpenStack community is convening virtually to set the agenda for the 2025.1 "Epoxy" release and beyond [1][2]. As of today, there are 33 different discussion tracks spread over five days. Now's as good a time as ever to review the Community Code of Conduct as we step into this event [3]. In the past week, the North American section of the OpenInfra community gathered in Indianapolis (and virtually) for a two-day conference. I had the privilege to attend in person and chat with numerous users, operators, and contributors. The community is as energetic as ever, as evidenced by the participation we saw in the leadership meet-and-greet event [4]. Amy Marrich (spotz) organized this event, and we had representation from the OpenInfra Board, Zuul, OpenStack TC, SIGs, and PTLs. The audience learned the essence of our "Open Community," how elections are conducted, what different community leadership roles are, and how one can participate in OpenInfra governance. We brainstormed how to revive projects with dwindling contributors and recapped takeaways from the "Bridging the Gap" and Security SIG-related discussions. Prof. Corey Leong (profcorey) from Valencia College volunteered to propose a "Higher Education" Special Interest Group focused on increasing awareness and creating learning material for university students interested in joining the OpenStack community. I'll share a link with video recordings of this conference in a future post. === Weekly Meeting === Dmitriy Rabotyagov (noonedeadpunk) chaired the weekly IRC meeting [5] of the OpenStack Technical Committee last week. We had fewer attendees than usual, but it was a productive discussion nevertheless. We prepped the TC's PTG etherpad [6] with topics and timings for the discussion. As is tradition, please allow flexibility in terms of the discussion schedule. Discussions may start a bit later (or earlier) than planned, and we'll have to be dynamic to accommodate scheduling conflicts, as many contributors are involved across multiple topics. In lieu of the PTG, the weekly IRC meeting scheduled for 2024-10-22 has been canceled [7]. We briefly discussed the leadership appointment patches concerning the Watcher and Mistral project teams. These are still being reviewed, and we'll try to get them closed out after the PTG week. We also discussed grenade job changes that Ghanshyam Mann (gmann) and other community members have been pursuing [8]. Concerns were raised about projects (like Kolla and Loci) publishing container images under the OpenStack name without a clear security policy. The need to clarify OpenStack's support and security posture on such deliverables was discussed. We have more to discuss on this topic at the PTG and beyond. The next weekly IRC meeting for the OpenStack Technical Committee is on 2024-10-29. The agenda is up early [9], but I'll write to you once again before it is formalized. I look forward to seeing you all at the PTG and possibly seeding more topics for this weekly meeting afterward. === Governance Proposals === ==== Open for Review ==== Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 Appoint Ke Chen as PTL for Watcher | https://review.opendev.org/c/openstack/governance/+/932419 Adding Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 Propose a pop-up team for eventlet-removal | https://review.opendev.org/c/openstack/governance/+/931978 Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/931254 === Upcoming Events === 2024-10-21 to 2024-10-25: OpenInfra Project Teams Gathering: https://openinfra.dev/ptg/ 2024-10-27: All Things Open: https://allthingsopen.org/ 2024-11-04: OpenInfra Board Meeting: https://board.openinfra.dev/ 2024-11-15: KubeCon + CloudNativeCon: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] "Epoxy" PTG Schedule: https://ptg.opendev.org/ptg.html [3] OpenInfra Community Code of Conduct: https://openinfra.dev/legal/code-of-conduct [4] OpenInfra Leadership Meet-and-Greet: https://etherpad.opendev.org/p/leadership-na [5] TC Meeting IRC Log, 2024-10-15: https://meetings.opendev.org/meetings/tc/2024/tc.2024-10-15-18.00.log.html [6] TC PTG Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [7] TC IRC meeting 2024-10-22 is canceled: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] Grenade Job changes: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [9] TC Meeting Agenda, 2024-10-29: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 year, 2 months

Re: Upstream Oslo IRC Meetings Are Back.

by Ghanshyam Mann

---- On Wed, 30 Oct 2024 08:06:11 -0700 Herve Beraud wrote --- > > > Le mer. 30 oct. 2024 à 13:06, Stephen Finucane stephenfin(a)redhat.com> a écrit : > On Tue, 2024-10-29 at 15:43 +0900, Takashi Kajinami wrote: > > +1 for using doodle vote to decide the slot. > > > > > > Just dumping my preference here for your refernce but I'll reflect these > > in the vote once it is open. > > > > Regarding the time slot, assuming we have more people from US/EMEA TZ > > attending the meeting, I'm ok with having the meeting late, but I hope > > we can finish it before 16:00 UTC (25:00 JST). > > > > Regarding the day, here in Japan we have more local holidays on Monday > > than the other days of a week, so I hope we can avoid Monday as I mentioned > > in my reply to the previous thread. I more likely get my own things on > > Friday or Wednesday. So I personally prefer Tuesday and Thursday, and then > > Wednesday as a fallback. > > Just thinking out loud: is it possible to alternate between (European) mornings > and afternoons to catch both audiences? I don't think the Doodle captures this > option. > > This is a good idea, I was thinking of maybe doing the same for the IRC meetings related to eventlet-removal. It would leave a chance for everybody to attend.The eventlet meetings are a bit different because they are bimonthly meetings so we could easily shift the time slot between the first and the second meeting.But as Daniel pushed to run it each week, IMO, it would be more complexe to apply it to oslo meetings. > I'm far from a doodle expert, but from what I observed, doodle want specific dates so... maybe the trick is to propose 2 time slots on fake dates that more represent days of the week (monday, tuesday, wed...) than real dates, and then to select the both opposite time slots that best cover our extended time zone needs. ++ on alternate TZ meetings, and that way, EU and Asia TZ can be covered in one of the meetings. To keep it simple, we can have separate doodle poll for each TZ meeting. -gmann > > > Stephen > > > > > On 10/29/24 1:59 AM, Herve Beraud wrote: > > > I don't think we can answer that question here. I'd encourage you to propose time slots and day and then to run a doodle vote on them. > > > > > > Le lun. 28 oct. 2024 à 17:22, Daniel Bengtsson dbengt(a)redhat.com dbengt(a)redhat.com>> a écrit : > > > > > > > > > > > > On 2024-10-28 15:55, Herve Beraud wrote: > > > > If we decide to change the hour, then, the meeting page should > > > > be updated (https://meetings.opendev.org/#Oslo_Team_Meeting https://meetings.opendev.org/#Oslo_Team_Meeting> <https:// > > > > meetings.opendev.org/#Oslo_Team_Meeting http://meetings.opendev.org/#Oslo_Team_Meeting>>). > > > Yes I will updated but what is the best time and day for everyone? > > > > > > -- > > > Daniel Bengtsson > > > Software engineer > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ https://github.com/4383/> > > > > > > > > > -- > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/ > >

1 year, 2 months

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