18:00:09 <gouthamr> #startmeeting tc 18:00:09 <opendevmeet> Meeting started Tue May 14 18:00:09 2024 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:09 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:09 <opendevmeet> The meeting name has been set to 'tc' 18:00:22 <noonedeadpunk> o/ 18:00:23 <gouthamr> Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. 18:00:26 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. 18:00:30 <gouthamr> #topic Roll Call 18:00:33 <gmann> o/ 18:00:36 <dansmith> o/ 18:00:38 <spotz[m]> o/ 18:00:38 <frickler> \o 18:00:43 <JayF> o/ 18:01:20 <gouthamr> absent today: slaweq gtema 18:01:46 <gouthamr> #chair frickler 18:01:46 <opendevmeet> Current chairs: frickler gouthamr 18:02:09 <opendevreview> Ghanshyam proposed openstack/project-team-guide master: Update retired project stable branch handling https://review.opendev.org/c/openstack/project-team-guide/+/919608 18:02:21 <gouthamr> we have quorum; so lets begin 18:02:29 <gouthamr> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee (Agenda) 18:03:01 <gouthamr> ^ light agenda today, so lets use the meeting to discuss ongoing items; but please hold for "Open Discussion" 18:03:10 <gouthamr> #topic AIs from previous week 18:03:24 <gouthamr> PyPi maintainers cleanup lists (gouthamr) 18:03:24 <gouthamr> Progress on eventlet removal (JayF) 18:03:24 <gouthamr> OSCaaS/speeding up DevStack (dansmith) 18:03:24 <gouthamr> Marking inactive projects prominently (gtema) 18:03:36 <gouthamr> i think there's been some updates regarding these.. 18:04:02 <JayF> I put a comment on the change, chatted with hberaud about the status of things, and emailed the list this morning with a call to action for projects to start eventlet removal work 18:04:11 <gouthamr> ty JayF 18:04:18 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/4KOGIDNM2SWJDBBFCTCJC3ZSITLMVMDL/ ([all][tc] Eventlet migration: Call to action) 18:04:43 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/902585 (Migrate eventlet usages to asyncio) 18:06:11 <gouthamr> lets see that discussion evolve on the ML.. 18:06:28 <gouthamr> on point (2): "We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model." 18:06:43 <gouthamr> do you mean to pursue https://review.opendev.org/c/openstack/governance/+/916546 as a resolution? 18:07:15 <JayF> It's my understanding that nobody, at this point, has expressed any desire to make oslo libraries dependant on a single threading model, and there are very few examples of cases that may need update. That means, to me, no action is the correct action. 18:07:36 <noonedeadpunk> frankly speaking, for me personally it would be /o\ to try to assess all possible frameworks that will come to the picture with threading 18:08:22 <noonedeadpunk> and if I'd be trying to start contributing - I would just give up instantly 18:08:46 <dansmith> noonedeadpunk: I'm not sure I understand what you're saying 18:08:58 <dansmith> I think the ask is that they *not* depend on any specific framework or strategy, 18:09:06 <dansmith> and AFAIK, that's mostly a no-op from where they are today 18:09:14 <spotz[m]> So seems do nothing right now makes sense 18:09:51 <noonedeadpunk> dansmith: yeah, and then from someone from outside of the project it may make unbearable to do anything in this project 18:10:10 <dansmith> noonedeadpunk: in what way? 18:10:32 <dansmith> I mean, given they're already there by all reports, that would imply the last 12+ years has been unbearable? 18:11:38 <JayF> Today, it's safe to assume on any OpenStack project it's using eventlet as the primary concurrency/event model. If we end up having multiple projects choose different models -- or even as some suggest, using different models in different parts of a single project, it'll be more complexity for contributors to interact with. 18:11:54 <noonedeadpunk> probably I'm thinking about smth different 18:11:55 <JayF> I'm not looking forward to that complexity at all, and it's a primary reason I'm disappointed we were unable to find a path everyone was happy with. 18:12:09 <noonedeadpunk> but I was more about with what to replace eventlet 18:12:36 <dansmith> we're talking about libraries here, not the service projects right? 18:12:54 <dansmith> "shared tooling such as oslo libraries" is what gouthamr was asking for confirmation on right? 18:12:56 <noonedeadpunk> as doing asyncio vs fastapi vs gevent - are all quite different 18:13:03 <noonedeadpunk> ah, ok 18:13:12 <noonedeadpunk> yeah, then different things, sorry 18:13:12 <gouthamr> yes; specifically wrt shared libraries :) 18:13:35 <dansmith> we already have service projects using things other than eventlet, and even multiples within the same project, FWIW 18:13:58 <noonedeadpunk> (and that is not good idea imo) 18:14:22 <spotz[m]> Are any a good replacement to champions? 18:14:32 <noonedeadpunk> (probably nobody in power in dictate, but I'd love tc to come with "recommendation" at very least) 18:14:40 <dansmith> noonedeadpunk: it's just not that simple 18:14:54 <JayF> spotz[m]: hberaud and I both attempted to champion asyncio; we got minimal support from other TC members on the proposed spec. 18:14:59 <dansmith> the needs of nova-compute are quite different from nova-api, and very different from glance 18:15:14 <dansmith> JayF: and from other community members, IMHO 18:15:18 <dansmith> not just TC 18:16:06 <JayF> dansmith: strangely enough, I consider your comments a form of support: you gave feedback on why you thought it was a bad idea 18:16:26 <JayF> dansmith: the silence/lack of participation in some cases is more difficult to deal with; you can't argue with or understand something from a ghost 18:17:15 <fungi> it's a common misconception that projects solved their problems in different ways because of a lack of cohesive leadership 18:17:26 <fungi> sometimes different problems are better solved in different ways 18:17:32 <dansmith> um, not sure what we're talking about here.. my point was that there were lots of non-TC voices on that review expressing lots of different opinions than just "replace eventlet with X" 18:17:39 <dansmith> JayF: ^ 18:17:56 <JayF> dansmith: I'm trying to say, s/support/engagement/ might have been the better way to word my statement at 11:14 18:18:33 <dansmith> JayF: ah, then in that case I agree, since most of the voices weren't from the TC 18:18:42 <gouthamr> we're re-iterating stuff here, which is good, but, lets do it on the ML if this sentiment is shared by the wider community.. 18:18:49 <dansmith> that said, I think the projects are really the important voices and not necessarily TC people because they're in the position to make a decree 18:19:23 <spotz[m]> There may not be one good solution any more but maybe the TC can come up with a list of recommendations 18:19:23 <gouthamr> ++ 18:19:34 <TheJulia> spotz[m]: ++ 18:21:40 <noonedeadpunk> yes, exactly. list of recommendations is I believe what might be expected 18:22:52 <TheJulia> An ideal warning at the bottom: you get to maintain eventlet if you don't choose one of the ones above. 18:23:20 <dansmith> I really don't even want us making a list of allowed ones, personally 18:23:35 <dansmith> until and unless someone appears to choose something completely off the wall, which feels unlikely 18:24:11 <JayF> I think such a list would be useful, whether in governance, docs, or non-openstack context. I'd be happy to review such a change wherever it was placed; but I'm putting future eventlet migration efforts towards coding -- first up is IPA eventlet removal. 18:24:23 <dansmith> so if you change that to s/ones above/something else/ then I'm in :) 18:24:51 <dansmith> suggestions are certainly a good idea 18:25:58 <dansmith> gouthamr: did you want to discuss other AIs? 18:26:00 <gouthamr> yes 18:26:05 <dansmith> I cleaned up OCaaS and it should be mergeable now 18:26:08 <gouthamr> ideally this list will get built over time 18:26:12 <dansmith> had to fix a couple devstack, ironic, and nova things 18:26:36 <gouthamr> #link https://review.opendev.org/c/openstack/devstack/+/676016 (Use OSCaaS to speed up devstack runs) 18:27:57 <gouthamr> in https://review.opendev.org/c/openstack/devstack/+/918681/6/.zuul.yaml you're enabling this on a "base" job; so we'd not merge this, correct? 18:28:12 <dansmith> yep, hence the DNM :) 18:28:25 <dansmith> just to show that it's working 18:28:39 <dansmith> I honestly think turning this on for more people is a good idea, bt I 18:28:52 <dansmith> but I'd at least like to be *able* to turn it on in some nova jobs :) 18:28:54 <gouthamr> ack; looks good to me, thank you for pursuing this.. we might find stray issues and have to fix them when doing this with other jobs 18:29:15 <dansmith> it's possible but in my few years of using it I've never found such a scenario :) 18:29:40 <dansmith> won't know unless we try though 18:30:01 <gouthamr> haha @ few years 18:30:11 <fungi> it's been suggested many times over the years, and in the past the main pushback from reviewers was "this doesn't reflect how people interact with devstack clouds in the real world" (which frankly could be true of a lot of other pragmatic choices devstack already makes) 18:30:29 <fungi> s/devstack clouds/openstack clouds/ i mean 18:30:42 <dansmith> I don't think that argument applies as much to the OCaaS one 18:30:46 <dansmith> it does to clarkb's approach I think 18:31:18 <dansmith> this is literally running osc in shell mode, which is fully supported in the regular usage of it and is really the only way an admin can do stuff quicker than one operation per 5s 18:31:42 <fungi> ah, yes there is a bit of a difference in approach 18:32:11 <fungi> and still has the desired effect of not incurring startup overhead over and over 18:32:28 <dansmith> yup 18:32:39 <dansmith> gouthamr: we're 30m into the call and feels like we're still stuck on the first agenda item, no? :) 18:32:42 <gouthamr> lets get this reviewed, and i'll call it out in our weekly summary so others can try adding jobs with this; there'll be good coverage with and without anyway.. but, it might save a few jobs hitting timeouts, and satisfy local devstack users that can't wait 40 mins 18:32:48 <noonedeadpunk> I kinda wonder, if it won't be easier to handle osc overhead jsut by enabling caching to memcached? 18:33:02 <dansmith> noonedeadpunk: it's not just the caching 18:33:04 <gouthamr> dansmith: there aren't many items today, so speak away :) 18:33:15 <fungi> entrypoint discovery is painful 18:33:17 <dansmith> it's the masssssive startup cost of importing all the python 18:33:19 * noonedeadpunk haven't read patch fully 18:33:26 <noonedeadpunk> ah 18:33:40 <fungi> and i/o-bound 18:33:59 <dansmith> noonedeadpunk: run "openstack shell" and see how long it takes to just get to a shell prompt.. it's *that* which we save over a thousand such invocations :) 18:34:17 * noonedeadpunk have to live with ansible, where nobody counts startup costs it seems... 18:34:23 <dansmith> gouthamr: okay, well, then maybe I'll duck out.. today is nova spec review day and I'm woefully behind 18:34:38 <gouthamr> on the PyPi maintainers cleanup - like clarkb mentioned, there doesn't seem to be a way to distinguish Owners vs Maintainers from the warehouse API that's publicly available. which is a PITA... I was going to poke clarkb/fungi for some help and post an update to openstack-discuss 18:35:28 <fungi> yeah, i'm back from vacation if you know what you need 18:35:38 <gouthamr> fungi++ ty 18:35:38 <gmann> try login with openstackci and see if it give the list of packages it own 18:35:43 <gouthamr> ^ that 18:35:50 <gouthamr> is what i needed help with 18:36:12 <gouthamr> lets chat about this off-meeting though 18:37:05 <fungi> yep 18:37:05 <gouthamr> we'll skip the 2024.2 TC Tracker this week because we're doing quite well on the items; thank you all for participating in the reviews and keeping your patches updated. It'll be back next week.. 18:37:18 <gouthamr> #topic Open Discussion 18:38:10 <spotz[m]> I'd still like to see the AC charter change go through but it seems stalled 18:38:12 <gouthamr> a reminder to folks that you can edit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee and propose topics, and state your absence anytime before the meeting starts :) 18:38:45 <gouthamr> (sees JayF's update; hope you have a good time off) 18:38:52 <noonedeadpunk> fwiw, opening openstack shell takes 0.3s for me... 18:39:04 <JayF> I'll be not off, but in Europe -- including presenting at the OIF Days + BM SIG at CERN :D 18:39:06 <gmann> one thing for inactive projects, I have started the retirement for 5 inactive/leaderless projects. To move next on retirement process, I need two TC members review/merge these repo content https://review.opendev.org/q/remove+repo+content+owner:gmann@ghanshyammann.com+status:open 18:39:32 <gmann> and the governance changes to retire those projects are also up for review 18:39:35 <spotz[m]> Oh I'll be off and traveling too OI Day at CERN too:) 18:39:35 <noonedeadpunk> JayF: oh, where you'll be on OIF Days? 18:40:18 <JayF> noonedeadpunk: OIF Days CERN in early June. I'll be UK the week before, Paris Mon/Tues, then on to Geneva for the events. There is a BM SIG the day before as well, I think we have slots left if you wanna join there too. 18:41:02 <gouthamr> spotz[m]: on the AC change; i'm trying to make the TC and SIG repos visible directly on our docs: https://review.opendev.org/c/openstack/governance/+/918488 - this would vastly signify your proposal because you can just link to it 18:41:07 <spotz[m]> join us noonedeadpunk ! 18:41:34 <noonedeadpunk> I'm going to Paris and was in Sweden... And I have /o\ of internal stuff in early June 18:41:35 <gouthamr> frickler suggested that I move it to a different place than the "OpenStack Project Teams" page that i've currently hijacked. I can do this :) 18:41:45 <spotz[m]> Thanks gouthamr 18:42:06 <JayF> noonedeadpunk: if you wanna sync up that Mon/Tues while I'm in paris, let me know -- I've got zero plans for those days as of now. 18:42:08 <noonedeadpunk> gmann: Im looking at patches for retireement, and I don't see a README left? 18:42:12 <gouthamr> spotz[m] frickler: ty i'll update 18:42:26 <JayF> noonedeadpunk: gmann: https://review.opendev.org/c/openstack/ec2api-tempest-plugin/+/919399/1/README.rst lgtm? 18:42:27 <fungi> keep in mind that retired repositories/projects where contributions landed before they ceased to be official are also treated as qualifying for ac status 18:42:46 <gmann> noonedeadpunk: it should be there in every repo, please comment if i missed any 18:42:50 <fungi> so just looking at "current" published official repositories isn't the whole picture, necessarily 18:43:42 <fungi> this is why we move them from the projects.yaml file to legacy.yaml 18:43:55 <fungi> so that the election tooling can continue to find them 18:44:02 <noonedeadpunk> ok, I see why - project never had one 18:44:46 <gouthamr> fungi: thanks; important call out.. this point's there in our retirement guide 18:44:49 <gmann> k, I added in those cases also 18:44:49 <gouthamr> #link https://docs.openstack.org/project-team-guide/repository.html#step-3-retire-repository-from-the-governance-repository ^ 18:45:24 <gouthamr> do we have any advice to share on a non-Openstack project's retirement/removal? 18:45:34 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/R42DO7M4BECGRLBTBXYRNRSF7JQGK5GB/ ([neutron][releases][tc] Retiring tap-as-a-service-tempest-plugin and old stable branches of tap-as-a-service) 18:45:52 <gmann> if anyone contributed in the new retired project during election electorate timeframe then yes they are considered as AC 18:45:54 <frickler> gouthamr: so you'll want to add a 4th table to your page with legacy repos I guess 18:46:27 <gmann> gouthamr: I do not think TC need to recommend on non openstack one, maybe opedev process can be followed directly 18:46:53 <gouthamr> frickler: true; and i can parse the retirement date 18:46:55 <fungi> an up side to this approach is that you'll finally have validation of the formatting of those files, and avoid last minute scrambles we've had in the past with people making untested edits to them which later break the election tools 18:47:07 <gmann> frickler: gouthamr: humm, maybe but we do not need to publish retired project, having those data in repo is enough it hink 18:47:36 <gouthamr> gmann: or probably show only those currently eligible for AC 18:48:12 <gouthamr> it'd be easy to do automatically; as long as the documentation stays updated :D 18:48:36 <gmann> gouthamr: eligibility for AC can be determined by scripts we have not via what we published right. i mean for retiring project, we used to have those project in project data before they went to retirement and any contribution to that will be counted by the script 18:49:34 <gouthamr> gmann: ack; but what the script does isn't shared publicly, no? 18:49:35 <gmann> I am not strongly against of publish all retired project but that is not exactly what AC means will be, it will be calculated by the timeframe also 18:49:49 <frickler> imo this is not about election tooling, but about documentation 18:49:58 <gmann> gouthamr: it is shared via the charter or at least with modification spotz[m] is doing 18:50:41 <gmann> our charter should cover that what all we consider in AC irrespective of our doc structure 18:51:19 <JayF> gmann: ++ 18:51:53 <gouthamr> for sure - agree as far as framing the charter goes; but, having things visible will make things easier to grok for the reader.. 18:52:30 <fungi> if "eligibility for AC can be determined by scripts we have" is a reference to https://opendev.org/openstack/election then that is published yes 18:52:37 <gmann> sure, you can publish retired proejct data but it will be lot extra work to shape it in same way as projects data are 18:53:01 <spotz[m]> After the charter change we still need to update the scriipts 18:53:06 <gmann> yes 18:53:40 <fungi> also if you change the schema/data model within any of those yaml files, the election tools will need updating because they parse them 18:54:02 <gmann> charter change is imp here and we should make that depends on our doc structure or script change etc. let's do charter change first and then implemention 18:54:24 <gmann> frickler: yeah, good point. and not just election but release tooling also 18:54:39 <gmann> release tools also fetch data as per schema 18:55:27 <gmann> fungi: ^^ i mean. wrongly tagged frickler 18:55:44 <frickler> another short notice before we finish: sqla2.0 is now in u-c, big thanks to stephenfin for having made this possible with years of work 18:55:51 <gouthamr> ++ 18:55:51 <fungi> at one time we talked about adding a python-based parser in openstack/governance which election and release tools could use to avoid code duplication, but i don't think that every came to pass (dhellmann started writing one at one point) 18:56:02 <spotz[m]> ++ 18:56:03 <gouthamr> #link https://wiki.openstack.org/wiki/Successes 18:56:35 <gouthamr> #link https://review.opendev.org/c/openstack/requirements/+/879743 (Update SQLAlchemy and alembic, drop sqlalchemy-migrate) 18:56:52 * fungi is thrilled to see that folks are still using the success and thanks features 18:57:08 * gouthamr loves it too 18:59:46 <gouthamr> alright; our time's up.. thank you all for attending and for the discussion.. see you at this meeting next week 19:00:05 <gouthamr> #endmeeting