| *** pojadhav|out is now known as pojadhav|ruck | 02:38 | |
| *** pojadhav|ruck is now known as pojadhav|break | 11:32 | |
| *** pojadhav|break is now known as pojadhav|ruck | 11:44 | |
| *** dasm|off is now known as dasm | 13:03 | |
| gmann | tc-members: meeting time | 15:00 |
|---|---|---|
| gmann | #startmeeting tc | 15:00 |
| opendevmeet | Meeting started Thu Jun 23 15:00:24 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 | #topic Roll call | 15:00 |
| gmann | o/ | 15:00 |
| slaweq | o/ | 15:00 |
| diablo_rojo | p/ | 15:01 |
| dansmith | o/ | 15:01 |
| jungleboyj | o/ | 15:01 |
| diablo_rojo | lol nailed it | 15:01 |
| diablo_rojo | o/ | 15:01 |
| spotz | o/ | 15:01 |
| dpawlik | o/ | 15:02 |
| gmann | In absence section: rosmaita (will miss 23 June and 30 June meetings) | 15:02 |
| gmann | let's start | 15:03 |
| gmann | today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 15:03 |
| gmann | #topic Follow up on past action items | 15:04 |
| gmann | no action item | 15:04 |
| gmann | #topic Gate health check | 15:04 |
| dansmith | stream9 is broken with some qemu or libvirt problem -- sounds like everyone has removed it from voting on their queue | 15:04 |
| gmann | yeah | 15:05 |
| dansmith | I'd have to go back and look, but I think it was "working" for _almost_ two months or so? | 15:05 |
| spotz | Do we have any errors we can report back? | 15:05 |
| dansmith | the fips jobs also needed some fix to the base jobs, but that is merged now | 15:05 |
| gmann | at least yes for qemu things but it was not stable | 15:05 |
| gmann | since I made it voting, some issue keep coming at least detach volume | 15:06 |
| dansmith | gmann: right but we don't know that those were really stream's fault vs just differences in behavior | 15:06 |
| dansmith | spotz: it's already reported up the stack yes | 15:07 |
| gmann | yeah, we need some volunteer from c9s team side to help in debugging so that we can fix our side things and they can do their side things | 15:07 |
| spotz | Thanks dansmith | 15:07 |
| dansmith | also on gate health, | 15:08 |
| spotz | gmann: From the Virtualation SiG or RDO? | 15:08 |
| gmann | just to update other tc-members, we discussed about c9s job stability in qa channel and clarkb mentioned there was some discussion with c9s maintainer in berlin summit . there was some talk on making it as party CI. | 15:08 |
| gmann | spotz: c9s maintainer | 15:08 |
| spotz | ok | 15:08 |
| fungi | yes, they're apparently also using zuul to do their centos stream testing, so they may be able to run some of the same jobs we do directly in their ci as well | 15:09 |
| gmann | we have many distro where we could not get much help/volunteer to debug things like opensuse, openEuler and we stopped their CI recently or last year | 15:09 |
| dansmith | yeah, using us as a heavy test case for things they want to merge makes a lot of sense | 15:10 |
| gmann | anyways we need to work on such collaboration if we have c9s in our testing runtime | 15:10 |
| dansmith | us using an unstable platform for our own testing is super frustrating | 15:10 |
| gmann | true | 15:10 |
| gmann | anyways I will add it as a separate topic and if we can call c9s folks during meeting. we can get some next steps | 15:11 |
| dansmith | we also discussed using a stream9 periodic which, if it fails three times in a row, rings a bell for someone would be a good canary for "something has changed, which might be a bug or might be an issue on our end" | 15:11 |
| gmann | yeah | 15:11 |
| dansmith | but it's going to take some commitment from folks who have interest and ability in connecting those dots | 15:11 |
| fungi | we did talk with bookwar at length about adjusting their workflow to be able to fast-track fixes and reverts/rollbacks rather than batching those up with normal platform updates | 15:11 |
| dansmith | fungi: that's cool, but it would still require halting the pipeline for a lot of people for however long the notification and fast-track takes | 15:12 |
| fungi | they acknowledge that resolving regressions a few weeks or a month after they're reported is suboptimal | 15:12 |
| dansmith | so I expect most people will still fall back to making it n-v immediately | 15:12 |
| opendevreview | Merged openstack/governance master: Add cinder ibm storwize charm https://review.opendev.org/c/openstack/governance/+/846900 | 15:13 |
| 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:13 |
| slaweq | maybe some kind of solution would be to use some snapshots of c9stream images which we know that works fine? | 15:13 |
| dansmith | so on another gate health topic: | 15:13 |
| gmann | yeah | 15:13 |
| dansmith | gorka has been looking at the c-bak memory usage in the gate, and seems to have made some progress on some obscure libc thing that might be preventing it from releasing memory back to the system | 15:13 |
| slaweq | it was something what bookwar already adviced to do on production for someone in the Summit | 15:13 |
| gmann | #link https://review.opendev.org/c/openstack/devstack/+/845805 | 15:13 |
| dansmith | so that's awesome, and he's been using the performance.json stuff to measure differences | 15:13 |
| dansmith | would be good to get this in so that is easier: https://review.opendev.org/c/openstack/devstack/+/846198 | 15:14 |
| fungi | slaweq: the downside to freezing the version of centos stream we use in testing is that it doesn't reflect how end users are consuming the same platform | 15:14 |
| dansmith | still yet to be decided if we should apply the libc fixes globally or just to c-bak | 15:14 |
| gmann | +1, that is nice improvement | 15:14 |
| fungi | unless we want to start recommending to users that the freeze centos stream themselves and not get security fixes | 15:14 |
| slaweq | fungi good point :) | 15:15 |
| diablo_rojo | eek | 15:15 |
| gmann | dansmith: libc fixes, link if there is any? | 15:16 |
| dansmith | gmann: it's the link you provided | 15:16 |
| gmann | dansmith: ohk got it. | 15:17 |
| dansmith | "fixes" might have been too strong.. "tweaks" perhaps :P | 15:17 |
| gmann | let's see how it goes and if we see more oom issues | 15:17 |
| *** diablo_rojo is now known as Guest3065 | 15:17 | |
| clarkb | there is a new ovs issue too aiui ykarel debugged it on a held node and looks like bad cpu feature testing | 15:18 |
| dansmith | oh yeah, I saw that one too | 15:18 |
| *** Guest3065 is now known as diablo_rojo | 15:18 | |
| dansmith | manifests as a bunch of kernel stack traces, IIRC | 15:18 |
| gmann | ok | 15:18 |
| clarkb | dansmith: ya I think they may be querying cpuid without checking for errors and the blazing ahead assuming the register values are all valid | 15:19 |
| dansmith | wow | 15:19 |
| clarkb | the errors can happen if you request a cpuid leaf value that is larger than what the cpu supports | 15:19 |
| knikolla | o/ sorry i'm late. | 15:19 |
| clarkb | but that was half awake and sick with what is apparently not covid digging this morning | 15:19 |
| clarkb | so I could be completely wrong | 15:19 |
| gmann | ok, anything else on gate health ? | 15:20 |
| gmann | let's move then. | 15:21 |
| slaweq | one thing | 15:21 |
| gmann | ok | 15:21 |
| slaweq | about rechecks | 15:21 |
| slaweq | I recently started doing some script which will check "naked" rechecks | 15:21 |
| slaweq | and I have some initial data | 15:21 |
| gmann | nice | 15:22 |
| slaweq | it's in https://etherpad.opendev.org/p/recheck-weekly-summary | 15:22 |
| slaweq | it's not 100% accurate yet for sure | 15:22 |
| slaweq | for example Cinder isn't good as there are some 3rd party comments with "recheck ..." there | 15:22 |
| slaweq | those shouldn't be catched probably but they are | 15:22 |
| slaweq | so I will have to improve my script for sure | 15:23 |
| gmann | this is nice data | 15:23 |
| dansmith | still, pretty nice thanks! | 15:23 |
| jungleboyj | slaweq: ++ Yeah, there are a number of CIs that give the recheck command. | 15:23 |
| dansmith | slaweq: when you're more confident will you send that to the ML? | 15:23 |
| gmann | QA is 68.42 % :) I will add this recheck thigns in our weekly meeting to improve it | 15:23 |
| slaweq | but in general it seems that we have many rechecks without reasons | 15:23 |
| slaweq | dansmith yeah, I will | 15:23 |
| gmann | yeah sending it on ML will be good trigger to such projects | 15:23 |
| dansmith | sweet! | 15:23 |
| gmann | thanks | 15:23 |
| slaweq | but I need to verify it a bit more and fix issues which I saw there | 15:23 |
| slaweq | that's all from me | 15:24 |
| gmann | nova is good in that stage only 4.8% | 15:24 |
| gmann | slaweq: thanks a lot for such data. | 15:24 |
| gmann | #action slaweq to send the recheck data on ML asking projects doing more bare recheck to start working on it | 15:24 |
| opendevreview | Kendall Nelson proposed openstack/governance-sigs master: Create the Environmental Sustainability SIG https://review.opendev.org/c/openstack/governance-sigs/+/845336 | 15:25 |
| gmann | moving to ELK topic first as dpawlik have some appointment | 15:25 |
| gmann | #topic New ELK service dashboard: e-r service | 15:25 |
| gmann | dpawlik: go ahead | 15:25 |
| dpawlik | Changes in ci log processing: created account on docker hub for ci log processing project (credentials are in AWS secret service); enabled pushing logscraper and log gearman container images into the docker hub. Still waiting for "good looking" performance.json to push the metrics to the Opensearch. About elastic recheck: I know that there was | 15:26 |
| dpawlik | something done, but it is still not deployed. | 15:26 |
| * dpawlik sorry for log message, in 3 min I need to go | 15:26 | |
| clarkb | dpawlik: note zuul has very good support for managing that credential and building and uploading the image for you. | 15:26 |
| dpawlik | clarkb: indeed. The same secret is also encrypted in zuul | 15:27 |
| * clarkb built and tested a gerrit 3.6 installation as well as tested a 3.5->3.6 upgrade yesterday before anything merged using the zuul docker image management tools | 15:27 | |
| dansmith | dpawlik: what do you mean "good looking" ? | 15:27 |
| gmann | dpawlik: thanks for updates. on elastic recheck, do you know if rdo and master branch merge is done? | 15:27 |
| dpawlik | dansmith: I mean there is no bug like service: "v2" | 15:27 |
| dansmith | dpawlik: that's more a bug in devstack itself.. do we need to wait before we can be indexing those things? It would have been handy to have it indexed for something last week.. things like the v2.0 problem will filter out once it's fixed right/ | 15:28 |
| gmann | I think we want to have some neutron folks to look into that, right dansmith ? | 15:28 |
| dansmith | gmann: not sure anyone is actively doing it, but it'd be nice yeah | 15:29 |
| gmann | but same issue in other service also like aodh? | 15:29 |
| slaweq | I can bring that topic in the neutron meeting next week | 15:29 |
| dansmith | gmann: could be, I'm not sure.. I don't look at any jobs with aodh in it | 15:29 |
| dpawlik | dansmith: I can "filter" temporary such information and start pushing the metrics to the separate index, if it's a prio. If it can wait, I suggest to wait | 15:29 |
| dansmith | I still think it's useful to have them indexed even if we have some inaccurate bits like that | 15:30 |
| gmann | agree | 15:30 |
| dansmith | dpawlik: problem is, the data is useful as-is, and fixing these little things are not as high-prio as having the rest of the data available | 15:30 |
| opendevreview | Kendall Nelson proposed openstack/governance-sigs master: Create the Environmental Sustainability SIG https://review.opendev.org/c/openstack/governance-sigs/+/845336 | 15:31 |
| dpawlik | dansmith: allright. Will do a fix for that. I will catch you on #openstack-infra | 15:31 |
| * dpawlik need to go. sorry | 15:31 | |
| dansmith | ack | 15:31 |
| gmann | thanks dpawlik | 15:32 |
| gmann | #topic Checks on Zed cycle tracker | 15:32 |
| gmann | #link https://etherpad.opendev.org/p/tc-zed-tracker | 15:32 |
| gmann | there are some progress but few items are still not started, correct me if I am wrong | 15:33 |
| gmann | 1. Technical guidlines for logging levels with more example or scenarios | 15:33 |
| gmann | 2. Drive the OSC as community-wide goals, be or find champion | 15:33 |
| gmann | 3. Renovate translation SIG i18 | 15:33 |
| gmann | 4. Recognize the new contributor work in some way: | 15:33 |
| slaweq | I think that "3. Remove release naming instead just use the number" can be marked as done now | 15:34 |
| gmann | slaweq: yes, I will do thanks | 15:34 |
| slaweq | thx gmann | 15:34 |
| gmann | these 4 are not yet started, please check if it is assigned to you. | 15:34 |
| arne_wiebalck | "2. Drive the OSC as community-wide goals, be or find champion": we wanted to wait for the corresponding forum session | 15:34 |
| gmann | arne_wiebalck: ok | 15:34 |
| arne_wiebalck | diablo_rojo and I were there to discuss with Artem and Stephen | 15:35 |
| arne_wiebalck | and also asked how the TC could help | 15:35 |
| diablo_rojo | Seems like we are getting to a good place with some larger projects to hold up as examples | 15:35 |
| diablo_rojo | which I think is why we had held off last time | 15:35 |
| diablo_rojo | Nova for example is nearly at parity. | 15:35 |
| arne_wiebalck | what the SDK team needs would be have people fixing "little" tasks in the various projects | 15:36 |
| arne_wiebalck | something for interns, students .. for instance | 15:36 |
| diablo_rojo | Yeah, more project involvement | 15:36 |
| diablo_rojo | I can bring the students if people are willing to mentor | 15:37 |
| gmann | as per last status i remember we still not got agreement from glance team on this? | 15:37 |
| arne_wiebalck | one suggestion was to have burn-down charts to see where the projects are | 15:37 |
| gmann | arne_wiebalck: yeah that will be great and good data to check if we can make it goal or not | 15:37 |
| dansmith | gmann: AFAIK, there is no desire from the (rest of) glance team to support OSC/SDK | 15:37 |
| arne_wiebalck | gmann: this is correct, I don't think anyone from the glance team was ther | 15:37 |
| arne_wiebalck | *there | 15:37 |
| gmann | dansmith: ok | 15:38 |
| dansmith | but I'm also not sure there's much missing really | 15:38 |
| dansmith | but I'll be glad to bring it back up again, | 15:38 |
| diablo_rojo | Yeah noone was there from glance | 15:38 |
| arne_wiebalck | dansmith: the general suggestion was to "increase the community pressure" | 15:38 |
| gmann | dansmith: +1 | 15:38 |
| dansmith | but I think we likely need some sort of "thou shalt do this" in order to push it along | 15:38 |
| arne_wiebalck | dansmith: ++ | 15:38 |
| dansmith | arne_wiebalck: yep, certainly more requests from users would be very helpful as well :) | 15:38 |
| jungleboyj | dansmith: ++ | 15:38 |
| gmann | I think having some chart on what left for what projects will give good idea for next step | 15:39 |
| arne_wiebalck | I think noone objected that the overall goal makes sense | 15:39 |
| diablo_rojo | dansmith, shoot! I was going to bring that up to the ops meetup but I got distracted by other topics. | 15:39 |
| diablo_rojo | arne_wiebalck, +1 | 15:39 |
| dansmith | diablo_rojo: bring up "go nag glance about osc"? yeah, that'd be helpful :) | 15:39 |
| diablo_rojo | The users/operators in the room at the forum session seemed all for it | 15:39 |
| gmann | yeah, there is no doubt that operators want it its just us not finishing it | 15:39 |
| gmann | at least they want it since many years :) | 15:39 |
| dansmith | that's good | 15:39 |
| diablo_rojo | dansmith, well not exactly, more the OSC topic in general, but I maybe if the request came from another source? :D | 15:40 |
| slaweq | in neutron we should be more or less good - I recently though that we have support for everything in OSC but recently gtema discovered that some advanced services like e.g. vpnaas are still using neutronclient python bindings | 15:40 |
| slaweq | amotoki was going to check that with gtema AFAIK | 15:40 |
| dansmith | ah okay | 15:40 |
| arne_wiebalck | gmann: right, this is where ops may also be able to help | 15:40 |
| arne_wiebalck | gmann: with interns etc | 15:40 |
| gmann | +1 | 15:40 |
| diablo_rojo | The more the merrier | 15:40 |
| arne_wiebalck | gmann: if there would be an easy to access list of low-hanging fruits | 15:40 |
| gmann | so should we start it as popup team like RBAC and proceed or all pre-work on-boarding intern etc before we can shape it as goal | 15:41 |
| knikolla | i remember attempting a spreadsheet matching client with osc commands about 2 years ago https://docs.google.com/spreadsheets/d/1C5f0BQcfD8czzhKJmWQ-nnDq_6_D9W2xsWsEh-zHIAo/edit#gid=0 | 15:41 |
| diablo_rojo | arne_wiebalck, stephenfin has generated that in the past per project, but I think its a bit tedious, maybe we can talk to him and work on generating them together? | 15:41 |
| arne_wiebalck | diablo_rojo: the low-hanging-fruits list? | 15:41 |
| arne_wiebalck | diablo_rojo: or the discrepancy list? | 15:42 |
| arne_wiebalck | anyway, let's talk to him and see what he can provide :) | 15:42 |
| diablo_rojo | arne_wiebalck, kinda both? | 15:42 |
| gmann | so what is next step 1. popup team 2. prepare the fresh current state and speed up the work | 15:43 |
| arne_wiebalck | yeah, related ofc | 15:43 |
| arne_wiebalck | but for ops the easier to see what needs to be done the better | 15:43 |
| gmann | having some regular set of people driving it with regular meeting is much needed i think | 15:43 |
| * arne_wiebalck hears silence when more meetings are mentioned :-D | 15:44 | |
| knikolla | actually, whoops, the above link is not my document. google drive search just randomly popped up a similar one :/ | 15:45 |
| gmann | ohk :) | 15:45 |
| diablo_rojo | arne_wiebalck, I feel the same. | 15:45 |
| gmann | arne_wiebalck: we need some regular work from some dedicated group here otherwise we know how it is going since many years | 15:45 |
| diablo_rojo | Lets keep things as process less as possible until we have decided to make it a goal | 15:45 |
| gmann | we have been asking project to finish the work for many years and we are not able to complete it | 15:45 |
| dansmith | I'm not anti-meeting for this, I think the policy one has been quite useful in that regard | 15:46 |
| dansmith | I dunno who is likely to be that chair though | 15:46 |
| gmann | popup team is not process overahead | 15:46 |
| gmann | yeah, RBAC has some good progress at least with popup team. | 15:46 |
| gmann | otherwise we end up saying "we need that much work to do so please do it and no one do it :)" | 15:47 |
| diablo_rojo | gmann, its not a matter of no meetings == no progress. Its no people == no progress. | 15:47 |
| arne_wiebalck | how about we check with artem and stephen if they would like to drive this? | 15:47 |
| gmann | meeting i mean drive the things in actual discussion/doing work than just status things | 15:47 |
| gmann | arne_wiebalck: sure. that will be great | 15:48 |
| arne_wiebalck | ok, let me check with them then | 15:48 |
| arne_wiebalck | if not, then we re-assess | 15:48 |
| gmann | and if we will have some regular work/meeting/people on it, it can attract more people to help | 15:48 |
| gmann | thanks | 15:48 |
| arne_wiebalck | gmann: ++ | 15:48 |
| gmann | #action arne_wiebalck to check with stephen and artem about driving the OSC work as popup team or any other dedicated group way | 15:49 |
| gmann | moving next? | 15:49 |
| gmann | #topic RBAC community-wide goal | 15:49 |
| gmann | #link https://etherpad.opendev.org/p/rbac-zed-ptg#L171 | 15:49 |
| diablo_rojo | so also, the sdk team already has regular meetings once a month anyway | 15:50 |
| gmann | in tuesday policy popup call, we discussed the operator feedback from ops meeting, KDDI (japanese telco) | 15:50 |
| gmann | diablo_rojo: yeah in any ways if a dedicated set or people can work on it | 15:50 |
| gmann | and we have the new direction based on that feedback on RBAC, its on etherpad | 15:51 |
| gmann | I need to update the same in community wide goal docuement. I have started that and almost 80% done but not up yet | 15:51 |
| gmann | I will finish that new direction write up and there we can discuss the same | 15:52 |
| knikolla | gmann: can you please update the meeting information on https://meetings.opendev.org/#Secure_Default_Policies_Popup-Team_Meeting | 15:52 |
| diablo_rojo | So I think a meeting is fine once we have a lay of the land, but I think we need to get the list of disparities before we start doing those because up till now, all the meetings we've had have just been status which is not all that productive. | 15:52 |
| gmann | key agreement there was to postponed the 'scope' which is what operator want | 15:52 |
| knikolla | i keep missing those meetings :/ | 15:52 |
| gmann | knikolla: yeah that is in my list, I will do it. sorry got distracted on that | 15:52 |
| gmann | knikolla: sorry about it, I keep this wiki up to date https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team#Meeting | 15:53 |
| gmann | sent invite calander on ML too | 15:53 |
| gmann | but I will update the irc-meeting repo also | 15:53 |
| gmann | dansmith if I remember your availability, you will be out tomorrow right? | 15:53 |
| gmann | checking if I can push goal document update today how soon you can review it | 15:54 |
| fungi | ping me when you push the irc-meetings update and i'll be sure to expedite approval | 15:54 |
| dansmith | gmann: correct.. I'll be ducking out a little early today, but if it's soon I can look | 15:54 |
| gmann | it is not just update but adding support of non irc meeting in irc-meeting repo so more work | 15:54 |
| gmann | dansmith: ok, let me try how fast i can | 15:55 |
| fungi | oh, yeah i don't think irc-meetings is a place to document meetings which don't happen in irc | 15:55 |
| gmann | that is all on RBAC, let's wait for the goal do up | 15:55 |
| dansmith | fungi: we really need a place where we can document it so it's in the ics files automatically | 15:55 |
| fungi | if we want somewhere to track non-irc meetings, that's probably a bigger discussion | 15:55 |
| gmann | fungi: yeah or remove that thing from wiki and add some other calendar | 15:55 |
| gmann | anyways let's discuss that separatly, as we are running out of time | 15:56 |
| gmann | #topic Create the Environmental Sustainability SIG | 15:56 |
| gmann | there is new SIG proposal #link https://review.opendev.org/c/openstack/governance-sigs/+/845336 | 15:56 |
| gmann | I think that is discussed in forum sessions. | 15:56 |
| fungi | this seems to answer a question i was asking diablo_rojo about in #opendev, namely that the sig is an openstack sig not some foundation-level effort? | 15:56 |
| gmann | I commented there about its scope. as it scopes is not just openstack but openinfra [projects | 15:57 |
| fungi | ahh, thanks | 15:57 |
| diablo_rojo | I think to make it productive we should start small | 15:57 |
| gmann | so doing it as openstack SIG is not that suitable place for it | 15:57 |
| diablo_rojo | and its should be openstack first | 15:57 |
| diablo_rojo | because thats where most of the efforts are | 15:57 |
| jungleboyj | Makes sense. | 15:58 |
| diablo_rojo | make progress and then push it to a higher level and hold up the progress we made from the openstack scope first | 15:58 |
| gmann | diablo_rojo: we do have working group as one possible place to start like diversity group, interop group | 15:58 |
| diablo_rojo | I think if we start too high level first, we risk a lot of sprawl and not much progress. | 15:58 |
| fungi | if it's an openstack sig, i would expect the irc channel to be #openstack-envirosig instead of #openinfra-envirosig, unless there's a foundation sig for which the openstack sig participants are a subset | 15:58 |
| diablo_rojo | gmann, yeah I know | 15:58 |
| diablo_rojo | fungi, I wanted room for growth? | 15:58 |
| gmann | diablo_rojo: my concern is if we see it as openinfra level then it is better to do it now instead of changing all latter which is more work | 15:59 |
| gmann | like irc channel as fungi mentioned | 15:59 |
| fungi | at the foundation level we don't have any concept of "sigs" that i'm aware of | 15:59 |
| diablo_rojo | fungi, that too | 15:59 |
| diablo_rojo | its working groups | 15:59 |
| gmann | fungi: Working Group | 15:59 |
| fungi | so openstack-envirosig or openinfra-envirowg | 16:00 |
| gmann | and it can work same way as we want as SIG, like interop WG doing | 16:00 |
| fungi | sig is an openstack thing, wg is a foundation thing | 16:00 |
| gmann | they own code repo, marketting things, connect community or so | 16:00 |
| gmann | or what diversity group is doing which is close example of this new env SIG | 16:00 |
| diablo_rojo | I think we need other input from people interested in the efforts. | 16:01 |
| gmann | I feel converting things later make more confusing which include the supporting channel, communication ways change | 16:01 |
| diablo_rojo | I am just one opinion. | 16:01 |
| diablo_rojo | Which is why I set up the IRC channel to be openinfra and not openstack | 16:01 |
| gmann | and changes to those things end up with losing people helping there | 16:01 |
| fungi | my concern is more around overloading organizational terminology. reusing the "sig" term for foundation level organizational concepts is going to increase confusion | 16:02 |
| jungleboyj | I think it is more confusing to change in the future. | 16:02 |
| gmann | why not we can do all things as WG if we have interested people can help three too instead of SIG | 16:02 |
| gmann | I do not think any difference there to do the things as WG or SIG if we have people to help here | 16:03 |
| gmann | fungi: we do not need to say it as SIG but we can sao Working Group like Diversity WG and drive the things to all OpenInfra projects | 16:03 |
| gmann | we are running out of time | 16:04 |
| fungi | gmann: agreed. i'm referring to the proposed changes to add the irc channel for it, which uses "openinfra" and "sig" together in teh name | 16:04 |
| gmann | fungi: ah right | 16:04 |
| diablo_rojo | I think the people that want to participate in the group should decide what level it goes at. I am more than happy to do it either way. I just want to see us move forward. | 16:05 |
| gmann | let's continue the discussion in next meeting. and meanwhile tc-members and other please input your feedback on gerrit #link https://review.opendev.org/c/openstack/governance-sigs/+/845336 | 16:05 |
| gmann | sure | 16:05 |
| jungleboyj | ++ | 16:06 |
| gmann | diablo_rojo: I will keep it in meeting agenda till we get clear direction on this | 16:06 |
| gmann | thanks for working on it. | 16:06 |
| gmann | that is all for today, we are out of time now | 16:06 |
| gmann | thanks everyone for joining | 16:06 |
| gmann | #endmeeting | 16:06 |
| opendevmeet | Meeting ended Thu Jun 23 16:06:53 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-23-15.00.html | 16:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-23-15.00.txt | 16:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-23-15.00.log.html | 16:06 |
| diablo_rojo | gmann, sounds good | 16:06 |
| spotz | Thanks gmann everyone! | 16:06 |
| diablo_rojo | thank you! | 16:06 |
| slaweq | thx all | 16:07 |
| jungleboyj | Thank you all! | 16:07 |
| slaweq | tc-members: can You review https://review.opendev.org/c/openstack/governance/+/839880 and https://review.opendev.org/c/openstack/governance/+/840856 when You will have few minutes? | 16:07 |
| slaweq | thx in advance | 16:07 |
| jungleboyj | Will do. | 16:08 |
| arne_wiebalck | thanks everyone! | 16:12 |
| *** frenzy_friday is now known as frenzyfriday|PTO | 16:21 | |
| *** pojadhav|ruck is now known as pojadhav|afk | 16:26 | |
| dasm | gmann: o/ i'm finally able to look back into Elastic Recheck. There are many incompatible changes between master and rdo. | 17:03 |
| dasm | currently we don't have running recheck, so i was thinking about merging back all changes rdo -> master and start reverting/clearing incompatibilities. | 17:04 |
| dasm | any pros/cons regarding that? | 17:04 |
| dasm | cc frenzyfriday|PTO ^ | 17:04 |
| gmann | dasm: sounds good, as elastic recheck is no up and so does not being used, having incompatibilities and clearing them case by case is all good. | 17:15 |
| dasm | ++ | 17:16 |
| dasm | i just sent email to the mailing list with a few words summarizing that. | 17:18 |
| gmann | dasm: thanks | 17:24 |
| gmann | tc-members: as we merged the openstack-doc (Technical Writing) SIG and its repo into TC (https://github.com/openstack/governance/commit/158e2be5a9b7aad43214517ebc6aa0560fdc87f4) I have added tc member group as core in openstack-doc-core (we discussed the same but somehow I might have forget to do) - https://review.opendev.org/admin/groups/238e9f33453744139facac78a6eb17de63c46a00,members | 17:24 |
| gmann | given that, please review these two changes from frickler 1. https://review.opendev.org/c/openstack/openstack-manuals/+/847361 2. https://review.opendev.org/c/openstack/openstack-manuals/+/847360/1 | 17:25 |
| clarkb | just thinkihng out loud here, this may be a good lesson for not hard forking within our community that way. Much of the changes in that diff could have been made against master instead and kept up to date for everyone from the start of new maintainership | 17:30 |
| clarkb | I think we were more than happy to hand over the keys to the repo, but were surprised to see the immediate first step was a new branch and a hard fork | 17:30 |
| fungi | dasm: merging the rdo branch to master, deleting the rdo branch, and then maintaining a single branch that works for everyone is what i've been suggesting for months. i even updated the acl for it to make that easier: https://review.opendev.org/840455 | 17:36 |
| dasm | fungi: oh, can I merge all changes at once? That would be awesome! | 17:54 |
| fungi | you can push a merge commit resulting from an overwrite merge of the rdo branch into the master branch, yes | 17:55 |
| fungi | at least as long as you're in the elastic-recheck-release group (i'm pretty sure i added you to that already) | 17:55 |
| dasm | i saw i have +2 rights to this branch, yes. | 17:56 |
| fungi | just make sure you don't overwrite the .gitreview file, otherwise git-review will be confused | 17:56 |
| clarkb | and that is for pushing the merge as a change to review not a force push over the history | 17:56 |
| fungi | right, https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#merge-feature-branch-into-master | 17:57 |
| clarkb | reviewing those is a little different than an omral change as it shows you the conflicts by default iirc rather than the regular diff | 17:57 |
| fungi | see the section just after that for how to omit the .gitreview file from being overwritten | 17:57 |
| dasm | ack, will do that | 17:57 |
| dansmith | fungi: I included you on that review because I thought I remembered you chiming in about the indexing, but I see from the logs I was just confusing temporal co-topic-ing | 18:12 |
| fungi | no worries, i saw the discussion about it and do agree | 18:13 |
| *** diablo_rojo is now known as Guest3078 | 19:09 | |
| frenzyfriday|PTO | dasm, i am working on https://review.opendev.org/c/opendev/elastic-recheck/+/845777 to integrate with the opensearch. Once that is done probably we can get it running | 19:42 |
| dasm | frenzyfriday|PTO: ack. i prepared merge-branch patch: https://review.opendev.org/c/opendev/elastic-recheck/+/847405/ cc fungi | 19:47 |
| fungi | dasm: lgtm, seems to have the two branch heads as parents of the proposed merge commit, and omits changing .gitreview so there's no new defaultbranch parameter in it | 19:52 |
| opendevreview | Gage Hugo proposed openstack/governance master: Retire openstack-helm-deployments https://review.opendev.org/c/openstack/governance/+/847413 | 21:33 |
| opendevreview | Samuel Walladge proposed openstack/governance master: Add Cinder Dell EMC PowerStore charm https://review.opendev.org/c/openstack/governance/+/846890 | 21:48 |
| *** dasm is now known as dasm|off | 22:07 | |
| 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 | 23:30 |
| gmann | dansmith: ^^ once you are online, RBAC goal update. Please check if I wrote the project-manager (Phase 3) things correctly and as per discussion. | 23:31 |
| gmann | dansmith: also I realized later that we need to drop the scope from keystone policy also otherwise it will break heat and so does Tacker | 23:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!