| *** mchlumsky7 is now known as mchlumsky | 03:04 | |
| *** akahat is now known as akahat|ruck | 06:47 | |
| *** akahat is now known as akahat|ruck | 10:08 | |
| *** dasm|off is now known as dasm | 13:03 | |
| fungi | tc-members: when you get a moment, please see the announcement i just sent to openstack-discuss about arranging a joint discussion with foundation board members: https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029352.html | 14:25 |
|---|---|---|
| *** diablo_rojo__ is now known as diablo_rojo | 14:39 | |
| frickler | fungi: is the OIF board involved in the decision about the format of PTGs? /me is wondering whether that would be a suitable topic | 14:42 |
| gmann | frickler I think that is more a question to foundation than Board. | 14:42 |
| gmann | Board is not much involved in event format/planning. But I think we discussed somewhere to have the community feedback on PTG format change from virtual to physical but I think that did not happen | 14:43 |
| diablo_rojo | They are going to alternate. | 14:45 |
| diablo_rojo | So the next one will be in person and then virtual | 14:45 |
| diablo_rojo | and so on | 14:45 |
| frickler | diablo_rojo: I would like to understand who decides this and what is the reasoning behind it. it doesn't seem to align with the wishes of much of the community I have talked to | 14:46 |
| frickler | e.g. kolla will now have to organize their own virtual sessions in order to plan the next cycle | 14:47 |
| fungi | frickler: as noted, ptg planning is basically left up to the event organizers at the foundation, though the board does officially govern the foundation staff they tend to stay out of decisions like that for the most part | 14:47 |
| diablo_rojo | frickler, oh okay. I can find you a contact email. I think it comes down to perspective though too. I have talked to just as many people that want to go back to in person as those that want it to be virtual. | 14:48 |
| fungi | thankfully, organizing virtual collaboration doesn't need nearly as much advance preparation as an in-person event | 14:49 |
| diablo_rojo | frickler, ptg@openinfra.dev sounds like a good place to get your questions answered. | 14:50 |
| fungi | but based on past experiences, i do think specific discussions should either be mostly in-person or mostly online, trying to do a 50/50 hybrid with some participants in the same room and others on conference call has tended not to work out so well | 14:50 |
| gmann | diablo_rojo: is there any feedback etherpad or ML etc discussion where people wanted physical PTG? as much as I see there was no such discussion happened in community | 14:50 |
| diablo_rojo | gmann, it was mostly conversations in Berlin about how much more work people got done together in person and that they were looking forward to getting back to in person PTGs | 14:51 |
| frickler | fungi: I 100% agree that mixed isn't a better option, that's why I am talking about virtual only | 14:51 |
| gmann | but yes, it is not TC things too , I think foundation ptg ML is good place to raise this. | 14:51 |
| fungi | granted, that feedback has a significant and obvious selection bias (people attending an in-person event talking about attending in-person events) | 14:51 |
| frickler | diablo_rojo: well talking to people at an in-person meeting obviously has a certain implicit bias | 14:51 |
| gmann | diablo_rojo: but i think physical PTG was already decided before berlin | 14:52 |
| diablo_rojo | fungi, totally it takes a very certain team culture to make hybrid work. | 14:52 |
| diablo_rojo | frickler, totally makes sense. Simultaneously, I would say the same about exclusively working remotely and having conversations virtually? People are more likely to be biased towards that? | 14:52 |
| fungi | putting together an in-person event takes so much advance planning and preparation, organizing venues and so on, that it has to be started long before the organizers can really know whether people will be able to attend | 14:53 |
| gmann | that is why ML or asking both togehter can be good place | 14:53 |
| diablo_rojo | fungi, - also a very good point | 14:53 |
| frickler | gmann: regarding not TC topic, I don't agree. it should be the focus of the TC to ensure good collaboration options in the OpenStack community. and excluding people not willing or able to travel from important parts of that collaboration is something the TC could (and IMO should) be able to have an opinion on and voice it | 14:55 |
| diablo_rojo | Teams are not being forced to participate in the PTG (virtual or in person). Its up to the team to decide if they want to participate. We can't effectively decide whats best for every team because they are all so different. | 14:56 |
| diablo_rojo | Moreover, the PTG isn't just for OpenStack anymore, it includes the other OpenInfra projects now too. | 14:56 |
| gmann | frickler: I mean we in TC do not control the event but yeah we can raise the voice. | 14:56 |
| dansmith | frickler: ++ for virtual only | 14:58 |
| gmann | frickler: I will add it for board interaction meeting and that is not just for TC to attend, we (TC and board) encourage other community member also to join | 14:59 |
| gmann | anyways TC meeting time | 14:59 |
| dansmith | frickler: I was surprised not to see a poll before announcing it as in-person this time | 15:00 |
| gmann | that is what i was expecting and we talked about it in tc channel and ohter place too | 15:00 |
| dansmith | I know a lot of people want in-person, but at least this contributor will have to make a tough decision now | 15:00 |
| gmann | #startmeeting tc | 15:00 |
| opendevmeet | Meeting started Thu Jun 30 15:00:45 2022 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'tc' | 15:00 |
| gmann | tc-members meeting time | 15:00 |
| gmann | #topic Roll call | 15:01 |
| gmann | o/ | 15:01 |
| slaweq | o/ | 15:01 |
| dansmith | o/ | 15:01 |
| dpawlik | o/ | 15:01 |
| diablo_rojo | o/ | 15:01 |
| jungleboyj | o/ | 15:02 |
| jungleboyj | I am not sure about other people but I don't see travel being allowed for me anytime soon. | 15:03 |
| spotz | o/ | 15:03 |
| arne_wiebalck | o/ | 15:03 |
| gmann | ohk. let's discuss it at the end | 15:03 |
| gmann | #link #https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 15:03 |
| gmann | today ^^ agenda | 15:04 |
| gmann | Follow up on past action items | 15:04 |
| gmann | gmann to add c9s testing collaboration topic in next meeting agenda and call c9s folks to help it to make stable distro to test in OpenStack | 15:04 |
| gmann | I did nto get time to do this, too many things this week. | 15:04 |
| gmann | I will re-add it and make sure next call we will discuss it with c9s folks | 15:04 |
| gmann | #action gmann to add c9s testing collaboration topic in next meeting agenda and call c9s folks to help it to make stable distro to test in OpenStack | 15:04 |
| gmann | slaweq to send the recheck data on ML asking projects doing more bare recheck to start working on it | 15:04 |
| gmann | slaweq: sent email #link http://lists.openstack.org/pipermail/openstack-discuss/2022-June/029342.html | 15:05 |
| dansmith | done, just in the nick of time ;) | 15:05 |
| gmann | +1 | 15:05 |
| gmann | and we will discuss about recheck things in gate health topic | 15:05 |
| gmann | thanks slaweq for sending | 15:05 |
| gmann | arne_wiebalck to check with stephen and artem about driving the OSC work as popup team or any other dedicated group way | 15:05 |
| slaweq | yw | 15:05 |
| gmann | arne_wiebalck: any update ^^ | 15:05 |
| slaweq | now the data should be accurate (I hope at least) | 15:06 |
| slaweq | at least it was good for various patches which I was checking today | 15:06 |
| arne_wiebalck | there was no reply yet, I sent the mail | 15:06 |
| arne_wiebalck | dansmith & diablo_rojo should have received a copy ... otherwise I did not send it :-/ | 15:07 |
| dansmith | I received it | 15:07 |
| arne_wiebalck | dansmith: thx | 15:07 |
| knikolla | o/ | 15:07 |
| gmann | ok | 15:08 |
| diablo_rojo | I saw it @arne_wiebalck ! | 15:08 |
| gmann | let's wait then | 15:08 |
| gmann | arne_wiebalck: should we continue the same action item or you want to proceed in other way like adding separate topic or so? | 15:08 |
| gmann | or just track it as part of zed tracker? | 15:08 |
| arne_wiebalck | zed tracker is fine I think | 15:09 |
| gmann | cool | 15:09 |
| arne_wiebalck | I will keep it updated | 15:09 |
| gmann | arne_wiebalck: thanks | 15:09 |
| gmann | #topic Gate health check | 15:10 |
| gmann | any news on gate before we discuss recheck things | 15:10 |
| dansmith | I don't have anything specific, but I think ade_lee fixed the fips job problem | 15:10 |
| dansmith | the nslookup thing.. the patch merged at least, and I think at least glance has another patch we need to merge for the periodic job | 15:11 |
| slaweq | yesterday we saw some rally issue in the neutron gates | 15:11 |
| dpawlik | I propose a patch to fix fields in performance.json in Opensearch, so it should provide more information | 15:11 |
| slaweq | I'm not sure if other rally jobs are broken also but I guess they can be | 15:11 |
| gmann | dpawlik: +1 thanks | 15:12 |
| gmann | I also have not seen any frequent failure | 15:12 |
| gmann | slaweq: not sure about rally, I hardly see any rally job in the projects I usually push patches | 15:13 |
| slaweq | here is bug reported https://bugs.launchpad.net/neutron/+bug/1980055 | 15:13 |
| slaweq | and patch seems to be in gate now https://review.opendev.org/c/openstack/rally-openstack/+/847879 | 15:13 |
| gmann | +1 | 15:13 |
| gmann | Bare 'recheck' state | 15:14 |
| gmann | #link https://etherpad.opendev.org/p/recheck-weekly-summary | 15:14 |
| gmann | slaweq: go ahead | 15:14 |
| gmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2022-June/029342.html | 15:14 |
| gmann | if anything you would like to highlight | 15:14 |
| slaweq | it seems that there is many "bare" rechecks done in most of the teams | 15:14 |
| gmann | yeah, I added to monitor this in QA meeting | 15:15 |
| slaweq | I don't think there is anything to highlight there now, I think we should try to share that data with the teams and see in time if that will improve | 15:15 |
| gmann | I will add it for tacker and horizon also as it is 100% bare recheck for them | 15:15 |
| slaweq | I will be regulary checking and reporting it in neutron team's meeting too | 15:16 |
| gmann | +1 | 15:16 |
| gmann | slaweq: plan is to post it on ML also every week right? | 15:16 |
| gmann | just making sure that is what we decided in last meeting not just only initial email | 15:16 |
| slaweq | gmann: I can do that every Thursday, before TC meeting | 15:16 |
| jungleboyj | slaweq: ++ | 15:17 |
| fungi | i found it interesting that there were only two teams below the 50% mark in the list | 15:17 |
| gmann | sounds good, that can help to get attention from projects | 15:17 |
| clarkb | one thing that occured to me from that thread is what we seem to be concerend about is a lack of culture around quality. | 15:17 |
| gmann | slaweq: thanks for doing it | 15:17 |
| clarkb | I wonder if we shouldn't try and reframe the discussion around that over time (add more metrics etc) | 15:18 |
| clarkb | (this is a great start!) | 15:18 |
| slaweq | clarkb: I would love to add more metrics, if You have any ideas about such, please let me know | 15:18 |
| slaweq | I will be happy to improve all of that | 15:18 |
| gmann | yeah, let's see how it goes and if we can build culture of no bare recheck and know the failure firt | 15:18 |
| gmann | that can be good first step | 15:19 |
| slaweq | ++ | 15:19 |
| jungleboyj | ++ | 15:20 |
| spotz | ++ | 15:20 |
| gmann | anything else on gate health | 15:21 |
| gmann | #topic New ELK service dashboard: e-r service | 15:22 |
| gmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028346.html | 15:22 |
| gmann | #link https://opensearch.logs.openstack.org/_dashboards/app/login?nextUrl=%2F_dashboards%2Fapp%2Fdiscover%3Fsecurity_tenant%3Dglobal | 15:22 |
| gmann | dpawlik: any updates on this | 15:22 |
| dpawlik | gmann: nothing important. Working on pushing container images with "latest" tag to the docker registry | 15:23 |
| gmann | this is to merge the rdo and master branch or elastic-recheck repo #link https://review.opendev.org/c/opendev/elastic-recheck/+/847405/ | 15:23 |
| gmann | dpawlik: thanks, | 15:23 |
| dpawlik | added a prometheus exporter to get some metrics to count metrics | 15:23 |
| dpawlik | to estimate space on Opensearch | 15:23 |
| dpawlik | created the performance- index, soon it will be recreated when https://review.opendev.org/c/openstack/ci-log-processing/+/848218 is merged | 15:24 |
| dpawlik | that's all | 15:24 |
| gmann | +1 | 15:24 |
| gmann | dpawlik: as we have good progress in this part, do you want to keep it in TC meeting topic or work/track as part of TaCT SIG? | 15:25 |
| dpawlik | about elasticsearch recheck, dasm I guess is working on adding authentication to the Opensearch, but I can be wrong | 15:25 |
| dpawlik | we can remove from TC meetings | 15:25 |
| clarkb | elastich-recheck shouldn't need more than anonymous access. I don't think those two things are related | 15:25 |
| fungi | out of curiosity, why is opensearch authentication needed for elastic-recheck to perform queries? | 15:26 |
| clarkb | or maybe you mean e-r needs to be updated to do the "anonymous" RO auth | 15:26 |
| dpawlik | clarkb: yeah, but anonymous access in opensearch = disable security plugin | 15:26 |
| gmann | sure, I will remove it from next meeting agenda and if you feel anything from TC you need you can ping us here | 15:26 |
| fungi | right, to know to use the openstack/openstack login | 15:26 |
| fungi | okay, that makes sense, thanks! | 15:26 |
| gmann | #topic RBAC community-wide goal | 15:27 |
| gmann | #link https://etherpad.opendev.org/p/rbac-zed-ptg#L171 | 15:28 |
| gmann | #link http://lists.openstack.org/pipermail/openstack-discuss/2022-June/029324.html | 15:28 |
| gmann | ^^ we had the policy popup meeting on tuesday and agreed on the direction mentioned in email | 15:28 |
| gmann | proposed the same in goal document update #link https://review.opendev.org/c/openstack/governance/+/847418 | 15:29 |
| dansmith | lots of discussion there, but seems like we're converging on agreement | 15:29 |
| gmann | idea is to postponed the 'scope' implementation and finsih project persona first. that is what operator want | 15:29 |
| gmann | yeah, please check the review if you are interested to help or get the overall direction | 15:29 |
| slaweq | and change "project_admin" into "admin" like it in legacy rules IIUC | 15:30 |
| slaweq | *like it is in legacy ... | 15:30 |
| gmann | slaweq: yes, good point, overall keep legacy admin same way it was | 15:30 |
| fungi | how does that square with the previous discussions to get rid of the word "admin" since it's misleading and has been a consistent source of confusion for users/operators? | 15:31 |
| gmann | overall, do the project persona with project reader which is phase 1 first | 15:31 |
| dansmith | fungi: those discussions settled on admin being actual admin, and not re-using that for lesser customer-type admins | 15:31 |
| dansmith | since we're just keeping the old admin, I think we 're square | 15:32 |
| gmann | yeah and for project level admin work, we will have project manager but in phase 3 | 15:32 |
| fungi | okay, so "admin" will mean global admin, but won't be allowed for project-level role names | 15:32 |
| gmann | fungi: project-level role names? you mean no more 'project-admin' and only single admin? | 15:33 |
| knikolla | that's what "manager" will be for, IIRC. | 15:33 |
| gmann | yeah | 15:33 |
| gmann | basicallly admin, project-manager, project-member, project-reader | 15:34 |
| fungi | the confusion which has resulted in security mishaps for users so far is creating an "admin" role in a project, and not realizing that users in that role got access outside that project | 15:34 |
| gmann | admin here is same thing we have already so no change in that name or its behavior | 15:34 |
| gmann | fungi: yeah, project-manager should solve that | 15:35 |
| knikolla | keystone has a keystone-doctor CLI that we could use to warn operators if they're unwillingly granting admin on users in more than one project | 15:35 |
| knikolla | unwittingly* | 15:35 |
| gmann | https://review.opendev.org/c/openstack/governance/+/847418/6/goals/selected/consistent-and-secure-rbac.rst#538 | 15:35 |
| fungi | that sounds helpful | 15:35 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/847418/6/goals/selected/consistent-and-secure-rbac.rst#538 | 15:36 |
| gmann | that is all on this and we request to review the proposed direction | 15:36 |
| gmann | dansmith: anything else from your side on RBAC? | 15:37 |
| dansmith | nope | 15:37 |
| gmann | ok | 15:37 |
| gmann | #topic Create the Environmental Sustainability SIG | 15:37 |
| gmann | #link https://review.opendev.org/c/openstack/governance-sigs/+/845336 | 15:37 |
| gmann | we discussed it in last meeting also | 15:37 |
| diablo_rojo | I haven't seen any new folks pipe up on the review | 15:38 |
| diablo_rojo | I will keep pushing on that. | 15:38 |
| gmann | I think from review from other member also, it should be openinfra level | 15:38 |
| gmann | diablo_rojo: or you are looking for more feedback ? | 15:38 |
| knikolla | a good topic to bring with the board then? | 15:38 |
| jungleboyj | diablo_rojo: Yeah, a few people have made comments. | 15:38 |
| diablo_rojo | gmann, yes, from the people that are interested in paricipating | 15:39 |
| diablo_rojo | jungleboyj, but almost none from the larger list of users and operators from berlin that signed up to participate | 15:39 |
| jungleboyj | Ah. :-) | 15:39 |
| diablo_rojo | I am working on getting them setup on Gerrit and IRC | 15:39 |
| jungleboyj | Good point. :-) | 15:39 |
| gmann | knikolla: humm i think we as SIG volunteer and TC can decide first, and if we agree to go as board workjng grouo then yes baord can discuss | 15:39 |
| spotz | Maybe not the board but reach out to the community managers and leads for visibility for input | 15:39 |
| diablo_rojo | so that we can actually collaborate :) | 15:39 |
| jungleboyj | diablo_rojo: Details, details. ;-) | 15:39 |
| gmann | diablo_rojo: TheJulia replied on that i think | 15:39 |
| knikolla | makes sense | 15:40 |
| diablo_rojo | jungleboyj, the devil is in the details ;) | 15:40 |
| * diablo_rojo waves from details | 15:40 | |
| * jungleboyj laughs | 15:40 | |
| diablo_rojo | gmann, yes but there are close to 30 other people I think that also want to be involved that havent spoken up yet | 15:40 |
| diablo_rojo | jungleboyj, :) | 15:40 |
| diablo_rojo | So at this point, I think we should hold off on anything until they reply on the review. | 15:41 |
| gmann | diablo_rojo: I will suggest to hold on the IRC, other infra setup or so until we decide where we will start this effort. l | 15:41 |
| diablo_rojo | At least a couple of the,. | 15:41 |
| gmann | diablo_rojo: you are assuming all those 30 or even half will be part of this SIG/group ? | 15:41 |
| diablo_rojo | gmann, fair. I don't need to setup a channel yet, but they should still get on IRC as we will want to communicate there eventually | 15:41 |
| diablo_rojo | gmann, yes I am | 15:42 |
| diablo_rojo | I really hope it doesn't come down to just TheJulia and I. | 15:42 |
| gmann | +1, good. | 15:42 |
| gmann | diablo_rojo: so how you want to proceed, expecting gerrit reply from all 30 seems like difficult to happen. | 15:42 |
| gmann | or you want to wait if majority or it reply and then discuss in TC if needed | 15:43 |
| gmann | anything ok for me | 15:44 |
| knikolla | diablo_rojo: i'm definitely interested, though I see a lot more value that this can bring on a OpenInfra / OpenDev level rather than just OpenStack :) | 15:44 |
| diablo_rojo | gmann, I wasn't expecting ALL of them to reply there | 15:44 |
| diablo_rojo | If I could get 3-5 even that would be great. | 15:44 |
| gmann | knikolla: also please add your feedback in gerrit too | 15:44 |
| gmann | sure | 15:44 |
| knikolla | (make pizza in the next ops meeting contingent on a review there, haha) | 15:45 |
| diablo_rojo | knikolla, I do too! I just think OpenStack is where the most knowledge is and so its a good place to start | 15:45 |
| fungi | knikolla: i'm definitely interested in what ways you see the opendev collaboratory as getting involved | 15:45 |
| gmann | diablo_rojo: let's wait then and we can add this topic again in TC meeting or i can keep it in agenda if you want | 15:45 |
| diablo_rojo | I think we, as a project have a problem with starting too big with too much admin and redtape and process. | 15:45 |
| fungi | since we're just consumers of infrastructure, i'm not sure where we fit, but happy to discuss after the meeting | 15:45 |
| gmann | knikolla: this review #link https://review.opendev.org/c/openstack/governance-sigs/+/845336 | 15:46 |
| diablo_rojo | gmann, I can add the topic when we are at a place to discuss here again | 15:46 |
| knikolla | fungi: sure, i'm happy to share a few rough ideas | 15:46 |
| diablo_rojo | if you want to take it off the agenda for now | 15:46 |
| gmann | diablo_rojo: thanks, I will keep it in next week at least and then remove if no progress so that we can add when it is ready or so | 15:47 |
| diablo_rojo | Okay. | 15:47 |
| gmann | diablo_rojo: thanks | 15:47 |
| gmann | #topic Open Reviews | 15:47 |
| gmann | #link https://review.opendev.org/q/projects:openstack/governance+is:open | 15:48 |
| gmann | I approved the tact sig patch | 15:48 |
| gmann | other than that we have discussed most of them or all | 15:48 |
| jungleboyj | \o/ | 15:49 |
| gmann | except this #link https://review.opendev.org/c/openstack/governance/+/836888 | 15:49 |
| gmann | jungleboyj: ^^ is it ready to review but still it is WIP | 15:49 |
| jungleboyj | Yeah, that is blocked on me finishing that. | 15:49 |
| jungleboyj | And looking at the comments. | 15:49 |
| gmann | ohk. | 15:49 |
| jungleboyj | I will carve out some time on that. | 15:50 |
| gmann | jungleboyj: thanks | 15:50 |
| gmann | not in agenda but good to point out here | 15:50 |
| gmann | as most of you know, in board we are starting the openinfra project interaction on regular basis so that project and board know each other and discuss the updates/issues on regular basis | 15:51 |
| gmann | apart from the OpenStack Updates in berlin board meeting, board is starting the next call and there will be more regular call in future | 15:51 |
| diablo_rojo | 5th and 12th of July | 15:52 |
| gmann | Board is communicating via foundation community manager to all the infra project including OpenStack, and you might have seen the email from fungi #link https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029352.html | 15:52 |
| opendevreview | Merged openstack/governance-sigs master: tact-sig: Simplify OpenSearch mention https://review.opendev.org/c/openstack/governance-sigs/+/847017 | 15:52 |
| diablo_rojo | Err wait thats something else | 15:52 |
| diablo_rojo | I think | 15:52 |
| gmann | diablo_rojo: no that is separate call | 15:52 |
| diablo_rojo | nvm | 15:52 |
| gmann | that is board informal strategic discussion | 15:53 |
| gmann | this is direct interaction with OpenStack and board | 15:53 |
| gmann | from OpenStack side it can be TC memebrs as well as community members | 15:53 |
| fungi | yeah, i picked the middle two weeks of august as options to give us some flexibility and time to coordinate schedules | 15:54 |
| gmann | two action item for us: | 15:54 |
| gmann | 1. vote on timing #link https://framadate.org/atdFRM8YeUtauSgC | 15:54 |
| gmann | 2. add topic in etherpad #link https://etherpad.opendev.org/p/2022-08-board-openstack-sync | 15:54 |
| gmann | tc-members: please do and asking the same in community member is already on ML | 15:55 |
| fungi | my biggest concern with timing is that july and august are prime vacation/holiday time in europe, but i didn't want to put it off until september | 15:55 |
| diablo_rojo | Oh to live in Europe :) | 15:55 |
| gmann | I will add this as a separate topic in next week meeting so that we can finish both things to let board send the meeting details | 15:55 |
| spotz | hehe | 15:55 |
| knikolla | oh yeah, especially first 2 weeks of august. | 15:55 |
| fungi | at least focusing on mid-week days we'll hopefully dodge weekend-adjacent holidays | 15:56 |
| spotz | +1 | 15:56 |
| gmann | fungi: sooner is ok and we will continue the next call on regular basis so we may have another one later | 15:56 |
| fungi | yes, the idea is to have one of these every few months | 15:56 |
| dansmith | with only three votes we're already down to a pretty small window | 15:56 |
| slaweq | fungi AFAIK in many countries 15th Aug is also bank holiday | 15:57 |
| gmann | not every month exactly but we as Board want to be frequent based on how it goes | 15:57 |
| fungi | slaweq: yep, i didn't include the 15th (it's a monday anyway) | 15:57 |
| slaweq | e.g. in Red Hat we will also have Friday 12th Aug off (Recharge day) it's "tricky time" I would say | 15:57 |
| jungleboyj | He he. European Summer. I have one co-worker leaving for 2 weeks. Another for a month! | 15:57 |
| gmann | let's add availability and based the availability we will discuss in next meeting if we want another date than proposed in poll | 15:57 |
| slaweq | fungi I know, just saying :) | 15:58 |
| fungi | same reason i skipped fridays ;) | 15:58 |
| gmann | and from Board side, it will be all the board will attend this, it will be who all are interested will join | 15:58 |
| jungleboyj | ++ | 15:58 |
| gmann | that is all from my side for today meeting. anything else? | 15:58 |
| gmann | 2 min left though | 15:58 |
| gmann | thanks fungi for sending it on ML | 15:59 |
| fungi | yes, the hope is to have some tc members and some board members discuss things (and people taking notes and summarizing to the ml) | 15:59 |
| gmann | let's close and reminder that next call will be video call on 7th July | 15:59 |
| gmann | fungi: +1 | 15:59 |
| slaweq | \o | 15:59 |
| gmann | thanks everyone for joining | 16:00 |
| gmann | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Thu Jun 30 16:00:04 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-30-15.00.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-30-15.00.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-30-15.00.log.html | 16:00 |
| jungleboyj | Sounds good. Thank you! | 16:00 |
| diablo_rojo | Thank you. | 16:00 |
| spotz | Thanks gmann everyone | 16:00 |
| knikolla | fungi: with regards to environmental sustainability, CI/CD is a significant factor and and opendev provides CI, and zuul is also an openinfra project. so it seems like a great opportunity to do something and be first consumers of it. | 16:06 |
| clarkb | Nodepool is already an on demand system :) (though it talks to things that may have varying levels of upness to supply the demand) | 16:07 |
| fungi | knikolla: that's a great point, thanks! and yes, considering we do a lot to try and optimize for efficient and responsible use of the resources donated to us, it does make sense | 16:09 |
| knikolla | Agree. And while we don't have any say on how our jobs are run, we can attempt to do some measurements/studies based on the amount of infrastructure we consume and its impact. | 16:09 |
| knikolla | By having Zuul expose that, people who use Zuul for their own CI would also get that data based on their infrastructure. | 16:10 |
| fungi | we walk a fine line between conservation of resources and trying to prioritize human efficiency over systems efficiency | 16:10 |
| clarkb | fwiw zuul does already expose quite a bit of that | 16:10 |
| clarkb | https://grafana.opendev.org/d/94891e7b01/resource-usage-by-tenants-and-projects?orgId=1 is a super high level view into that | 16:10 |
| knikolla | clarkb: thanks for sharing that. that's extremely helpful! | 16:13 |
| knikolla | I'm looking at the other dashboard as well, fantastic work! We could use the information about instances, their instance types, and where they're running (what type of energy powers them and they require) and put that together into some insights about energy use, etc. | 16:17 |
| fungi | yes, if we could get that information from the donors, we could probably factor it in | 16:21 |
| fungi | i expect we can get at least some of them to tell us, and then try to make educated guesses about the others based on that | 16:21 |
| fungi | if those donors are also participating in the sig, then they have a clear impetus to offer up that info | 16:22 |
| knikolla | and if downstream zuul operators deploy their own zuul, that information might feed into them as well (being the same cloud (?)), though I imagine a bill will have the same effect for them to lower their impact, haha. | 16:24 |
| fungi | a lot of zuul deployments use private/on-prem clouds, but in those cases it's probably even easier for them to get the data | 16:25 |
| knikolla | true, though in those cases there will be an organization separation between the developer writing zuul jobs, and the operator maintaining the hardware. | 16:26 |
| knikolla | it might help to have the developer have visibility into things they wouldn't have otherwise considered, such as energy use due to treating the data center as unlimited. | 16:26 |
| knikolla | (ex: the number on non-voting failing jobs in this project is equal to 2 racks of hardware being fully utilized all the time * energy consumption) | 16:28 |
| fungi | "the cost to the company of non-voting failing jobs in this project exceeds your salary" | 16:29 |
| gmann | :) | 16:29 |
| clarkb | this also touches on my comments about restoring a culture of quality. I think what bugs me most about resource waste is that it could be leveraged in a non wasteful way with a little extra effort | 16:30 |
| knikolla | hahaha, tie that into git blame, and then "the environment impact of your broken code is equal to a boeing 747 circumnavigating the globe twice" | 16:31 |
| clarkb | and if you do that you take wasted resources and turn them into a powerful tool | 16:31 |
| gmann | knikolla: all these are great point/ideas I think, I am not sure there is any documents/repo is started for Environment group but good to record these somewhere so that these does not go unnoticed here . may be in review https://review.opendev.org/c/openstack/governance-sigs/+/845336 or in https://wiki.openstack.org/wiki/Environmental_Sustainability_SIG ? | 16:31 |
| fungi | i'm starting to think i don't want to know what the environmental impact of all my broken code has been over the years :/ | 16:32 |
| clarkb | sometimes that will mean deleting jobs and marking features as unsupported. Others it will involve fixing bugs that affect every openstack production deployment further multiplying the problem. Sometimes it will involve improving base performance again multiplying impact | 16:32 |
| fungi | note that if you want a landing page for a sig, you can do like i did for the tact sig and just serve it on the governance site, with a simple file in the governance-sigs repo | 16:33 |
| knikolla | great points. i think there's two threads here which i'll try to summarize. 1) is by collecting energy usage for CI resources we can provide visibility and hopefully incentives for cloud operators to prioritize turning those resources into sustainable resources. 2) by providing insights into what might be wasteful usage, to highlight the problem, which people ordering new hardware may not be aware of | 16:35 |
| clarkb | then when python3.11 becomes our platform we get a 40% improvement for free >_> | 16:36 |
| clarkb | it might actually be worth doing some sort of audit of the code bases to make them python3.11 friendly to get the most out of the perofmrance improvements there | 16:36 |
| dansmith | I'm looking forward to python for workgroups | 16:38 |
| knikolla | lol | 16:38 |
| knikolla | I still have a few CDs somewhere | 16:38 |
| dansmith | I totally do | 16:38 |
| dansmith | I also have my OS/2 2.1 on 5.25" floppies | 16:38 |
| knikolla | clarkb: the message that Devstack now prints out about time saved is fascinating and this reminded me of that. | 16:40 |
| fungi | dansmith: yes, that's exactly what runs through my head every time i test my personal projects with 3.11 prereleases | 16:42 |
| * dansmith nods | 16:42 | |
| clarkb | knikolla: re devstack we can cut down on significant runtime by not using osc, but I know that has been a hard sell in the past | 16:42 |
| fungi | for my stuff, where i run identical tests against a series of python versions compiled the same way on the same platform, i've been tracking timing differences and there definitely has been an incremental improvement in runtime | 16:43 |
| clarkb | fungi: apparently you get the most benefit if your classes don't change "shape" over time | 16:43 |
| fungi | not just in 3.11, but each minor python release seems to have added some efficiency over the ones before | 16:44 |
| clarkb | this means setting attributes and methods upfront and not changing their types over time | 16:44 |
| clarkb | in those cases the updated interpreter cheats and does fewer checks that things haven't changed between now and the last time it interacted with the objects | 16:44 |
| fungi | yeah, i've put zero effort into tuning my code to take advantage of optimizations in the interpreter, just observing gradual decrease in runtime from one version to the next for the same code on the same platform | 16:44 |
| knikolla | i feel like a monster now, standing up a vm to run tests locally in a container, deployed within kubernetes, inside of a vm and then destroying it all thereafter. what gradual performance improvement? haha | 16:46 |
| fungi | the real trick is in figuring out at what point you're spending more energy running tests than you're conserving by putting out more efficient, less bug-ridden software ;) | 16:47 |
| gmann | spotz: can you help me to connect or you can connect/give some CentOS stream maintainers names. TC need to have a call together with them on CentOS stream 9 testing stability and collaboration. | 16:48 |
| gmann | spotz: I have added this topic in our next week meeting https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 16:48 |
| clarkb | gmann: https://fedoraproject.org/wiki/User:Bookwar | 16:49 |
| dansmith | I think also apevec would be a good person to poke | 16:49 |
| fungi | bookwar is who was providing us with a lot of process insight during the forum sessions | 16:58 |
| knikolla | fungi: i feel like that would still be less than the aggregate consumption of electron apps that my computer suffers through on a daily bases | 17:40 |
| clarkb | knikolla: weeslack works pretty well. Though I'm told it suffers when the slack install gets large enough | 17:41 |
| fungi | yeah, i've used weeslack for years, but only in smallish slack orgs or whatever they're called | 17:42 |
| knikolla | oh fantastic, i'll have to look into that. | 17:43 |
| fungi | it's convenient to be able to treat a slack org as just another irc network, in essence | 17:49 |
| spotz | gmann are you looking for RDO or CentOS upstream folks? | 19:15 |
| clarkb | I think specifically centos as the idea is to help with third party ci testing for the distro? | 19:31 |
| *** dasm is now known as dasm|off | 20:42 | |
| *** diablo_rojo is now known as Guest3865 | 21:17 | |
| gmann | spotz: centOS upstream folk | 21:37 |
| gmann | yeah either setup the 3rd party CI or help in make the testing stable. that is something we will discuss in meeting next week | 21:37 |
| spotz | Ok let me see who I can get Aleksandra came to the Forum session she might be a good one | 21:47 |
| spotz | The request is out but timezones, I'll report back tomorrow. And it's the video call next week | 21:54 |
| gmann | yeah, thanks | 21:54 |
| opendevreview | Ghanshyam proposed openstack/governance master: Updating the RBAC goal as per new direction in zed cycle https://review.opendev.org/c/openstack/governance/+/847418 | 22:22 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!