| gtema | gouthamr: I am on PTO for 2 weeks so not going to participate today and next week TC meeting | 11:23 |
|---|---|---|
| opendevreview | Merged openstack/election master: Switch foundation membership check to new style https://review.opendev.org/c/openstack/election/+/954787 | 12:37 |
| noonedeadpunk | Hey! Sorry for not notifying in advance, but I won't be able to join today | 14:56 |
| gouthamr | ack noonedeadpunk | 14:56 |
| gouthamr | hola tc-members: gentle reminder that our weekly IRC meeting will happen here in ~59 minutes | 16:01 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Jul 29 17:00:41 2025 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17: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. | 17:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| spotz[m] | o/ | 17:01 |
| frickler | \o | 17:01 |
| gouthamr | noted absence: n o o n e dead punk, m n a sia d k a | 17:02 |
| gouthamr | courtesy-ping: gmaan, gtema, cardoe, bauzas | 17:02 |
| bauzas | o/ | 17:02 |
| gmaan | o/ | 17:02 |
| bauzas | last meeting for me before my 3-week PTO period | 17:03 |
| frickler | gouthamr: gtema wrote earlier about being away, too | 17:03 |
| gouthamr | oh | 17:03 |
| gouthamr | i missed that | 17:03 |
| gouthamr | ty frickler | 17:03 |
| gouthamr | bauzas: we'll help you pack :) | 17:04 |
| bauzas | ;-) | 17:04 |
| gouthamr | alright, lets get started.. | 17:05 |
| gouthamr | #topic Last Week's AIs | 17:05 |
| gouthamr | we took an AI about a long pending patch to clarify affiliation | 17:05 |
| spotz[m] | Oh and I’m out next week speaking of away:) | 17:05 |
| gouthamr | ack spotz[m] | 17:05 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/949432 (Require declaration of affiliation from TC Candidates) | 17:06 |
| gouthamr | this needs to be updated to depend on | 17:06 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/956024 (Define "affiliation" within the context of the TC) | 17:06 |
| gouthamr | i'll do that.. but please do review | 17:07 |
| gouthamr | spotz[m]: already noted that we can copy the bylaws' definition of this before it is taken down | 17:07 |
| gmaan | I think that was more legal and might need legal chekcs? | 17:07 |
| gouthamr | yeah its more or less the same in essence *i think*, but has more legalese | 17:08 |
| gmaan | and that is why we wanted a simple one which can cover TC diversity things from organizational point of view | 17:08 |
| gmaan | It will be helpful to keep it as simple as even it is not full | 17:08 |
| gouthamr | i agree in spirit, think spotz[m] wanted to cover our bases in case someone challenged it | 17:09 |
| gouthamr | she had a good point about subsidiaries - an example being Red Hat owned by IBM, except, i, as a Red Hat employee know that i'm not an IBM employee, but, how does the world perceive this? | 17:10 |
| gmaan | that is the main point and challenge, if we want to have it to challenge then it is out of scope from TC as that might need legal checks | 17:10 |
| gmaan | we consider those separate organization from TC perspective. | 17:10 |
| gmaan | I mean we just need to define what we want from TC organizational diversity point of view | 17:11 |
| gmaan | otherwise there are a lot of things- partner companies etc | 17:11 |
| gouthamr | because they're separate OpenInfra Member companies? | 17:11 |
| gmaan | I do not know :) that is why I am saying going in same way as it was in bylaw can have a lot of open questions | 17:12 |
| fungi | note that there's no requirement for a tc member to be employed by a member company (or any company at all), so that sounds like it could be a questionable distinction | 17:12 |
| gmaan | yeah | 17:12 |
| gmaan | we should not consider membership here | 17:12 |
| gouthamr | ah yes, i tried stating that in the first line of the change | 17:12 |
| gmaan | ++ | 17:12 |
| bauzas | I haven't looked at the affiliation patches but I'll | 17:13 |
| bauzas | I still have one open question about external people working on the behalf of a company | 17:13 |
| gmaan | I will add comment there and we can discuss async | 17:13 |
| bauzas | is it covered by the affiniliation definition patch ? | 17:13 |
| gmaan | bauzas: those still consider as contractor/employee and should decalre their affiliation as the company they are contributing for | 17:14 |
| bauzas | okay, that was my thought, just wanted to make sure we were clarifying that | 17:14 |
| gouthamr | yes | 17:14 |
| gouthamr | we are | 17:14 |
| gmaan | ++ | 17:14 |
| bauzas | I'll shepherd the patches anyway | 17:15 |
| gouthamr | tl;dr: we need a TC member to be an individual member of the OpenInfra Foundation, and they don't need to be affiliated.. but, if they are affiliated, we've the diversity requirement .. we got a question on what does it mean to be affiliated, that's being determined here: https://review.opendev.org/c/openstack/governance/+/956024 | 17:15 |
| gmaan | bcz there can be case where employee of CompanyA contributing on behalf of companyB with companyA and CompanyB contract | 17:15 |
| gouthamr | ^ lets discuss more directly on the patch | 17:15 |
| gmaan | we just need to make sure "declare your affiliation from contribution point of view" | 17:15 |
| gmaan | rest other (subsidiary, contract etc ) are out of scope for us | 17:16 |
| gmaan | gouthamr: ++ I will check and add comment there | 17:16 |
| gouthamr | ty gmaan | 17:16 |
| gouthamr | and others for reviewing! | 17:17 |
| gouthamr | i also looped in folks that shared their opinion here, and TheJulia and jbryce.. lets hash this out :) | 17:17 |
| * TheJulia appears | 17:17 | |
| fungi | TheJulia: tl;dr, defining "affiliation" in https://review.opendev.org/949432 | 17:18 |
| gouthamr | haha, didn't mean to summon you, but, please do check the patch above when you have time TheJulia | 17:18 |
| gouthamr | lets move to the next AI: Monasca (and inactive projects in general).. | 17:18 |
| TheJulia | fungi: reading | 17:18 |
| gouthamr | i've added this as a separate topic to cover what happened between meetings and what we'll do next | 17:18 |
| gouthamr | we had an AI regarding a review dashboard, i suppose we'll table that to next week since no onedeadpunk isn't here.. no rush | 17:19 |
| spotz[m] | Fand I’m laggy | 17:19 |
| * gouthamr is that a reference to something? | 17:20 | |
| * gouthamr hi laggy, am not the Fand you're looking for.. | 17:20 | |
| gouthamr | we had a couple of minor AIs on tracking Debian Trixie in the CI | 17:20 |
| gouthamr | frickler had a devstack patch | 17:21 |
| gouthamr | #link https://review.opendev.org/c/openstack/devstack/+/954653 | 17:21 |
| gouthamr | still WIP | 17:21 |
| TheJulia | fungi: okay, I'm ignoring the actual back and forth on the discussion, should I be reading that. Where this has been a challenge is somehow folks trying to infer wholely owned subsidaries are legally the same company but it boils down to the legal responsibility of the command chain | 17:21 |
| frickler | yes, waiting for trixie to be released before proceeding, so we can add in mirrors in opendev first | 17:22 |
| TheJulia | i.e. if IBM legal, for example in-house counsel, were to approach me, I would be required to refer them to Red Hat legal (in-house counsel) because IBM legal is entirely outside of my structural chain of command | 17:22 |
| gmaan | is this first one of do we have kolla or somewhere Debian Trixie job/test running | 17:22 |
| gouthamr | ah ty frickler | 17:22 |
| gmaan | frickler: ++ | 17:23 |
| gouthamr | in a similar vein, sean-k-mooney is trying to convert the Ceph job to use debian | 17:23 |
| gouthamr | bookworm, because we'll wait on the image, mirrors, devstack support etc to exist to try this with trixie | 17:23 |
| gouthamr | #link https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/955714 | 17:23 |
| sean-k-mooney | that mainly to renable test cover by using one of our other supprot runtime | 17:24 |
| sean-k-mooney | isntead fo just disabling the test becuse ubuntu has a packaging bug | 17:24 |
| gmaan | ++, this is good example of distributing our testing among different distro | 17:24 |
| sean-k-mooney | but yes bookworm not trixe bcasue of supprote runtime and the fact openstack does not work on trixy yet | 17:24 |
| clarkb | and trixie isn't released | 17:25 |
| sean-k-mooney | we coudl use trixie/13 next cycle after its released | 17:25 |
| fungi | trixie release is schedule for next week | 17:25 |
| gmaan | yeah, we cna move that to trixie later | 17:25 |
| TheJulia | gmaan: the weirdness of on behalf of another company is... very weird, even more so for copyright since lineage is lost in such cases and thus really should be avoided at all costs. | 17:25 |
| gmaan | sean-k-mooney: ++ make sense t use trixie in next cycle runtime | 17:25 |
| sean-k-mooney | just keep in mind | 17:25 |
| sean-k-mooney | trixie use python 3.13 | 17:26 |
| sean-k-mooney | and eventlet is not compatible with that | 17:26 |
| gmaan | oh | 17:26 |
| sean-k-mooney | so using it will be partly gated by that | 17:26 |
| gmaan | py3.13, I did not realize that | 17:26 |
| sean-k-mooney | i know zigo is activly trying to reslove that | 17:26 |
| frickler | sean-k-mooney: iiuc all issues are resolved, tempest is passing | 17:26 |
| gouthamr | TheJulia: ah, ack, ty - i don't know how easy it is to define that succinctly, but "legal responsibility of the command chain" may be invisible to the outside world.. lets discuss on the patch itself.. (sorry again for cutting this) | 17:26 |
| sean-k-mooney | but its currently a blocker ot using it but it good to use as a smoketest/canary | 17:26 |
| sean-k-mooney | frickler: really | 17:27 |
| sean-k-mooney | that awsome news | 17:27 |
| gouthamr | w00t, TIL | 17:27 |
| frickler | the last issue was actually not py3.13, but a change in mariadb | 17:27 |
| sean-k-mooney | oh the transaction thing | 17:27 |
| frickler | yep | 17:27 |
| sean-k-mooney | so then yes we shoudl stronctly consider adding trixe to the testing runtime for 2026.1 keeping bookworm for stable upgrade testing | 17:28 |
| sean-k-mooney | and in 2026.2 we can drop bookwrom ot not infinetly grow the test matix | 17:28 |
| gouthamr | good suggestion.. i'll work on the runtime update | 17:28 |
| frickler | yes, currently the timetable looks like that will be feasible | 17:29 |
| gouthamr | that's all the things we were working on that i see as AIs from our last meeting.. was anyone else working on anything to note? | 17:29 |
| sean-k-mooney | for nova w are curently using debign to test some thing that redhat and canonical compile out fr what its worth. like spice supprot. | 17:29 |
| gmaan | TheJulia: well, its about how those company/employee are contracted and allow them to use their affiliation which is again part of the contract. In summary, employee are on-site/deputed to their organization for particular duration. but yes we cannot cover all cases or assume things and mainly avoid legal checks | 17:29 |
| TheJulia | gmaan: oh yeah, indeed. For example, there is a concept in close business relationships of dual badge employes | 17:30 |
| sean-k-mooney | i mean in that case you could list both | 17:30 |
| TheJulia | one some level, one company pays for that employee, but then and only then can that individual self identify who they are working on behalf of | 17:30 |
| sean-k-mooney | but the affiation thing is mroe to disclose bias not a catch all for all influcance | 17:31 |
| TheJulia | sean-k-mooney: quite possibly, granted in the cases I'm aware of those folks are not upstream contributors | 17:31 |
| TheJulia | exactly, which is why its important to focus discussion on what is the common good | 17:32 |
| gouthamr | all good inputs, lets talk on the gerrit proposal.. | 17:32 |
| gouthamr | #topic AI Working Group's White Paper - Call for Resources | 17:32 |
| TheJulia | Yeah, I'm reading through the back and forth now | 17:32 |
| fungi | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/QGADCGXW2J5PJZKDH24VMJJJOM72GQTF/ OpenStack for AI Whitepaper coordination mailing list and meeting info | 17:32 |
| fungi | anybody interested in ai workloads on openstack or tuning openstack deployments to support them should consider participating | 17:32 |
| bauzas | I won't be able to join next meeting but I definitely plan to help for the whitepaper | 17:33 |
| gouthamr | yes, i see a specific call out for folks that know the services deeply, i suspect we want to call out any features/architectures that are beneficial for AI workloads | 17:33 |
| fungi | yeah, for those who haven't skimmed the announcement, just a reminder that the call is scheduled for 13:00 utc on thursday of this week (july 31) | 17:34 |
| sean-k-mooney | there was a ptg seesion on this topic too last cycel | 17:34 |
| sean-k-mooney | i assume there will be a simialr bird of a fether seesion at the sumit or next ptg | 17:34 |
| gouthamr | i think they're trying to wrap up this paper by the Summit | 17:34 |
| bauzas | correct | 17:35 |
| sean-k-mooney | i assuem the effort will evovle into a working group or sig ot drive this usecase in openstack going forward | 17:35 |
| sean-k-mooney | oh it is a working group already | 17:35 |
| gouthamr | yes, it's a Foundation working group right now.. | 17:36 |
| gouthamr | (like the VMWare Migration Working Group) | 17:36 |
| fungi | it's already organized as a foundation-level working group, but i could see some possibility for a mirrored structure within the openstack community too (like a sig maybe) | 17:36 |
| bauzas | and there were some talks already | 17:36 |
| bauzas | like showcases | 17:36 |
| sean-k-mooney | well we know you can run ai workload on openstack (people have been doign it of year) btu there is defeily room for improvment so i will be interested to see what tehy whitepaper containes when its done | 17:37 |
| gouthamr | if you're aware of these gaps,sean-k-mooney, an OpenStack SIG could be helpful - it'd be development focussed if we were to build specifically to address these AI use cases | 17:38 |
| fungi | i think it's more about explaining how it's done by various organizations and covering the various use cases | 17:38 |
| bauzas | zactly | 17:38 |
| fungi | but sure, potential improvements to the platform to make that even better would probably also be a good outcome | 17:38 |
| bauzas | but also collecting some needs | 17:38 |
| gouthamr | lets chat about this some more at the 1300 UTC call this thursday | 17:40 |
| gouthamr | anything else on $topic? | 17:40 |
| * gouthamr next up.. | 17:41 | |
| gouthamr | #topic Proceeding with Monasca's retirement | 17:41 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/953671/comments/05494668_4deb962f | 17:41 |
| gouthamr | ^ thuvh told us that they'd prefer to get the project retired.. | 17:41 |
| gouthamr | the repos owned by the monasca team have no stable branches as we noted in last week's meeting | 17:42 |
| gouthamr | just the "unmaintained/2023.1" branch | 17:42 |
| bauzas | let it go then ? | 17:42 |
| gouthamr | the unmaintained branch was already not the project team's responsibility - so i think we can consult the ML and unmaintained-core and proceed | 17:43 |
| gmaan | I was not 100% sure if they are ok for retirement or they understood 'moving to legacy' correctly means that is retirement | 17:44 |
| gmaan | but yes, their vote on the retirement change in governance can confirm it officially | 17:44 |
| gmaan | just want to be more explicit in case there is any communication gap or gap in understanding of retirement | 17:44 |
| fungi | also retirement is not irreversible, and doesn't really result in much difference with regard to the current state of activity in the project anyway | 17:44 |
| gouthamr | i think you clarified that in your earlier comments on the change | 17:44 |
| gouthamr | fungi: +1 | 17:45 |
| sean-k-mooney | the main impact is offically removing it form the integrated release coorect | 17:45 |
| fungi | (sorry for the double-negative, should have said "retirement is reversible" i guess) | 17:45 |
| sean-k-mooney | it can be unretired if folks really wanted too | 17:45 |
| gouthamr | sean-k-mooney: it's not being released since 2023.1 | 17:45 |
| gmaan | ok because one time they said they want to maintain then after reading meeting logs ( which was more of discussion about how we can achieve healthy maintenance and avoid same situation again) they are ok for retirement | 17:45 |
| sean-k-mooney | gouthamr: yep, its technially supprot in watcher as a backend but it has no docs/testing | 17:46 |
| gmaan | I do not want to push pressure to them if they want to maintain. | 17:46 |
| sean-k-mooney | we are offically decleering it deprecte/experimental this cycle adn considering if we would remove supprot in 2026.1 | 17:46 |
| sean-k-mooney | its retirement woudl factor into that too | 17:47 |
| bauzas | this is already communicated afaik | 17:48 |
| bauzas | now the question is whether we would retired it | 17:48 |
| sean-k-mooney | i have no objection one way or another . but if it is retired it make droping supprot next cycle an easy desion for us | 17:49 |
| gouthamr | sean-k-mooney: so to use it as a backend in this release, one would have to use watcher from 2025.2 and monasca-api from 2023.1 or older, i think? | 17:49 |
| sean-k-mooney | yep | 17:49 |
| sean-k-mooney | which may or may not be co installable | 17:49 |
| sean-k-mooney | as i said we do not have ci for that and we are lackign docs | 17:49 |
| sean-k-mooney | so we are not realy able to say its supproted | 17:49 |
| gouthamr | ack | 17:50 |
| gouthamr | okay, i'll take an AI to get this process rolling.. in the ML post, i'll mention the integration with watcher.. | 17:50 |
| gouthamr | #link https://review.opendev.org/c/openstack/watcher/+/941828 | 17:51 |
| gouthamr | tkajinam possesses clairvoyance of sorts | 17:51 |
| gouthamr | ty for the call out here sean-k-mooney | 17:51 |
| gouthamr | anything else for $topic? | 17:51 |
| spotz[m] | Hehe | 17:52 |
| fungi | i think tkajinam lives in the future and sends his changes to the past for us to review | 17:52 |
| sean-k-mooney | we disucssed it at the ptg | 17:52 |
| sean-k-mooney | we wanted to servay all the integration and backend this cycle | 17:52 |
| sean-k-mooney | and understnd if we can supprot them and the level of testing | 17:52 |
| sean-k-mooney | so we could comunitte the realtiy of where watcher really is today | 17:53 |
| gouthamr | +1, i think this is a good effort! https://review.opendev.org/c/openstack/watcher/+/951699 | 17:53 |
| sean-k-mooney | so far the main output has been https://docs.openstack.org/watcher/latest/integrations/index.html#integration-status-matrix and https://docs.openstack.org/watcher/latest/strategies/index.html | 17:53 |
| gouthamr | ty | 17:54 |
| gouthamr | #topic A check on gate health | 17:54 |
| gouthamr | ^ any gate concerns/updates this week? | 17:54 |
| gmaan | one thing to mention | 17:55 |
| gmaan | gibi fix (one of the possible root cause) on grenade job DB dump timeout is merged, if anyone still seeing that, please report | 17:56 |
| gmaan | #link https://review.opendev.org/c/openstack/grenade/+/955865 | 17:56 |
| gmaan | we were seeing frequent timeout in grenade skip level job in last couple of week | 17:57 |
| cardoe | ah I'm totally late. | 17:57 |
| gouthamr | ack gmaan | 17:57 |
| gouthamr | cardoe: hello | 17:58 |
| sean-k-mooney | --skip-lock-tables makes sense in grenade | 17:58 |
| gouthamr | we have under a minute | 17:59 |
| gouthamr | so i'll skip to | 17:59 |
| gouthamr | #topic Open Discussion | 17:59 |
| gouthamr | just wanted to give a shoutout to the i18n interns, and their mentors ianychoi and seongsoo | 18:00 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/GGQAIF23Q3EEN5XRPZACM3E2FVLBQK26/ | 18:00 |
| gouthamr | 18:00 | |
| spotz[m] | Woot | 18:00 |
| gouthamr | pretty nice summary from ian there, i'd recommend reading it.. i think we'll keep up with the progress there, and finish the zuul integration soon (TM) | 18:01 |
| gouthamr | with that we're just over the hour.. | 18:01 |
| gouthamr | is there anything else you'd like to note in the minutes today? | 18:01 |
| gouthamr | thank you all for attending, and staying the extra few minutes.. | 18:03 |
| gouthamr | #endmeeting | 18:03 |
| opendevmeet | Meeting ended Tue Jul 29 18:03:02 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:03 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.html | 18:03 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.txt | 18:03 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.log.html | 18:03 |
| sean-k-mooney | gouthamr: os now that the meeting is over there two pain pont im aware of relating to ai and openstack. the first is just a lack of encodign the tribeal knowlage into somethign that easy for a operator or use to consume | 18:04 |
| sean-k-mooney | i.e. how to use the existing feature live vgpus or pci passhtough to provide ai acclerator to vms, or how to optimise the preformance | 18:04 |
| fungi | which is probably something the whitepaper could cover, but also might be worth integrating into project documentation somewhere | 18:06 |
| sean-k-mooney | the second oen is more nova specific. there are a number of perforamce optimisation that we leave on the table because we have not optimized nova to supprot them. thign like iothread and or how we virtualise the vm numa toplogy or pci groups. those are more technial pain point that go beyond ai usecases that we have not previously had tiem to prioritse but that i hope we can | 18:06 |
| sean-k-mooney | adress in teh future | 18:06 |
| sean-k-mooney | many of the feature we devleoped to optimsie nova for NFV/telco workload will help with ai workload too. like hugpages ectra | 18:08 |
| sean-k-mooney | the bit that is chalanging from my persective with the current lifecycle of openstakc is higher level abstractions | 18:08 |
| sean-k-mooney | if this was 10 year ago | 18:09 |
| sean-k-mooney | i coudl have seen a trove or magnum like project that did ai as a service | 18:09 |
| sean-k-mooney | today im not sure htat that is openstack domain and leaving that to k8s or soemthign else might make more sense | 18:09 |
| sean-k-mooney | liek with the rate fo ai devleopemtn im not sure buildign a proejct to provide remote mcp service as a service woudl actully make sesne | 18:11 |
| sean-k-mooney | with the size of the active contibotrs to the openstack comunity adn oure release cadace if feel liek some other proejct under opendev or linuxfoundation will have more of an impact | 18:13 |
| gouthamr | it might, I actually don’t know if we could build something today off of OSC/openstacksdk alone.. I mean you may want lower level things that services don’t expose via the API | 18:13 |
| sean-k-mooney | i think you can do alot today with the infra that hte openstack service provide | 18:14 |
| gouthamr | agree with using the Whitepaper as a venue to capture things in Nova that are being useful in this context | 18:14 |
| sean-k-mooney | belive it or not i think zun or cyborg coudl have a role in this story if there were folks workign to enable it | 18:15 |
| sean-k-mooney | nova too | 18:15 |
| gouthamr | maybe operators would tell us what other gaps exist, folks on the scientific SIG maintain infra for AI experiments - have you folks seen any RFEs from them? | 18:15 |
| sean-k-mooney | but in a diffent way | 18:15 |
| sean-k-mooney | yes and no, i can think of one which we approved as a spec | 18:16 |
| sean-k-mooney | btu they didnt have time to work on it | 18:16 |
| sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/2024.1/approved/pci-passthrough-groups.html | 18:16 |
| sean-k-mooney | that was motivated by both hpc and ai uscases | 18:17 |
| gouthamr | thanks, we can note this as future work and call for help… | 18:17 |
| sean-k-mooney | its technicaly possibel to do pci grouping in nova today with some abuse of our config file | 18:18 |
| sean-k-mooney | but its not easy. that proposal adress a lot of there pain point but they just dint have tiem to write the code | 18:18 |
| gouthamr | ack - I think they sought a Lustre backend in Manila too - would like someone to implement and maintain it | 18:20 |
| sean-k-mooney | i wrote an internal docuemtn describing the hack i probaly shoudl put that public somewhere if only as a blog | 18:21 |
| gouthamr | ++ | 18:22 |
| sean-k-mooney | i need to remove a coulpe of internal links and "osp refences" but i can try an put it on my block or share it in a etherpad or similar | 18:24 |
| fungi | bauzas: i'm told the plan is to record the call thursday too, so you can consume it after the fact if you like | 18:24 |
| gouthamr | sean-k-mooney: or if you’d like it on the superuser, diablo_rojo may be interested to collaborate | 18:25 |
| sean-k-mooney | im in too minds. the reason im not propsoing it ot the nova docs is im unsure if i want to encurrage peopel to do this | 18:26 |
| gouthamr | ah, is it based on stuff you don’t want to support? it’s likely someone may be using it already? | 18:27 |
| sean-k-mooney | the spec that we appeted but did not implement extis because it adresses the painpoint we have today in a much more elegent way | 18:27 |
| sean-k-mooney | it using a feature we fully supprot and will continue to suprpot in a way it was not inteded to use | 18:27 |
| sean-k-mooney | so the underlying mechanium is soudn and will continue ot be supproted its just intentally violateing oen fo oru best practices/rules to acive a diffent goal | 18:28 |
| gmaan | gouthamr, tc-members: commented on diversity things, please check if that makes sense https://review.opendev.org/c/openstack/governance/+/956024/comment/38ec51de_2bfa7735/ | 18:28 |
| sean-k-mooney | gouthamr: ist bascially a case of this https://www.youtube.com/watch?v=Nz8ssH7LiB0 | 18:30 |
| gouthamr | 😛 | 18:34 |
| gouthamr | thank you gmaan | 18:34 |
| TheJulia | I've also chimed in. | 18:44 |
| gouthamr | ty TheJulia | 18:44 |
| TheJulia | with many complex examples boiling down to direct employee/employer relationship being the only viable modeling | 18:44 |
| sean-k-mooney | i kind of feell like adding lots of examples for the edgecase is conter productive and it just come down ot . could someone percive a confilcit of interest or baias by your assocation that there for shoudl be disclosed as an affiliation | 18:54 |
| sean-k-mooney | most of the tiem that going to be i work for x | 18:54 |
| sean-k-mooney | very realy it might be im ethe cto and founder of x | 18:54 |
| sean-k-mooney | or x sponsered me to work on y for a perod of tiem btu goign into a lot of detial might actully obsucre the intent | 18:55 |
| sean-k-mooney | the intent being ot foster a diveristy of voicies in the tc | 18:55 |
| TheJulia | Absolutely, but it has to be in line with the employment agreement/contract, so if there is a rights transfer or whatever, then that is also respected. Trying to go further just creates clarity which is "clear as mud" because it is guessing intent/bias/affliation. | 18:56 |
| TheJulia | I know the amount was rooted way back in time from the early board of directors meetings | 18:57 |
| TheJulia | like... 2012 timeframe. | 18:57 |
| sean-k-mooney | i dont think the ammoutn shoudl be in the defintion espcially now that we under the linux foundation and not a seperate 501 c charity or delaware coperation | 18:58 |
| sean-k-mooney | whatever it was leagallybefore | 18:58 |
| TheJulia | I don't know the root of that at this point since it was so far in the past, but the example even then sort of crates this weird corner case which also sort of begins to create this other case we then feel the need to account for | 18:58 |
| TheJulia | Well, for the purposes of this, all 501(c)s are not for profit corporations, charity is just shorthand ;) | 18:58 |
| TheJulia | that has varying legal meaning depending on context, though. | 18:59 |
| sean-k-mooney | ya | 18:59 |
| TheJulia | I think the amount needs to be dropped. | 18:59 |
| sean-k-mooney | i undersand the delta but i dont feell like typing it out :) and i agree i dont think amount really shoudl be here unless legally requried to be there | 18:59 |
| TheJulia | It breaks my brain since that is... below cost of living in some parts of the world. | 18:59 |
| TheJulia | I don't see why it would be but also in those days there *was* a huge engagement of third parties to help move stuff upstream | 19:00 |
| TheJulia | now, that is not really a thing as far as I'm aware. | 19:00 |
| TheJulia | Anyway, I need to go eat something for lunch | 19:01 |
| sean-k-mooney | well 60,000 usd is above the average irish sallary (in no tech industires) | 19:01 |
| fungi | "charity" typically refers to 501(c)(3) in usa tax code, openinfra was (and lf is) a 501(c)(6) non-profit, similar to a "trade organization" | 19:03 |
| TheJulia | Yeah, economies and costs are different all over the place | 19:03 |
| TheJulia | fungi: indeed :) | 19:03 |
| fungi | (6) member fees can be written off as business expenses in the usa, but (3) donations are tax deductible in the usa | 19:04 |
| TheJulia | but even then, (c)(3)'s are "for the public good", where as (c)(6) for member mutual benefit | 19:04 |
| fungi | fairly significant distinction from the donor/member cost perspective anyway | 19:04 |
| TheJulia | yeah | 19:04 |
| fungi | right | 19:04 |
| TheJulia | Anyway, I'm going to get some lunch | 19:04 |
| sean-k-mooney | i woudl like to think we srive for both public good and benifit of our users | 19:04 |
| fungi | so software in the public interest is a (c)(3) for example | 19:05 |
| TheJulia | sean-k-mooney: Yeah, that is a topic which makes some people get very sad actually :( | 19:05 |
| TheJulia | (since there was an attempt to get a ruling for (c)(3) at one point) | 19:05 |
| TheJulia | (but then also, members!) | 19:05 |
| fungi | we originally wanted to be organized as a charity, but the usa irs made it virtually impoossible for new software foundations to qualify, so for example spi is grandfathered in and probably wouldn't be able to get it if applying today | 19:06 |
| TheJulia | yup | 19:07 |
| spotz[m] | Going back to the $ affiliation comment above, that's part of the reason I grabbed from the bylaws the section I did as $$ all depends on where you live:( | 19:12 |
| clarkb | why not make it as simple as "you've been paid by the entitiy within the last 2 months" or something along those lines | 19:14 |
| clarkb | make it simple | 19:14 |
| clarkb | then keep the bit about equity/ownership/leadership for orgs that don't necessarily pay a salary or contracts | 19:14 |
| * gouthamr didn't include payment in the proposal | 19:15 | |
| clarkb | gouthamr: oh cool not sure where it came from above then | 19:15 |
| gouthamr | i understood it as discussing the erstwhile foundation bylaws | 19:16 |
| gouthamr | i have noted only opposition to any mention of salart/pay so far.. | 19:16 |
| clarkb | ack | 19:17 |
| TheJulia | $0.02, I'd avoid a time window as in paid in, just more so is there an active relationship or not. That sort of steps away from the whole problem of modeling payroll or compensation for work being performed | 20:13 |
| ianychoi | <gouthamr> "just wanted to give a shoutout..." <- Thank you for your kind support. Also, appreciate diablo_rojo to liaise to introduce students. This mention recalls me thanks bot, so let me call for Seongsoo | 23:59 |
| ianychoi | #thanks seongsoocho Thank you for your active mentoring of CMU students despite the time zone differences. Keep up the great work on the I18n and Weblate migration! | 23:59 |
| ianychoi | Seems not working now :p | 23:59 |
| opendevstatus | ianychoi: Added your thanks to Thanks page (https://wiki.openstack.org/wiki/Thanks) | 23:59 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!