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