| *** bauzas_ is now known as bauzas | 00:26 | |
| *** bauzas_ is now known as bauzas | 02:27 | |
| *** bauzas_ is now known as bauzas | 12:23 | |
| opendevreview | Hervé Beraud proposed openstack/governance master: Remove Eventlet From Openstack https://review.opendev.org/c/openstack/governance/+/902585 | 12:25 |
|---|---|---|
| opendevreview | Jens Harbott proposed openstack/governance-sigs master: Add PyYAML to doc/requirements.txt https://review.opendev.org/c/openstack/governance-sigs/+/922205 | 12:36 |
| *** bauzas_ is now known as bauzas | 12:40 | |
| *** bauzas_ is now known as bauzas | 13:53 | |
| opendevreview | Hervé Beraud proposed openstack/governance master: Remove Eventlet From Openstack https://review.opendev.org/c/openstack/governance/+/902585 | 14:05 |
| *** bauzas_ is now known as bauzas | 14:43 | |
| JayF | I know getting there has been a giant pain, but looking at the releases page (screenshot linked) and seeing things that aren't maintained actually say they aren't is really quite nice. https://usercontent.irccloud-cdn.com/file/TedvLDpP/image.png | 15:38 |
| JayF | Sometimes easy to get wrapped up in implementing these things so we miss that we actually achieved the desired goal -- nobody can go to that page and thing zed-or-older is actually a good thing to install. | 15:38 |
| JayF | *think | 15:38 |
| gouthamr | ++ indeed :) | 15:44 |
| frickler | is "continual updates" actually a valid phrase? or should this rather be "continous updates"? | 17:10 |
| gouthamr | "continous updates" | 17:11 |
| frickler | hmm, after ddging some dictionaries, the term seems to be fine, though maybe uncommon for non-native speakers | 17:12 |
| gouthamr | yeah; i'm a non-native speaker too. i'll file this under "English is weird" | 17:13 |
| JayF | I think they are slightly different tenses | 17:18 |
| JayF | well, at least ... I read a little bit of connotation in it | 17:18 |
| JayF | continual would be more "update as needed" continuous would be more "constantly updating" | 17:19 |
| JayF | but both are fine for the context I think | 17:19 |
| frickler | yes, continual is not uninterrupted, but repeated (more or less) regularly | 17:19 |
| frickler | which matches the release calendar quite well | 17:19 |
| fungi | though also, just picking different words entirely is sometimes the easier path to clarity | 17:50 |
| fungi | especially when writing english for an international audience | 17:51 |
| gouthamr | ++ | 17:51 |
| gouthamr | tc-members: irc meeting here in ~9 mins | 17:51 |
| gouthamr | #startmeeting tc | 18:00 |
| opendevmeet | Meeting started Tue Jun 18 18:00:37 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
| opendevmeet | The meeting name has been set to 'tc' | 18:00 |
| 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 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. | 18:01 |
| gouthamr | #topic Roll Call | 18:01 |
| gmann | o/ | 18:01 |
| gtema | o/ | 18:01 |
| slaweq | o/ | 18:01 |
| dansmith | o/ | 18:01 |
| noonedeadpunk | o/ | 18:01 |
| JayF | o/ | 18:02 |
| frickler | \o | 18:02 |
| gouthamr | #chair frickler | 18:02 |
| opendevmeet | Current chairs: frickler gouthamr | 18:02 |
| gouthamr | courtesy ping: spotz | 18:03 |
| gouthamr | we have the requisite quorum; lets get started.. | 18:04 |
| gouthamr | #topic AIs from last week | 18:04 |
| gouthamr | frickler: any further update on the PyPi cleanup from you? | 18:05 |
| frickler | no, didn't get to check further stuff yet | 18:06 |
| * gouthamr just noticed the question you left for me on the etherpad | 18:06 | |
| gouthamr | frickler: ack; ty.. np. the next steps here were to go through the lists again with a fine toothed comb to see any packages we've missed; and address the ones we need openstackci to be owner on | 18:07 |
| gouthamr | i didn't get a chance to do any of this in teh past week; it's been a frenzy downstream.. but i'll commit some time this week | 18:08 |
| frickler | there's also the open question of whether to add a second account for redundancy | 18:08 |
| frickler | maybe this can be deferred until using an organization account is possible | 18:08 |
| gouthamr | ah yes; i think we were in agreement here.. is this something the TaCT SIG can do for us? | 18:08 |
| gouthamr | oh; #TIL | 18:09 |
| gouthamr | #link https://docs.pypi.org/organization-accounts/ (PyPI Organization Accounts) | 18:09 |
| noonedeadpunk | they're there still though? | 18:09 |
| noonedeadpunk | *not there | 18:09 |
| frickler | that feature is in beta testing for two years now iiuc, seems the foundation is searching for someone to work on the implementation | 18:09 |
| noonedeadpunk | but that would makes sooo much sense | 18:10 |
| frickler | adding another account now would have to be done manually again for all repos, so I wouldn't mind if we could wait with that maybe another year or so | 18:11 |
| frickler | of course there might be some larger issue if we ever got locked out of the current account, so this is not completely without risk | 18:11 |
| gouthamr | :( yes; and the wait for this feature doesn't look definitive | 18:12 |
| gouthamr | i am in favor of adding a second maintainer account and then transitioning these accounts to organization accounts if necessary; maybe when this does happen, there'll be a sane warehouse API too | 18:13 |
| JayF | Honestly, I would not count on those things happening at all unless someone here is going to volunteer to do them. As mentioned by frickler, pypi-related features are promised more frequently than delivered in general. | 18:14 |
| JayF | So I would advise us to decide based on what exists today, and not wait for something that may not come. | 18:14 |
| noonedeadpunk | ++ | 18:14 |
| frickler | fungi: ^^ any opinion from you as tact head? ;) | 18:15 |
| fungi | i'd be inclined to wait, but willing to go along with the tc's preference | 18:16 |
| fungi | working upstream with the warehouse maintainers to solve the missing collaborator api would be another option | 18:16 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance-sigs master: Link SIG repos from index https://review.opendev.org/c/openstack/governance-sigs/+/922162 | 18:16 |
| * JayF is OK with going along with fungi's suggestion | 18:17 | |
| fungi | if warehouse grew an api for those tasks, we could script something akin to the accessbot we use for managing irc channel access lists | 18:17 |
| gouthamr | that'd ease a world of pain | 18:17 |
| fungi | because keep in mind that this isn't a one-time task | 18:18 |
| fungi | the second collaborator would need to be manually added every time we publish the initial release of any new deliverable in the future too | 18:18 |
| fungi | and remember that pypi projects aren't created ahead of time any more, now they're auto-created by the first uploaded release | 18:19 |
| fungi | so just adding it to the project creation steps isn't going to work | 18:19 |
| gmann | I think we should leave it to tact SIG as it is handled there and the way they would like to proceed. if any decision/policy is needed from TC we can check/help. | 18:20 |
| frickler | fungi: do you have any contact to warehouse maintainers where more details could be discussed? | 18:20 |
| frickler | but yeah, we can discuss that off-meeting | 18:20 |
| fungi | frickler: the issue that's filed in github is my contact | 18:20 |
| opendevreview | Merged openstack/governance-sigs master: Add PyYAML to doc/requirements.txt https://review.opendev.org/c/openstack/governance-sigs/+/922205 | 18:20 |
| fungi | i mean, i do know some of the maintainers, but they prefer such things to go through issues and pull requests anyway | 18:21 |
| frickler | that's not too much of a contact in my world, but ok | 18:21 |
| gouthamr | #link https://github.com/pypi/warehouse/issues/13409 ([META] Determine API design for performing maintainer actions) | 18:21 |
| frickler | I'll read up on that tomorrow, thx | 18:21 |
| gouthamr | okay - good discussion | 18:22 |
| gmann | one suggestion: it seems we are spending much time in every meeting on this, can we discuss/let tact SIG handle it and we can join discussion in #openstack-infra channel? | 18:22 |
| spotz[m] | o/ sorry had the meeting time as laterduetotime zone | 18:22 |
| gouthamr | #agreed we'll not implement the second maintainer on PyPi; we'll instead wait on organizational accounts or a warehouse API | 18:23 |
| JayF | gmann: I like that we handle it in meetings, supply chain security for us is a top line topic for technical governance in a project like ours, IMO. | 18:23 |
| gouthamr | the other AIs from last week pertain to zuul config errors | 18:24 |
| gmann | JayF: but tact SIG is handling it carefully on behalf of TC, I do not see any issue in that | 18:24 |
| gouthamr | lets switch to the gate health topic so we can review those | 18:25 |
| gouthamr | #topic Gate Health | 18:25 |
| gouthamr | i sent this link with our weekly summary: | 18:25 |
| dansmith | I haven't had a lot of time this last week, but a bunch of nova patches have been on permafail status | 18:25 |
| gouthamr | #link https://zuul.opendev.org/t/openstack/config-errors (Zuul config errors) | 18:26 |
| * gouthamr sorry; interrupted dan there | 18:26 | |
| gmann | from tempest jobs I have observed last week, i did not see any frequent failure | 18:26 |
| frickler | also config errors is a different topic than gate health? | 18:26 |
| gmann | there were some timeout in integrated compute job and suspect was http_client timeout increase | 18:27 |
| dansmith | gmann: up to 12 rechecks: https://review.opendev.org/c/openstack/nova/+/912094/3?tab=change-view-tab-header-zuul-results-summary | 18:27 |
| gouthamr | i think neutron-dynamic-routing and neutron-fwaas (perhaps others) started having issues with some recent wsgi refactoring in neutron | 18:27 |
| JayF | Ironic had an issue related to pysnmp getting bumped in requirements (at our request), we missed that virtualbmc needed migration as well. | 18:27 |
| gmann | but we will be observing that in this or coming week | 18:27 |
| gmann | gouthamr: that is fixed right? | 18:27 |
| frickler | vpnaas, yes, that should be fixed in neutron soon, however | 18:27 |
| gouthamr | gmann: is it? we skipped installing neutron-dynamic-routing in manila jobs as a workaround | 18:28 |
| frickler | #link https://review.opendev.org/c/openstack/neutron/+/922185 | 18:28 |
| slaweq | gouthamr: yes, there is/was some issue with those but I haven't had a lot of time this week and I don't know details | 18:28 |
| gmann | gouthamr: ohk, it is not merged yet. | 18:28 |
| gouthamr | ah tyty (cc: carloss ^) | 18:28 |
| frickler | approved, but not merged yet, and then needs a new neutron release | 18:28 |
| frickler | for the ironic issue the reqs bump has been reverted | 18:29 |
| frickler | #link https://review.opendev.org/c/openstack/requirements/+/922186 | 18:29 |
| gouthamr | +1 | 18:30 |
| JayF | Thanks for that, I'm going to be working the virtualbmc issue so we can get it rolled forward again. pysnmp did an asyncore->asyncio migration which is causing pain with how it's structured | 18:30 |
| fungi | projects are installing neutron releases in integration tests? | 18:30 |
| gtema | the neutron one got w+1 some minutes ago | 18:30 |
| JayF | s/virtualbmc/virtualpdu/ | 18:30 |
| fungi | thought they all installed neutron branch tips, so just merging should be enough? | 18:30 |
| gmann | I think it is from master with required-project so release might not be needed | 18:31 |
| gouthamr | (^ that's true of manila jobs.. they use neutron-dynamic-routing from git) | 18:31 |
| gtema | fungi - issue is when neutron is coming from tips and vpnaas not tips | 18:31 |
| gtema | but tomorrow it should be all fine | 18:31 |
| fungi | right, that's what i thought. okay thanks | 18:31 |
| gouthamr | we might have to log some bugs for integrated jobs that timeout sporadically | 18:32 |
| frickler | there was a suspicion that that might be related to specific providers, but sean mooney made some statistics which looked indifferent to me | 18:33 |
| gouthamr | or is there a hunch that these have a pattern? i.e., when using this feature on slow test nodes on xyzzy provider, things timeout | 18:33 |
| frickler | though that was only for the devstack part so far | 18:33 |
| frickler | see the log of the -qa channel for more details (last 3 days or so) | 18:35 |
| gouthamr | ack ty frickler | 18:35 |
| gouthamr | "devstack-plugin-ceph-tempest-py3" is a base job for integrated jobs elsewhere and it timed out 25% of the time: https://zuul.opendev.org/t/openstack/builds?job_name=devstack-plugin-ceph-tempest-py3&project=openstack/devstack-plugin-ceph | 18:36 |
| gmann | I think this job is still not so stable and many place we have it non voting | 18:37 |
| frickler | a lot of the successful runs are also very close to 2h, so either reduce the test coverage or increase the timeout a bit? | 18:37 |
| fungi | or find a way to make tests more efficient/faster | 18:38 |
| dansmith | we made a lot of tests slower recently because it makes them more repeatable | 18:39 |
| dansmith | so you know, it's a tradeoff :) | 18:39 |
| dansmith | "fast and racy" vs "slow and predictable" | 18:39 |
| gmann | frickler: yeah, may be. I think it include slow tests also which we excluded in tempest full job also https://github.com/openstack/devstack-plugin-ceph/blob/13f94aaaf2b4a59581b1be5979600ca18a8df5c3/.zuul.yaml#L36 | 18:39 |
| gmann | and with 2 hrs timeout | 18:39 |
| gmann | we should divide this job to run slow marked tests and non-slow separately | 18:41 |
| dansmith | don't we already do that for integrated-storage? | 18:41 |
| frickler | was just writing this: splitting into two jobs might also be an option | 18:42 |
| gmann | yes, we do that for other integrated jobs | 18:42 |
| dansmith | and I think those timeout too, is my point | 18:42 |
| dansmith | but sure, obviously can't be worse | 18:42 |
| slaweq | +1 | 18:43 |
| gouthamr | okay looks like we've identified a strategy to try.. do we have a volunteer to test this strategy? :) | 18:43 |
| gmann | i can propose | 18:44 |
| gouthamr | gmann++ ty | 18:44 |
| gouthamr | we'll circle back on this next week; are there any other gate concerns to discuss? | 18:45 |
| gouthamr | #topic 2024.2 TC Tracker | 18:47 |
| gouthamr | #link https://etherpad.opendev.org/p/tc-2024.2-tracker (Technical Committee activity tracker) | 18:47 |
| frickler | gmann: are you still working on the affiliation diversity topic? the next election is coming up faster than we might think | 18:48 |
| gmann | frickler: yeah, I have election dates in mind, I will propose something soon this week most probably | 18:50 |
| gouthamr | amidst all the things he's up to :) | 18:50 |
| JayF | Hopefully we won't need it, but it'll be nice to know we won't deadlock should it occur again. | 18:50 |
| gouthamr | gmann: if you intend to pawn it off, i can help draft something that we can poke holes at | 18:50 |
| gmann | considering it might take time to merge but let's see how it goes | 18:50 |
| gmann | gouthamr: sure, will let you know | 18:50 |
| gouthamr | ^ yes; we'll hopefully time box the reviews on this | 18:50 |
| gmann | ++ | 18:51 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/902585 (Remove Eventlet From Openstack) | 18:51 |
| gouthamr | ^ this has been refreshed | 18:51 |
| gouthamr | JayF: i don't know if this now addresses/subsumes your WIP proposal: https://review.opendev.org/c/openstack/governance/+/916546 | 18:52 |
| JayF | TBH I thought I had abandoned that; I will now | 18:52 |
| gouthamr | ++ | 18:52 |
| gouthamr | gmann: spotz[m]: i think i want to freeze https://review.opendev.org/c/openstack/governance/+/918488 if you can take another look | 18:53 |
| gmann | gouthamr: yes, I have opened it in morning, will review today | 18:53 |
| gouthamr | spotz[m]: i tested and used the suggested fix feature on gerrit on your review: https://review.opendev.org/c/openstack/governance/+/915021 | 18:54 |
| gouthamr | (clarkb ^ this has been working like a charm for me all over) | 18:54 |
| gouthamr | spotz[m]: maybe you can help test the "accept suggestion" workflow :D - super neat improvement on gerrit | 18:55 |
| gouthamr | nothing else is popping to me as being urgent on the governance repo.. please correct me if you disagree | 18:56 |
| gmann | this one need one more review https://review.opendev.org/c/openstack/governance/+/920848 | 18:57 |
| gmann | and this is eligible to merge, gouthamr whenever you are running the script to check mergable one https://review.opendev.org/c/openstack/governance/+/917516 | 18:58 |
| gouthamr | ack will do gmann | 18:58 |
| gmann | thanks | 18:58 |
| spotz[m] | I’ll take a look | 18:59 |
| gouthamr | alright we're at the hour; so unfortunately, we'll skip open discussion | 18:59 |
| gouthamr | thank you all for the great discussion; if there's anything urgent to chat about, feel free to ping right after on this channel | 19:00 |
| gouthamr | see you all in-sync here again next week! | 19:00 |
| gouthamr | #endmeeting | 19:00 |
| opendevmeet | Meeting ended Tue Jun 18 19:00:24 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2024/tc.2024-06-18-18.00.html | 19:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-06-18-18.00.txt | 19:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2024/tc.2024-06-18-18.00.log.html | 19:00 |
| spotz[m] | Thanks all | 19:01 |
| opendevreview | Merged openstack/election master: Update PTL and TC election dates https://review.opendev.org/c/openstack/election/+/920166 | 19:07 |
| opendevreview | Merged openstack/governance master: Fixing the validate-legacy script https://review.opendev.org/c/openstack/governance/+/920848 | 19:12 |
| opendevreview | Merged openstack/governance master: Add TC liaison in DPL model implementation https://review.opendev.org/c/openstack/governance/+/917516 | 19:14 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Show TC and SIG repos under reference https://review.opendev.org/c/openstack/governance/+/918488 | 19:19 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Minor documentation fixes https://review.opendev.org/c/openstack/governance/+/922249 | 19:19 |
| gmann | gouthamr: thanks for the update, I am ok with governance change but moved my comment to governance-sigs change. sig-repo.yaml can stay in governance but governance-sigs existing table can fetch the data from governance and list the SIG repo in existing table | 19:45 |
| gouthamr | gmann: thanks i saw that.. i'll need to figure out how sphinx/jinja can fetch data from elsewhere; probably a macro | 19:46 |
| gmann | gouthamr: this table consist the 21 SIGs which are official list of SIG https://governance.openstack.org/sigs/ and this new table have only 14 SIG listed (because they only have repo) https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_185/918488/6/check/openstack-tox-docs/18513b4/docs/reference/sig-repos.html | 19:47 |
| gouthamr | yeah; and the link that i added is hidden at the bottom | 19:48 |
| gmann | gouthamr: or I should say that governance repo does not have a complete list of SIGs like we do for projects. other option is 1. move the SIG table from governance-sigs into governance which can include the SIG repo info also 2. link that in governance-sigs and SIG guidelines can stay there | 19:49 |
| gmann | this was governance repo will be managing the official SIG list and addition/removal can be done as per the TC motion | 19:49 |
| gmann | gouthamr: we can do this as a separate change as it is little more than listing SIG repo which is your intension in 918488 | 19:50 |
| gouthamr | yes | 19:51 |
| gmann | just for background, we created the governance-sigs repo because SIG were under TC + UC and not only TC things. | 19:51 |
| gmann | but as we do not have UC as a separate entity, it make sense to maintain SIG list in governance repo instead of separate | 19:52 |
| gouthamr | and now the UC is part of the TC; would it make sense to combine the two reos? | 19:52 |
| gouthamr | repos* | 19:52 |
| gouthamr | yeah; sounds good to me | 19:52 |
| gouthamr | i can work on that; it'll be easier to consolidate and drop the governance-sigs repo altogether | 19:53 |
| gouthamr | easier+less confusing in the future | 19:53 |
| gmann | we can or repo can be separate with governance-sigs provide the SIG guidelines or more details about SIGs working details and governance repo maintain the official list of SIGs | 19:53 |
| gmann | yeah, I am ok with that. it makes reading and maintenance easier | 19:54 |
| gmann | this is main file and there and we can move it in governance/reference https://github.com/openstack/governance-sigs/blob/master/doc/source/reference/sig-guideline.rst | 19:55 |
| gmann | *this is main file there.. | 19:55 |
| gmann | other benefits of combining is monitoring, we always forget to monitor SIGs if they are active or not, One of the reason is that SIG list is maintained in separate repo and we forget to check that and only focus on project teams. | 19:59 |
| gouthamr | yeah | 20:04 |
| gouthamr | ++ | 20:04 |
| gouthamr | some of these SIGs may be ready to be archived | 20:05 |
| gmann | yes | 20:11 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
