| opendevreview | Ian Y. Choi proposed openstack/election master: [Tool] update-governance: divide into tc/ptl/combined rounds https://review.opendev.org/c/openstack/election/+/978081 | 00:00 |
|---|---|---|
| *** bauzas7 is now known as bauzas | 01:54 | |
| *** jroll07 is now known as jroll0 | 08:45 | |
| opendevreview | Merged openstack/election master: [Tool] update_releases_calendar: Fix # of "-" for rendering https://review.opendev.org/c/openstack/election/+/978083 | 09:38 |
| *** vhari_ is now known as vhari | 10:28 | |
| opendevreview | chenker proposed openstack/governance master: Add RISC-V https://review.opendev.org/c/openstack/governance/+/988896 | 13:13 |
| opendevreview | chenker proposed openstack/governance master: Add RISC-V https://review.opendev.org/c/openstack/governance/+/988896 | 13:17 |
| gouthamr | tc-members: a gentle reminder that our weekly IRC meeting will be hosted here in ~45 minutes | 16:12 |
| gouthamr | the agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda | 16:13 |
| cardoe | I’m going to miss today. At a Boy Scout summer camp and only on mobile. | 16:34 |
| gouthamr | ack cardoe | 16:56 |
| spotz[m] | Have some s'mores for me! | 16:59 |
| gouthamr | #startmeeting tc | 17:01 |
| opendevmeet | Meeting started Tue Jun 23 17:01:02 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:01 |
| opendevmeet | The meeting name has been set to 'tc' | 17:01 |
| 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. | 17:01 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| noonedeadpunk | o/ | 17:01 |
| dansmith | o/ | 17:01 |
| bauzas | o/ (but fried) | 17:01 |
| mnasiadka | o/ | 17:03 |
| gouthamr | courtesy ping: frickler spotz[m] mnasiadka | 17:03 |
| gouthamr | ha, you sneaked in | 17:03 |
| spotz[m] | o/ had to put food in the microwave! | 17:03 |
| frickler | \o | 17:04 |
| gouthamr | alright, let's get started.. | 17:04 |
| gouthamr | thank you for joining! | 17:05 |
| gouthamr | #topic Last Week's Action Items | 17:05 |
| gouthamr | we took one regarding extended absences from TC activity | 17:05 |
| gouthamr | you must have seen an email about that, we can discuss that probably next week | 17:06 |
| gouthamr | looks like Zun and Zun-UI db/facade changes and CI fix patches for 2026.1 have merged | 17:07 |
| noonedeadpunk | yup, they're | 17:07 |
| gouthamr | #link https://review.opendev.org/c/openstack/zun/+/988859 | 17:07 |
| noonedeadpunk | though still our CI is failing for some reason with them | 17:07 |
| noonedeadpunk | specifically on zun-ui... but need more investigation if that's something with tests or not... | 17:07 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/zun-ui+branch:stable/2026.1 | 17:08 |
| gouthamr | ack, thank you for pursuing that on the ML and elsewhere | 17:08 |
| gouthamr | we took AIs to close out on a few pending governance reviews.. those have since merged | 17:08 |
| gouthamr | appears we've to wait for a window to rename x/cursor to openstack/cursor | 17:09 |
| gouthamr | so the governance patch to bring it under oslo similarly waits | 17:10 |
| clarkb | is it cursor or cursive? | 17:10 |
| gouthamr | worthy correction | 17:10 |
| gouthamr | cursive | 17:10 |
| clarkb | I corrected what was on the wiki and want to double check I didn't do so in error | 17:10 |
| gouthamr | ah! wasn't just me.. ty | 17:10 |
| fungi | oh, i bet that was my fault, thanks! | 17:11 |
| fungi | i'd been staring at btg survey analysis answers about ai use | 17:11 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/993388 (Move tenks from Ironic to Kolla governance) | 17:11 |
| gouthamr | ^ this has just been workflow-ed | 17:11 |
| gouthamr | that's the action items that i'm seeing, was anyone else working on anything to note? | 17:12 |
| noonedeadpunk | I'm waiting for vitrage deprecation patch to land to governance | 17:12 |
| gouthamr | ack | 17:13 |
| noonedeadpunk | #link https://review.opendev.org/c/openstack/governance/+/982869 | 17:13 |
| gouthamr | can i have some eyes on this please ^ | 17:13 |
| spotz[m] | opened | 17:13 |
| gouthamr | alright, ty.. we'll chat more about other open reviews that need attention at the end | 17:15 |
| gouthamr | #topic Contributor Experience Working Group | 17:15 |
| * fungi rubs hands together | 17:16 | |
| gouthamr | i briefly touched on this topic at the PTG, and wanted to get this started during this cycle | 17:16 |
| gouthamr | fungi ildikov and clarkb have been doing a lot of work regarding surfacing metrics, and i was hoping we can, as a group track and implement the changes we need in the community | 17:17 |
| noonedeadpunk | I recently stumbled upon some teams working on integrating an automated AI-based code review approaches | 17:18 |
| noonedeadpunk | And I was wondering if we wanna include some point like that to the topic | 17:18 |
| noonedeadpunk | of how would this may impact contributor experience | 17:18 |
| fungi | i think that's sean-k-mooney's experiments you're talking about | 17:18 |
| gouthamr | yes.. anything that influences the contributor experience would be fair game | 17:18 |
| noonedeadpunk | fungi: actually not | 17:18 |
| fungi | oh? | 17:19 |
| fungi | so more besides those | 17:19 |
| noonedeadpunk | but also from RedHat :) | 17:19 |
| gouthamr | we'll try not to boil the ocean, but, we'll have a forum to ideate, and implement | 17:19 |
| noonedeadpunk | I don't wanna point fingers as we got to mutual understanding during discussion | 17:20 |
| sean-k-mooney | there are 2 that im aware of | 17:20 |
| * frickler needed to check whether ideate is indeed a word or a typo :D | 17:20 | |
| spotz[m] | I think the key is to make sure we remain welcoming and open | 17:20 |
| fungi | i'll admit, i'm a little worried about the possibility that the ai/llm craze will dominate these discussions, when the fundamental problems we've identified all stem from insufficient communication between humans | 17:20 |
| sean-k-mooney | mine is a zuul job that invokes an agent and runs on cyborg and wathcer | 17:20 |
| noonedeadpunk | But imo - this affects contributor experience a lot from my prespective | 17:20 |
| sean-k-mooney | the ohter is a cronjob that uses an agent and is sued to comment on manilla | 17:21 |
| gouthamr | ^ i didn't know | 17:21 |
| fungi | i'm not sure that removing humans even farther from interaction solves the lack of human communication | 17:21 |
| noonedeadpunk | sean-k-mooney: then it's three | 17:21 |
| gouthamr | fungi: agreed.. | 17:22 |
| noonedeadpunk | or second is not only manila | 17:22 |
| sean-k-mooney | i dont think tis about removign human form teh interaction | 17:22 |
| noonedeadpunk | I would say that the results I have seen was extremely confusing and hardly useful for humans | 17:22 |
| sean-k-mooney | i at least allow it to leave comment but not vote +/- CR or V | 17:22 |
| noonedeadpunk | unless you want humans to waste time on AI written bs | 17:23 |
| sean-k-mooney | so its more set up to provide some extra context to other reviewer and provide early feedback | 17:23 |
| sean-k-mooney | noonedeadpunk: i have found mine to be very useful | 17:23 |
| noonedeadpunk | I'd need to see example of that | 17:23 |
| mnasiadka | noonedeadpunk: well, on other hands I have humans doing vibe reviews and pasting LLM outputs into Zuul comments - that’s the thing that confuses and irritates me the most these times | 17:24 |
| sean-k-mooney | and the watcher cores ask me to renabel it after it was broken for a month | 17:24 |
| sean-k-mooney | becuase they had value | 17:24 |
| mnasiadka | Erm, not Zuul - Gerrit | 17:24 |
| gouthamr | we're deviating :) things like this can be discussed in detail at the working group.. and to prevent going into rabbit holes, we'll have consensus on some ground rules.. | 17:24 |
| sean-k-mooney | ture | 17:24 |
| sean-k-mooney | oen of the first should be transparnacy | 17:25 |
| gouthamr | is anyone opposed to the idea here? I clarified what the group would do here: | 17:25 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/994046 | 17:25 |
| noonedeadpunk | mnasiadka: not sure how 2 AI agents talking to each other really solve that, when it's vibe-coded all the way trhough without potentially validating that direction where it goes even is valid... | 17:25 |
| noonedeadpunk | as one hallucination at the beginning gets things completely off rails for the whole thing. But anyway | 17:26 |
| frickler | why do we need a resolution to create a WG? | 17:26 |
| opendevreview | Merged openstack/governance master: Move tenks from Ironic to Kolla governance https://review.opendev.org/c/openstack/governance/+/993388 | 17:26 |
| gouthamr | not to reiterate the description, this is only the second working group we're setting up | 17:26 |
| gouthamr | #link https://governance.openstack.org/tc/reference/working-groups.html | 17:26 |
| sean-k-mooney | im also not sure this really falls undor Contributor Experience working group vs tact | 17:26 |
| gouthamr | frickler: good question, we don't _need_ it, but, it was a vehicle to drive consensus in the TC | 17:27 |
| sean-k-mooney | but there is some intersction i guess | 17:27 |
| gouthamr | sean-k-mooney: yes, great point.. i called that out in the group's description | 17:27 |
| gouthamr | sean-k-mooney: the WG will not own any repos, SIGs will.. and so many of the working group's repos can be in the TaCT SIG | 17:27 |
| frickler | oh, WG is different from SIG. | 17:28 |
| gouthamr | wanted to loop in fungi and mnasiadka into that part of the discussion | 17:28 |
| gouthamr | the work the OIF staff has been doing on the TC's request is really ad hoc with no formal mandate or continuity guarantee. | 17:29 |
| sean-k-mooney | just to renforce fungi's concern i would hope ai woudl be a small aspect of a "contibuter experince working group" working groups primay focus | 17:29 |
| fungi | i'll note that it's also now being done at the direction of the openinfra governing board, as part of their goal for us to "take openstack to the next level" | 17:30 |
| gouthamr | neat, i should clarify, no TC mandate then.. | 17:30 |
| fungi | well, it did totally start as an openstack tc mandate | 17:30 |
| fungi | but it's apparently also part of how we're going to satisfy the board's goal for us | 17:31 |
| gouthamr | ack | 17:31 |
| gouthamr | Aside from the "Bridging the gap" implementation, the WG will absorb/sunset the dormant First Contact SIG. It'll coordinate with Election WG rather than duplicating whatever that group does.. | 17:32 |
| gouthamr | by brainstorming with several of you here and the PTG, i've added three focus areas (recognition, health, onboarding) - things that fall through the cracks because no project team 'owns' them fully | 17:33 |
| gouthamr | and the TC itself doesn't have bandwidth to drive them week to week. | 17:33 |
| gouthamr | i'm also hoping that this becomes an onboarding zone to the TC | 17:34 |
| fungi | i guess one thing worth pointing out is that this wg seems to be focused primarily on the experience for contributors, while the btg effort hopes to balance that against the experience for project maintainers as well | 17:35 |
| fungi | (and hopefully grow casual contributors into maintainers/core reviewers and leadership roles) | 17:35 |
| gouthamr | hmm, maintainers are contributors too.. so i was hoping its both ways :) | 17:35 |
| gouthamr | ++ | 17:35 |
| fungi | yeah, when we get into discussions within the wg we can hash out how to make sure we keep that balance | 17:36 |
| fungi | but basically don't give maintainers a list of things they should be doing better, try to educate non-maintainer contributors on how to make maintainers' lives easier | 17:36 |
| fungi | since a lot of the communication breakdown we've observed was casual contributors not engaging usefully with maintainers who are trying to review their proposed changes | 17:38 |
| gouthamr | ack, that sounds good.. | 17:39 |
| mnasiadka | Unfortunately that ties well with the current LLM usage to review or generate code, which drives the maintainers frustration (at least in projects I’m active) | 17:39 |
| mnasiadka | (So the WG will not escape from that ;-) ) | 17:39 |
| gouthamr | nah, it'll deal with that.. but also we have some Action Items that the BTG analysis already surfaced | 17:40 |
| gouthamr | would be nice to start from there | 17:41 |
| gouthamr | i'll send a note to the Mailing List announcing the group and its intent.. we can certainly have a wider discussion there | 17:41 |
| gouthamr | and on the gerrit change | 17:41 |
| sean-k-mooney | mnasiadka: im kind of interested in your and noonedeadpunk expcice with llms in the proejcts ye work on | 17:41 |
| sean-k-mooney | perhaps a topic we can discuss more on #openstack-agentic-workflows channel later | 17:42 |
| gouthamr | ++ | 17:42 |
| gouthamr | alright, that's all i had for today on this topic | 17:42 |
| spotz[m] | I shall remove first contact sig from my calendar:) | 17:42 |
| gouthamr | it exists? | 17:42 |
| gouthamr | kidding :P will propose removal of all those artifacts if this group becomes a reality | 17:43 |
| sean-k-mooney | fungi: for what its worht one thing i have been using ai for is to add the regression tests and release notes for casual contibtors that done know how ot do that or dont have time | 17:43 |
| fungi | makes sense, though i'm also wary of approaches that imply maintainers need to take on additional work (even if it's just to prompt an llm) | 17:44 |
| sean-k-mooney | i.e. case where i have reviewed the change and gone "the direction is valild but your missing X, Y an Z" and then never hear back | 17:44 |
| fungi | anyway, all things we can hash out in the wg | 17:45 |
| gouthamr | ++ | 17:45 |
| gouthamr | #topic A check on gate health | 17:45 |
| sean-k-mooney | right in the few cases i have dont that it has been after a few week when an operator has gone "can we fix this" | 17:45 |
| sean-k-mooney | sory yes lets move on | 17:45 |
| gouthamr | anything to note regarding the gate? | 17:46 |
| fungi | stephenfin added a job today for libs to do more forward-looking unit testing on newer python versions | 17:46 |
| gouthamr | ah, related to: | 17:47 |
| fungi | basically voting py314 and non-voting 315 (pyenv-based) | 17:47 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/992765 (Distinguish between tested runtimes for clients and libraries) | 17:47 |
| fungi | yes, exactly. the change to create the mix-in template merged just a few hours ago | 17:47 |
| mnasiadka | I also have noticed https://review.opendev.org/c/openstack/devstack/+/994272 - which makes us more aware that rpm based devstack deployments are suffering due to RDO inactivity | 17:48 |
| frickler | oh, also the devstack change to support Ubuntu 26.04 is approved now. thx sean-k-mooney for doing all the work on that one | 17:49 |
| sean-k-mooney | yes i think rabbit is one of the problem issue with rpm distos | 17:49 |
| sean-k-mooney | frickler: no worries | 17:49 |
| gouthamr | ah neat | 17:50 |
| gouthamr | #link https://review.opendev.org/c/openstack/devstack/+/988482 (Add Ubuntu 26.04 platform support) | 17:50 |
| mnasiadka | sean-k-mooney: well, there are upstream rabbit repos we can use, I’m happy to do some digging in devstack to make that happen | 17:50 |
| sean-k-mooney | mnasiadka: its unclear what will happen with rdo, but i feel like decoupling our depence on it is better in teh long run | 17:50 |
| mnasiadka | But liberasurecode is nowhere to be found, but I guess the current version in RDO Epoxy is fine for Swift to work | 17:51 |
| spotz[m] | Quick RDO update, we did have a meeting between RH volunteers and community volunteers. While folks have stepped up to help no one is stepping up to be the main organizer:( | 17:51 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/FB3NPVQODMOF3EEABTUDX6BTV5OETGAL/ (Re: [rdo-dev] RDO RPMS Update - Meeting) | 17:52 |
| sean-k-mooney | mnasiadka: on option for https://github.com/openstack/liberasurecode | 17:52 |
| sean-k-mooney | would be to condier publishing it to pypi | 17:52 |
| gouthamr | RDO isn't really an OpenStack project/group.. so doesn't need PTL/DPL, but i get your meaning there spotz[m] | 17:52 |
| sean-k-mooney | cmake and other tools are there | 17:52 |
| spotz[m] | It was just easier I felt to use familiar terms for chair/co-chair, maintainers, etc | 17:53 |
| mnasiadka | sean-k-mooney: that’s C code? | 17:53 |
| sean-k-mooney | mnasiadka: yes it is | 17:53 |
| mnasiadka | Ah, as in build on install time | 17:53 |
| sean-k-mooney | or package it as a binary wheel | 17:54 |
| sean-k-mooney | like a cpython module | 17:54 |
| sean-k-mooney | anyway that was just an idea | 17:54 |
| gouthamr | alright, anything else for $topic? | 17:55 |
| mnasiadka | Worst case scenario a COPR repo or something | 17:55 |
| gouthamr | #topic Open Discussion | 17:56 |
| fungi | note that since liberasurecode is part of openstack, we shouldn't necessarily require distro packages for devstack | 17:56 |
| gouthamr | we discussed cursive's patches.. | 17:56 |
| fungi | (though it does need to be compiled somehow) | 17:56 |
| gouthamr | rosmaita added an item on retiring cinderlib | 17:56 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/994004 | 17:57 |
| fungi | yes, in opendev's 19:00 utc meeting today we'll talk about scheduling for the cursive namespace move | 17:57 |
| gouthamr | ++ ty fungi | 17:57 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/PJMYN5KFN25MO443EESAVRQ3TBSOZ7RZ/ ([cinder][unmaintained] retiring cinderlib) | 17:57 |
| gouthamr | honestly, just kill it no? | 17:57 |
| frickler | zuul has proposed its own AI policy, which may be interesting to look at, too https://review.opendev.org/c/zuul/zuul/+/993998 | 17:57 |
| gouthamr | 'mostly-dead.config' seems unnecessary, and im assuming you meant it as a joke | 17:58 |
| rosmaita | my question about cinderlib was whether we can officially retire it even if the unmaitained branches still exist | 17:58 |
| rosmaita | or whether we need to get the unmaintainers to delete them | 17:58 |
| gouthamr | frickler: neat, ty for sharing | 17:59 |
| rosmaita | the 'mostly-dead' was so that we can have it both ways, officially retired but unmaintained branches still existing | 17:59 |
| frickler | rosmaita: iiuc there is no 2024.1 branch because it was deprecated before? | 18:00 |
| rosmaita | yes, last branch was 2023.2 | 18:00 |
| frickler | so then the criterium for keeping older unmaintained branches is no longer fulfilled | 18:00 |
| sean-k-mooney | well there was orgianlly only ment to be 1 unmainted brnach | 18:01 |
| sean-k-mooney | and it woudl be EOL'd once hte next slurp becomes unmaintaiend | 18:01 |
| sean-k-mooney | i know that some have step up to do some maintiance | 18:02 |
| sean-k-mooney | but even till they shoudl not live forever | 18:02 |
| frickler | that's not how the current policy is worded. it is possible to keep older um branches alive as long as someone claims to care for them | 18:02 |
| frickler | but it is not possible to have gaps | 18:02 |
| dansmith | yeah, not sure where "only one unmaintained branch" came from | 18:03 |
| sean-k-mooney | provided they opt in every release and the gate are green | 18:03 |
| fungi | my main reason for bringing it up was that the branches ought to be deleted *before* we merge the retired acl that makes doing so harder | 18:03 |
| rosmaita | that makes sense | 18:03 |
| dansmith | frickler: I actually thought gaps were explicitly allowed, if people were rallying around a single common oft-deployed release | 18:03 |
| frickler | ok, so just make a release patch to eol them | 18:03 |
| gouthamr | "Only SLURP branches are eligible for Unmaintained status." | 18:04 |
| gouthamr | "By default, only the latest eligible Unmaintained branch is kept open." | 18:04 |
| gouthamr | #link https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained | 18:04 |
| frickler | "No SLURP branches may be skipped between the oldest unmaintained branch and the current maintained releases." | 18:04 |
| dansmith | we have a gap right now: https://releases.openstack.org/, I guess because of the gap | 18:04 |
| sean-k-mooney | it came form here by the wy https://github.com/openstack/governance/blob/245af834a476ee45e562b6e9c05cc45c1574fa17/resolutions/20230724-unmaintained-branches.rst?plain=1#L83-L85 | 18:04 |
| sean-k-mooney | yes that | 18:04 |
| dansmith | er, because of the slurp rule | 18:04 |
| dansmith | okay so meant no gaps amongst slurps | 18:05 |
| sean-k-mooney | https://github.com/openstack/governance/blob/245af834a476ee45e562b6e9c05cc45c1574fa17/resolutions/20230724-unmaintained-branches.rst?plain=1#L97-L113 | 18:05 |
| sean-k-mooney | so the transition section is the real reason we have many unmainted branches | 18:05 |
| sean-k-mooney | we only really applied the other ules form antelope on | 18:06 |
| dansmith | ack, fair enough, I didn't remember the transition being different | 18:06 |
| rosmaita | i think the key thing is there is supposed to be an upgrade path from the oldest existing unmaintained branch into the stable branches | 18:06 |
| fungi | yes, before antelope there was technically no slurp | 18:06 |
| gouthamr | alright, i think this is worth asking in #openstack-unmaintained | 18:06 |
| gouthamr | the TC doesn't really care imo, the EOL/retirement can happen and i'm glad you're asking rosmaita | 18:07 |
| sean-k-mooney | rosmaita: well upgrade are best effort form unmainted to stable | 18:07 |
| rosmaita | ok, and i will follow frickler's advice and put up a patch to eol the unmaintained cinderlib branches | 18:07 |
| gouthamr | we're 8 minutes over :) | 18:08 |
| gouthamr | anything to note for the minutes today | 18:08 |
| gouthamr | if not, thank you for joining and staying on! | 18:09 |
| gouthamr | #endmeeting | 18:09 |
| opendevmeet | Meeting ended Tue Jun 23 18:09:01 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-06-23-17.01.html | 18:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-06-23-17.01.txt | 18:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-06-23-17.01.log.html | 18:09 |
| sean-k-mooney | rosmaita: as an aside i guess the cinderlib retiment is because that fucntionatliy has been absoved into cidner itslef or nolonver provide value to ship seperatly? | 18:10 |
| rosmaita | sean-k-mooney: no, it was more that there was no interest in further development | 18:16 |
| sean-k-mooney | oh ok | 18:17 |
| sean-k-mooney | """The Cinder Library, also known as cinderlib, is a Python library that leverages the Cinder project to provide an object oriented abstraction around Cinder's storage drivers to allow their usage directly without running any of the Cinder services or surrounding services, such as KeyStone, MySQL or RabbitMQ.""" | 18:17 |
| sean-k-mooney | os that is very diffent then neutron-lib | 18:17 |
| sean-k-mooney | neutorn-lib has all the common code that an out of tree driver might want to reuse to write a neutron driver | 18:18 |
| rosmaita | yeah, it looked like a good idea, but there wasn't a lot of uptake | 18:19 |
| fungi | yeah, cinderlib was more about "stand-alone cinder" use cases, if memory serves | 18:19 |
| sean-k-mooney | where as cinderlib was more about usign the cidner service as a lib so ya very diffnt usecase | 18:19 |
| fungi | making it available as a backend in non-openstack contexts like kubernetes | 18:20 |
| gouthamr | was related to https://github.com/Akrog/ember-csi-operator | 18:20 |
| sean-k-mooney | ya i was thinking of ember csi | 18:20 |
| sean-k-mooney | but its more of an embded mode | 18:20 |
| sean-k-mooney | ember csi coudl just talk to a standalone cinder too | 18:20 |
| fungi | without the abstraction layer, right | 18:21 |
| sean-k-mooney | well i jsut mean most csi drviers are not also the storager laywer | 18:22 |
| gouthamr | you don’t need it if you could just make cinder-csi work independent of OpenStack | 18:22 |
| sean-k-mooney | well i think that is basiclly what has happend | 18:22 |
| gouthamr | I mean, if you were going to talk to OpenStack Cinder - you might as well just use cinder-csi* | 18:23 |
| sean-k-mooney | cinder-csi just uses goperhcloud sdk to talk to a real cinder | 18:23 |
| gouthamr | right now there’s a hard limitation on attaching only to nova VMs | 18:23 |
| sean-k-mooney | gouthamr: right it just 2 diffent approch to reusing cidner ember tried to embded cidner in it | 18:23 |
| sean-k-mooney | and cidner-csi keept the system bondary | 18:23 |
| gouthamr | yes | 18:23 |
| sean-k-mooney | gouthamr: where is that requriement? attachign onnly to nova vms | 18:24 |
| gouthamr | eharney/TheJulia etc were chatting about baremetal attachments with cinder-csi (like manila-csi can) | 18:24 |
| gouthamr | sean-k-mooney: cinder-csi’s node plugin calls nova’s volume attach APIs | 18:25 |
| sean-k-mooney | do you mean kubevirt vms? oh but wait that doesnt reallly make sense | 18:25 |
| gouthamr | which in turn call os-brick to plumb in the connection | 18:25 |
| TheJulia | On the baremetal side, we likely need to terminate on the host, unless we build a model of randomizing all NQNs. | 18:25 |
| TheJulia | Which, I think... is on the table | 18:26 |
| sean-k-mooney | gouthamr: when you say nova volume attachment api are you tralkign about nova's actull api ? | 18:26 |
| sean-k-mooney | or the attament apis in cidner that nova uses | 18:26 |
| sean-k-mooney | because i have used cider before to provdie iscis volumes to my laptop | 18:27 |
| sean-k-mooney | so there is nothing in cidner api that requrid an attachmetn to be used with a nova instance | 18:27 |
| timburke | re: liberasurecode -- fwiw, pyeclib (the python bindings that swift uses to interface with liberasurecode) now publishes binary wheels that bundle liberasurecode (as well as isa-l, one of the commonly used backends). a while back i tried dropping it from bindep, but ran into trouble with some old rolling-upgrade jobs -- i should probably dust off https://review.opendev.org/c/openstack/swift/+/933697 | 18:27 |
| sean-k-mooney | timburke: oh cool | 18:28 |
| sean-k-mooney | timburke:swift historically has tested very old verions beyound the normal testing runtime | 18:29 |
| gouthamr | sean-k-mooney: yes, I’m saying that cinder-csi does the nova volume attach calls.. with v3 attachment APIs, you can grab the connection info and do local attachments yourself, but the csi driver was purpose built for nova so far | 18:30 |
| sean-k-mooney | i.e. swift-tox-py37 | 18:30 |
| sean-k-mooney | gouthamr: wow because those api where deprecated in nova before k8s or csi was a thing | 18:31 |
| sean-k-mooney | gouthamr: well if it the ones im thinking of | 18:32 |
| gouthamr | probably not those ones :D | 18:32 |
| gouthamr | https://github.com/kubernetes/cloud-provider-openstack/blob/ae97b53f6efe73564c6e02de6e0431d962363000/pkg/csi/cinder/controllerserver.go#L324 | 18:32 |
| sean-k-mooney | oh this is beign used for runing openshfit on openstack | 18:34 |
| sean-k-mooney | and to attach cinder volume to the openstack vms | 18:35 |
| sean-k-mooney | attaching them to the k8s workher hosts directly | 18:35 |
| gouthamr | yes, but, this can be made to support k8s running on baremetal rather than on Nova VMs | 18:35 |
| sean-k-mooney | thats a diffent attachment flow then i tought was being used | 18:35 |
| sean-k-mooney | well cloud provier openstack is desgiend to allow creating worker nodes for k8s which can be vms or ironci nodes | 18:37 |
| TheJulia | I've been pretty deep into looking at the topic as related to baremetal, but entirely unrelated to k8s natively on the host. | 18:37 |
| sean-k-mooney | right | 18:37 |
| TheJulia | I have customers who want to physically boot entire hosts from SAN arrays and ultimately cinder volumes | 18:37 |
| sean-k-mooney | CSI is the contaienr storage interface an i was thinking of a baremetnal k8s cluser rather then shift/k8s on openstack toplogy | 18:38 |
| sean-k-mooney | TheJulia: that works today updtream right | 18:38 |
| TheJulia | Post-Boot volume attachment is more a userspace and access rights issue, i.e. workload have sufficient access to do it's needful | 18:38 |
| gouthamr | yes, build tenant dedicated storage arrays! :) | 18:38 |
| sean-k-mooney | TheJulia: ironic has cider boot supprot | 18:38 |
| TheJulia | sean-k-mooney: iscsi only, everyone wants nvme. | 18:38 |
| TheJulia | The SNIA benchmarks are super compelling | 18:38 |
| TheJulia | like, absurdly compelling. | 18:38 |
| sean-k-mooney | TheJulia: yep i have used the icsi boot once in my home lab | 18:38 |
| sean-k-mooney | nvmeof woudl be a nice perfomance uplift | 18:39 |
| TheJulia | ~70% | 18:39 |
| sean-k-mooney | i belvie nvmeof is also someithng folks have looked into for cpeh clusters | 18:39 |
| TheJulia | 71% in SNIA benchmarks if you care about jumbo MTUs | 18:39 |
| TheJulia | Yeah, thats a thing also being desired out there | 18:39 |
| sean-k-mooney | im not sure how much protocol effince you get form rbd vs nvme in teh cecph case | 18:40 |
| sean-k-mooney | but it cerntally woudl allow you to share the same storage pool with diffent workload (vms and baremental) | 18:40 |
| TheJulia | I'm not sure that has been explicitly benchmarked, but more and more I'm hearing capability over strict performance view | 18:40 |
| sean-k-mooney | if your already in the ceph echosystem | 18:40 |
| sean-k-mooney | there is also the windows aspectfg | 18:40 |
| sean-k-mooney | *aspect | 18:41 |
| TheJulia | yup | 18:41 |
| sean-k-mooney | i may be mistake but i dotn think there is a native rbd driver for wondwos but windows does supprot nvmeof pretty well | 18:41 |
| TheJulia | well, the problem you need the secret rbd credentials and all, which for a random tenant is just super duper bad | 18:42 |
| sean-k-mooney | that or per tenant keys | 18:42 |
| sean-k-mooney | but ya you need direct cluster access | 18:42 |
| TheJulia | yeah, and you still can't boot. That is the biggest thing is people are trying to also phase out storage devices on local machines... again. | 18:43 |
| sean-k-mooney | although in the baremental world you may be able to attach via the bmc if redfhish supprot that the same way it does for iscsi | 18:43 |
| sean-k-mooney | but enve then the tenat can use ipmitool or simialr to look at that configuration in most cases | 18:44 |
| TheJulia | The Hardware assisted and UEFI software initiators seem to and Software initiators are not in the best shapes on the vendors which have them either | 18:44 |
| * TheJulia is about to try and brig it up on a call | 18:44 | |
| TheJulia | Tenants should never be touching BMCs though. | 18:45 |
| sean-k-mooney | shoudl and do are very diffent thigns | 18:45 |
| TheJulia | yup | 18:45 |
| sean-k-mooney | but ya if you set passwords and you dotn have firmware bugs | 18:45 |
| sean-k-mooney | then its at least somehwat secure. | 18:45 |
| sean-k-mooney | a lot of older system used to alwasy present a sperate deivce to thse host system for the bmc and on some systems that alway bypassed auth | 18:46 |
| TheJulia | inband ipmi is still a thing | 18:46 |
| sean-k-mooney | i.e. root on the host could alwasy access the bmc direcly like on my realy old hp servers | 18:47 |
| TheJulia | vendors now prefer inband ethernet interfaces | 18:47 |
| TheJulia | *vomit* | 18:47 |
| TheJulia | which are just usb devices | 18:47 |
| sean-k-mooney | i was going to say maybe that better (beign usb based) but it was proably just cheaper | 18:48 |
| sean-k-mooney | the inband ipmi interaces used to be hooked off or the spi bus or similar | 18:48 |
| sean-k-mooney | with less isolation between the host and the bmc | 18:49 |
| sean-k-mooney | granted the only sysstem i own currently with ipmi supprot also still uses a front side bus betwen teh cpu and motherboard so my personal knowage on that front is very out of date | 18:50 |
| TheJulia | yeah, and some vendors still have them for the most part but now ship with those interfaces off generally since you can force reset the BMC credentials with them | 18:51 |
| TheJulia | or at elast, can attempt, they may not actually succeed | 18:51 |
| fungi | stephenfin: revisiting the move of x/cursive into the openstack/ namespace, it looks like the current core review and release team members for it are jhuapl folks and barbican-core, are those maintainers in favor of the project getting adopted by openstack, or are they even in the picture any longer? | 20:04 |
| fungi | just making sure we have consent | 20:04 |
| fungi | https://review.opendev.org/admin/groups/cursive-core,members and https://review.opendev.org/admin/groups/cursive-release,members (same people in both) | 20:05 |
| fungi | it doesn't appear that any of the individuals who have core review rights on that repository have commented on either the project-config or governance changes | 20:07 |
| fungi | that aside, assuming they're on board with the proposal, we're tentatively targeting some time on thursday july 9 for the rename maintenance window to accommodate sysadmin availability (vacations/travel and such) | 20:08 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!