16:00:06 #startmeeting tc 16:00:06 Meeting started Wed Feb 22 16:00:06 2023 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:06 The meeting name has been set to 'tc' 16:00:09 #topic Roll call 16:00:10 o/ 16:00:13 o/ 16:00:14 o/ 16:00:14 o/ 16:00:33 o/ 16:00:46 o/ 16:00:58 \o /me sits again at the back :) 16:01:35 let's wait for couple of min if other tc-members joining 16:01:47 * mnaser sits at the side 16:01:57 meanwhile this is today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 16:02:35 o/ 16:03:05 o/ 16:03:12 let's start 16:03:16 #topic Follow up on past action items 16:03:26 #link https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-15-16.00.html 16:03:33 two action item from previous meeting 16:03:37 noonedeadpunk to add PyPi access policy in governance documentation 16:03:43 o/ 16:03:46 I've pushed 2 patches as of today - https://review.opendev.org/q/topic:tc%252Fopenstackci_pypi 16:04:05 noonedeadpunk: I think some of the effort I made got duplicated b/c I wasn't here last week to show my work -> https://review.opendev.org/c/opendev/infra-manual/+/873033 16:04:07 I'm also looking at project-team-guide for place where to better mention this requirement 16:04:20 noonedeadpunk: I've put some comments on your changes and I think a mix of what I wrote and what you put up will likely be ideal 16:04:22 o/ 16:04:24 Aha 16:04:42 as we need something in governance to say "openstack projects must do this" (what you're doing) and something in manuals saying how to (what I did) 16:05:37 sure, that will be helpful, we can make depends-on on JayF patch and modify the governance in parallel on policy 16:05:55 thanks noonedeadpunk for pushing those, let's review those 16:06:17 second action item is - gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job 16:06:46 I did not get time to prepare this. I will try to finish this in this week so continuing it as action item 16:06:53 #action gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job 16:07:01 topic Gate health check 16:07:05 #topic Gate health check 16:07:12 any better news on gate? 16:07:19 timouts still happening 16:07:20 my summary is "slightly better than last week" 16:07:27 but still quite poor 16:07:37 last week wasn't good for sure 16:07:40 few timeout are gone but yes it still happening 16:07:48 noonedeadpunk: I've seen fewer (I think) but agree, it's still happening way too often 16:07:54 I also see that in number of rechecks needed to get something merged - gates weren't stable 16:08:21 thanks for the hard efforts on tempest folks ! 16:08:34 Well, yes, I agree it's better, but far from perfect. 16:08:36 slaweq: noonedeadpunk do you two see the volume test failures in your gates? 16:08:40 I'm not sure what you run compared to us 16:08:48 yeah moving cirros image vesion to 0.6.1 alsao broke some job which is now reverted #link https://review.opendev.org/c/openstack/devstack/+/874625 16:08:54 I've been trying to fix cinder tests that I find 16:08:55 I wish I could have metrics to share about rechecks 16:09:14 and yeah, cirros-0.6.1 is creating a few issues that need to be addressed 16:09:23 dansmith in Neutron we are running "integrated-networking" tests so no cinder related tests theere 16:09:31 slaweq: okay 16:09:35 I now wonder if some of the seemingly-random ironic failures this week were potentially cirros related. 16:09:44 slaweq: but we have sometimes some dhcp problems in the gate 16:09:50 dansmith: no we run jsut couple of default integrational scenarios, so didn't see anything to off with cinder 16:09:52 JayF: the failures over the last day after say 8am yesteday are all it 16:09:53 is the ovn fix in jammy-updates yet or still only in -proposed? 16:09:58 the client doesn't get the lease in time 16:10:01 TheJulia: ack; ty for the detail 16:10:11 we also don't run devstack, so... 16:10:12 dhcp problem was due to cirros, which should be fixed now 16:10:17 after 3 retries, each after 1 min 16:10:18 bauzas can You point me to the failed job with such dhcp issue? 16:10:20 bauzas: feel free to recheck now 16:10:32 gmann: because of a cirros upgrade ? 16:10:37 yeah 16:10:39 bauzas: yes 16:10:43 regarding cirros 0.6.1 I recently added support for dhcpcd in tempest 16:10:46 it's merged 16:11:11 bauzas: if you find dhcp issue and have a fix, please let me know. dhcp failures are also a pain point for me 16:11:24 so jobs which are using that needs to configure proper dhcp client to use, like we did in neutron https://review.opendev.org/c/openstack/neutron/+/871272 16:11:32 well, there are the usual dhcp issues, and the recent ones I think 16:11:37 slaweq: sec, I have a patch up for Nova 16:11:37 but volume detach things are big blocker now a days 16:11:51 the cirros problem is just the recent increase I think, but in general, lack of networking to the guests is a common flaky failure point 16:11:55 dansmith: yeah, they need to be delienated if at all possible :) 16:11:58 right 16:12:41 my impression and the longer term class is "not configured in time" 16:12:44 slaweq: wait, so the new dchp client will work for cirror <0.6.2 also? because cirros version bump is reverted in devstack #link https://review.opendev.org/c/openstack/devstack/+/874625 16:13:05 we tried to test cirros-0.6 with dhcpcd https://review.opendev.org/c/openstack/nova/+/873934 16:13:19 that should work 16:13:23 TheJulia: I don't think it's that.. that's how it manifests, but I think it's not actually slowness as the guest is usually up and bored, but we still can't talk to it 16:13:32 slaweq: this is the bug report we use for tracking the dhcp lease issues https://bugs.launchpad.net/nova/+bug/2006467 16:13:39 anywyas let's take this to qa channel after meeting as we have many other topics to discuss today ? 16:13:47 dansmith: indeed 16:13:50 bauzas: thanks, that is helpful 16:13:58 any other gate things? 16:14:16 is the ovn fix in jammy-updates yet or still only in -proposed? 16:14:56 just wondering if nova was still running into those failures too 16:15:05 which ovn fix? 16:15:07 which one? slaweq do you know? 16:15:32 nope 16:15:40 fungi: any link please? 16:15:43 the one last week which fnordahl pushed an sru for 16:16:05 i'd have to dig the lp link out of the nova channel 16:16:07 so I probably missed it, most likely ralonsoh will know 16:16:20 let me read first 16:16:37 fungi: hmm, sorry, I remember-ish that without context 16:16:43 ok, let's check/talk on nova or qa channel about that 16:16:50 that does ring a bell, but a small one 16:17:04 sorry, ovs 16:17:08 #link https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2003060 16:17:10 yup, openstack-qa seems a good place to discuss to me 16:17:24 yeah, let's move to next topic 16:17:28 #topic Discussion of "Add guidelines about naming versions of the OpenStack projects" 16:17:40 #link https://review.opendev.org/c/openstack/governance/+/874484 16:18:09 we had discussion on version guidlines for document and release notes for consistency among openstack projects. which is ask by projects in PTG 16:18:28 I'd like to ask we keep the conversation to the content of that change -- I simply want it to be clear we can refer to individual packages, and their versions, without having to include information about the integrated release. There are no specific plans or details on when or where I want to do this; I just think it's valuable to retain that freedom. 16:18:45 slaweq: pushed the changes which was merged as per formal-vote criteira andwhat we discussed in PTG #link https://review.opendev.org/c/openstack/governance/+/872769 16:18:48 For reasons that are partially my fault; it turned into a conversation about "standalone ironic" which was not my intention 16:19:01 JayF: has some updates suggestion on that ^^ 16:19:46 JayF: I think that is reasonable, although I'd honestly prefer a higher bandwidth medium so we can exercise listening as opposed to reading, as I think something gets lost in translation 16:19:48 sure, actually conversation on another things started from the comment on the proposal of not using 'openstack' but use cordinated release version 16:20:33 but yes, let's discuss about the change and providing the two option in that guidlines one with OpenStack coordinated rlease and one with project version only 16:20:49 TheJulia: frankly if there are other issues to discuss; we should discuss them in a proper venue -- I just don't want to be the nexus of those disucssions nor to have my (honestly, relatively minor) governance update tied up in them 16:21:05 I think that is totally reasonable. My concern comes up when an explicit single way mandate comes into play. 16:21:07 I suggest that two option in that patch becuase using release version '2023.1' without 'openstack' word seems odd 16:21:19 on the other hand, mentioning that the standalone product has been tested amongst a large list of other projects seems a quite good incentive for promoting OpenStack to others who just went to the standalone product without getting the whole stack 16:21:24 I think we still should omit having cooredinated release but for projects with independant release model at very least 16:21:29 JayF: absolutely agree, there are defintely related discussions occuring in the thread 16:21:38 As coordinated release is simply not applicable for it 16:22:08 a coordinated release implies that we ensure all our projects are tested between themselves, even the standalone ones 16:22:10 noonedeadpunk: meaning make the doc say "independent release projects should omit the OpensStack 2023.1 part" ? 16:22:14 noonedeadpunk: This sorta puts the crunch on Ironic; given we have users that use both our independent and coordinated releases. It's not as clean as one or the other. 16:22:17 that seemed to be the consensus. providing two ways to refers depending on whether it's being consumed as an integrated release (with openstack and release name), or by itself (without openstack release version). 16:22:49 noonedeadpunk: but you mean standalone project to move to intendent release model too ? 16:22:51 but people can start consuming a project and after that integrating it with other projects 16:23:02 There's also the fact that the integrated release name is on the url path of the docs 16:23:08 dansmith: well, you don't really know part of what they are? 16:23:25 My preference, as demonstrated by the patch, is to trust the people closest to the project to know the best context to put things in rather than dictate it at a TC level. 16:23:30 yes, removing integrated release version completly is hard 16:23:32 noonedeadpunk: I'm asking if you're suggesting drawing the line at "independent release or not" 16:23:32 For exemple - they can have last release 2 years ago 16:24:21 dansmith: yes, I'd say that for project with independant release cadence it doesn't make much sense to mention coordinated release in docs or release notes 16:24:29 noonedeadpunk like Tripleo for example :) 16:24:34 dansmith: but they still can/should be mentioned on releases page 16:24:49 but ironic is independent release model or coordinated ? 16:24:57 cycle with intermediacy 16:24:58 slaweq: I was thinking more about tempest or oslo, but yeah... :D 16:25:02 noonedeadpunk: agree, and by the same token coordinated or independent-and-coordinated (or whatever it's called) would continue to refer to which coordinated release the doc goes with right? 16:25:13 yeah, cycle-with-intermediate is what I meant ^ 16:25:18 then mentioning only about independent release does not solve ironic case right? 16:25:23 dansmith: yeah, sure 16:25:35 gmann: correct, but I think that's what noonedeadpunk is suggesting 16:25:38 I do not intend on updating my governance change to draw the line based on specific release models. There is little value in micromanaging to that level. 16:25:54 And I would not be in favor of a different change that drew that line. 16:25:58 standalone vs non-standalone is right thing to suggest? 16:26:01 JayF: that's your opinion, I think it's clear that for a bunch of people here, we see a value there 16:26:15 value in consistency 16:26:33 consistency is the key and from where these guidelines requirement came from 16:27:06 I think this whole release model discussion is contrary to the heart of the issue, which is how do projects refer to other projects 16:27:40 as mnaser also mentioned in patch and I also commented, having a top level line of saying 'this project can be used as integrated openstck and standalone and ignore the openstack version if you are a standalone user and do not know openstack' can clear the thigns 16:27:41 I'm not sure it's that so much as "how do projects refer to the group of versions of other projects that they were tested with" 16:27:44 And if there are going be changes there, that has a wide reaching impact which may or may not be desirable, so I would encourage lots of thought, discusison, and consideration of feedback 16:27:46 But I think my biggest question to the change about motives behind it? As I'm not really sure that intention was to distantiate project from openstack, but was about being more clear for end-users that are standalone? 16:27:51 Could we refer to other projects by release or tag? 16:28:27 consistency is super important 16:28:29 spotz[m]: tag? tag are release version for projects 16:28:33 +1 16:29:00 consistency is important, but to be consistent one has to be mindful of their audience 16:29:05 if I start using project A with 2023.1, I somehow want to make sure that if I use project B later, 2023.1 release will work with project B 16:29:13 project A* my bad 16:29:15 spotz[m]: My change, as written, just explicitly permits contributors when sensible in context to refer only to the component name and version. Without my change, it appears any reference to an integrated project needs to be prefaced with the integrated version. 16:29:28 are you saying the audience of ironic is people who will lose their hope at using the software when they see openstack 16:29:33 their audience has a starting context, they need to manage that context, and then any author needs to go onward from there 16:30:05 mnaser: that is one of the feedback items we tend to get 16:30:07 "ugh, openstack, forget ironic, it has the o word, i will ignore it as a very capable toolkit to manage by baremetal" 16:30:24 well maybe educating those people might be the way to go rather than dodging the whole thing 16:30:27 and that is a whole perception issue which is... differnet 16:30:31 I just want to call out that the conversation is devolving. 16:30:37 knikolla[m]: indeed! 16:30:42 I really do not understand the concern that ironic users may see the word openstack in the doc (ignoring that it's already in the URL) and be concerned that they're going to have to deploy more than they expect 16:30:42 And we're not discussing the item at hand. 16:30:51 we should stick to the topic at hand, how projects should refer to other projects. 16:31:05 Which is, in the case of standalone projects, does it make sense to allow them in some use cases to omit integrated release name. Consensus was that it does. 16:31:10 Please, keep the focus on the difference as proposed in the patch: should contributors be permitted to reference their projects' actual-version without prefacing it with the integrated release when sensible 16:31:11 but if that's the concern, how about a note or a footnote that clearly indicates that ironic can be deployed standalone? 16:31:12 JayF: but would suffixing openstack version isntead of prefixing it solve your issue? 16:31:33 all projects should refer to other projects by the openstack release number so that people who are trying to run this arent stuck looking for this all the time 16:31:33 ok so we are missing thing here again. I think both are somwhere related where ironic as standalone want version without openstack 16:31:34 Consistency when using those projects together with other projects would be preserved, because the integrated release version in that case would still be included. 16:31:41 it is hard to separate the things 16:31:49 I do not want to hypothetical or hypothesize about other things; I'm not trying to split any hair other than maintaining my and other Ironic contributors' editorial independence when writing docs about these. 16:31:51 knikolla[m]: consensus where 16:31:52 its frustrating enoguh opening releases.openstack.org all the time because i have no idea what release nova 23 is. 16:32:07 mnaser: I feel the same :) 16:32:08 mnaser: well, I think that's why we have https://releases.openstack.org/antelope/index.html 16:32:10 ++ 16:32:18 mnaser: I work on nova and I don't even know what nova version numbers match up to anything :D 16:32:20 mnaser: right, I do check for tempest also many time even I do releaase for it :) 16:32:23 mnaser: that is a good data point, can you articulate how you get to that starting point of looking for nova 23 ? 16:32:31 Which must be source of truth kind of for integration between components 16:32:33 pip freeze in an env? 16:32:39 it even takes me 0.5secs to remember the nova release number for every cycle when I write the relnotes 16:32:47 well... that is a *whole* different issue then 16:32:55 dansmith: the majority in the patch discussion had no objection, you included if i'm not wrong, to allow an option to use case for omitting the coordinated release version when considering a project separately from the rest. 16:32:58 this is taking too much brain cycles to calculate this in my mind 16:33:02 no because now i will end up on the ironic 19.0.0 release page docs 16:33:06 and i will have no idea what version of openstack it is 16:33:10 TheJulia: I'd like to point out that you commented on my mention of that concern and maybe even implied malice on my part :) 16:33:31 do we have any other stanadalone project case here and what they thing? 16:33:40 knikolla[m]: I don't think you're reading that right ;) 16:33:57 The way the conversation has devolved into a referendum on the decisions Ironic has made with regard to what else it's integrated with does feel malicious in some ways. I understand my feelings may not align with reality but it's hard not to connect them when scope keeps getting balooned. 16:33:58 are they also feel having openstack version in doc confuse users? 16:34:19 dansmith: then apologies for that. i will go and read it again. 16:34:28 To be frank - for me some middle ground would be making main focus on project version and reference openstack version afterwards 16:34:43 noonedeadpunk: that is ok if that solve the issue 16:34:52 So instead saying `OpenStack 2023.1 (Nova 27.0.0)` we can do `Nova 27.0.0 (OpenStack 2023.1)` 16:35:00 we had that option in pTG discussion 16:35:04 noonedeadpunk: that was essentially my original proposal 16:35:12 noonedeadpunk: if you look at Patchset 1, per your original suggestion 16:35:22 at this point; I think I prefer my current patchset to that one though 16:35:28 And I'm not sure where all this fuss about ironic and distantiation from openstack has come from... 16:35:43 noonedeadpunk: I strongly dislike mentioning the nova release number before the openstack release 16:35:55 oh? 16:36:00 JayF: no. proposal; in PS1 was "Nova 2023.1 Series (27.X.Y)" 16:36:06 and I'll encourage my projects contributors to always refer to the openstack release 16:36:25 gmann: right, which is incorrect, because the nova version is not 2023.1 16:36:34 dansmith: not implying malice on your part, but there is a potential risk there, which is an entirely separate discussion. If that is a driver to be dsicussed, then so be it but we shouldn't merge the issues together. Hearing mnaser express frustration from pip freeze to what version is a very valid issue, but we're going to impact identity at that point and then we are re-framing what is openstack 16:36:36 yeah it's a meaningless 27.0.0 16:36:36 gmann: ack; that's fair 16:36:43 at which point, a higher level discussion is truly needed to validate perceptions 16:36:54 which needs you need to calculate how many nova releases you got since Austin 16:37:05 and for Neutron this is weirder 16:37:09 bauzas: but we also do have usecases of project that are deployable and used quite heavily outside of openstack. where openstack version is not that important for some users 16:37:12 so we need to solve standalone case and how standalone projects can consume both version for both cases 16:37:24 you have to take in account this was incepted later as a Quantum project, somewhere in Essex release 16:37:31 and I think talking to few more standalone projct will give us more clarity now 16:37:48 I have proposed that solution: trust the contributors of the standalone project to reference them reasonably. If we publish documents, as an Ironic team, that people have an issue with, we can deal with them specifically 16:38:03 bauzas: so basically you're saying that "Nova 2023.1 Series (27.X.Y)" would be good for you? 16:38:04 Folks, there are several different issues at play here, each one is a separate discussion. 16:38:09 for now; I just want to not feel handcuffed when writing up official things about Ironic that might be targetted more towards standalone users 16:38:16 noonedeadpunk: this is a message I tend to disagree : even standalone users can take benefits of a release number that guarantees you a compatibility with other products from the same foundation 16:38:20 It seems to me this topic is a larger issue needing further discussion and maybe a wider audience 16:38:22 This is the focus of my patch; none of this larger picture stuff 16:38:25 noonedeadpunk: not fine with me 16:38:25 noonedeadpunk: that is too confusing 16:38:40 gmann: dansmith I'm just trying to understand 16:38:46 k 16:38:55 JayF: I get that you don't want to discuss the larger issue, but for what seems like a bunch of us, we can't understand the "smaller" change without the larger context 16:39:08 noonedeadpunk: pesonnally, I think 50% of the users probably misunderstand the different projects we have 16:39:09 JayF: if I'm to ignore the larger context on the "smaller" change then I'm -1 because it makes no sense to me 16:39:20 bauzas: I think we're jsut talking now where to place coordinated release and where project version 16:39:23 noonedeadpunk: mentioning the project first seems always weird to me 16:39:31 dansmith: bluntly; I'd rather have a straight up-and-down vote lost than continue down these unfruitful discussions of the last two or three days 16:39:35 i think this small change is contextual out of a larger context 16:39:45 ok so let's do one things. I think it is hard to conclude in meeting or in review. let's dodiscussion or re-discuss in PTG on that ? 16:39:50 JayF: roger that 16:39:53 No; I am not OK with that gmann 16:40:07 because that means the policy as written/landed while I was out will be in effect for all docs I write for EOC Antelope 16:40:12 and starting of Bobcat ycle 16:40:36 So I do not want this punted; I want it voted on. If it loses; it loses; but I will not kick the can further down the road. 16:40:50 well 16:40:54 then the tc votes 16:40:59 and then we can discuss in the ptg again 16:41:06 sure, that work fine 16:41:06 and then we revert all the release notes if we decide agaisnt it 16:41:07 bauzas: well, I also have usecase where porject version matters. As depending on project version you can tell exactly SHA of other dependencies that were installed 16:41:15 oops, im not part of the tc, but thats what i was thinking 16:41:23 Hehe 16:41:33 I don't care much what would be first though as it looks quite insufficient for me 16:41:40 no it is ok to vote on proposal and if still objection on results we can discus in PTG 16:41:41 mnaser: you are tc-emeritus, i think 16:41:54 He is 16:42:03 i am but i'm running off with it as a tc-member :) 16:42:16 noonedeadpunk: fwiw we pin our RPC versions with the openstack release name, so... 16:42:16 but my opinion is that it should get voted on, and if it goes through, great, if it doesn't, great. it can be rediscussed in ptg 16:42:21 and then anything can be easily reverted 16:42:56 bauzas: but error out with ID in case of mismath :p 16:43:01 27.0.0 is only an openstack/releases number that very insightful people know :p 16:43:02 tc-members: all ok with that and vote means vote on gerrit right? 16:43:05 well, what I'm hearing is that JayF wants a vote on the patch, and very specifically without any larger context about why the change might be needed 16:43:12 if any tc members want to ready the patch/conversation 16:43:37 gmann: yep, sounds like it 16:43:50 yeah. let's vote on patch and in next video call we take decision if still not concluded on gerrit? 16:43:54 But yeah, as I said I personally don't care much about what will be first, but I can understand why some may preffer X over Y 16:44:15 gmann +1 16:44:28 I will say to get more opinion of other standalone projects but I will try to get those people if I can 16:44:33 I'd just say when voting: have some trust in your contributors? My career, as is most of the others in here, is tied to *OpenStack*. Show some trust that if you give the freedom it will not be abused. 16:44:37 JayF: it works for you? 16:44:54 JayF: you're not the only one that has been doing openstack and only openstack :) 16:44:55 gmann: sure 16:45:01 ok 16:45:04 but some of us here do more than just one project and _have_ to know the big context 16:45:10 mnaser: I know, I just think some folks are reading bad motives into things here, and there are none 16:45:18 moving next, as we are running out of time 16:45:32 the less context we have, the harder it is to see your pov, but i will let gmann run the rest of the meeting ) 16:45:33 :) 16:45:45 But context here may be entirely different from outside this channel 16:46:11 sure, let's vote on patch and other things we can discuss as separte, feel free to add it in PTG etherpad 16:46:15 #topic TC 2023.1 tracker status checks 16:46:22 #link https://etherpad.opendev.org/p/tc-2023.1-tracker 16:46:42 I will skip this one but please do check your assigned itme as we are approaching to cycle end 16:47:50 #topic Deprecation process for TripleO 16:48:05 we're full of hot topics todya, huh 16:48:26 as discussed in last meeting, I asked about maintaining zed branch too #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032239.html 16:48:30 starting the new tc term with fireworks 16:48:47 james mentioned he will check it in tripleO team and get back to TC 16:49:03 but no response yet so I will say let's wait and I will ping them again 16:49:13 knikolla[m]: noonedeadpunk :) 16:49:42 anything else anyone want to discuss on this ? 16:49:42 yeah, that's disappointing.. I suspect maintaining zed would mostly be a ceremonial thing, not requiring a lot of work on their part 16:50:13 hope so but not sure what tripleo plan is 16:50:25 Have we reached out to PTLs of other deployment projects to see if they have an interest in developing a tripleo migration plan? 16:50:33 It'd be a good way to get tripleo users on OSA/KA/et 16:50:35 *etc 16:50:44 I think at very least we should provide them with guidance on deperecation process of master branch? 16:50:49 its there on ML but i did not see anyone shown interest 16:50:52 JayF: meaning a plan to migrate tripleo users to something else like OSA? 16:51:06 Yeah; some kind of off-ramp so they can keep using openstack-blessed deployment methods 16:51:10 even with tripleo being retired 16:51:13 I'm kind of interested, but lacking time right now 16:51:25 noonedeadpunk: sure, let me ping them and we can give path forward for master at least 16:51:30 I think this is really good idea to be frank 16:51:36 it seems like a way for us to prevent loss of face in the light of the users who might be marooned 16:52:24 aren't we forced to find a way to maintain TripleO back to Xena, as it was part of an official OpenStack release? 16:52:28 And OSA has path wit husage of RDO packages 16:52:30 let me check with Tripleo about zed maintenance and way to proceed on master if that is blocking them on something 16:52:49 knikolla[m]: there is no xena. its wallaby and then zed tjhat is all confusion 16:52:57 k moving to next topic? 16:53:00 JayF: it'd be nice for sure, but knowing what I do (and don't) know about tripleo, that would likely be a massive amount of work 16:53:07 gmann: wait a sec 16:53:12 knikolla[m]: there is no function to force the people who know about a project to maintain it if they don't want to; that's part of why I get nervous about projects primarily with one corporate sponsor 16:53:12 k 16:53:13 ah :/ right. 16:53:23 knikolla[m]: yeah, it's really messy :( 16:53:24 as a reminder, tripleo is a collection of repos 16:53:24 There's also a ML and PR regarding picking up some delivareables by Heat 16:53:44 maybe some have more interests for consumers than others 16:53:59 noonedeadpunk: that config one? I did not see that yet but that will be great 16:54:07 JayF: I understand. I mean that the openstack releases page makes a promise about level of support and we are missing the mark on it. 16:54:07 I see no reason to refuse this request, but I wonder if we should block it or not until master will be deprecated 16:54:28 noonedeadpunk: agree, any other project taking maaintainance of few thigns is good 16:54:35 #link https://review.opendev.org/c/openstack/governance/+/874719 16:54:36 knikolla[m]: that's my primary concern btw 16:54:36 errr... maintainance... not support 16:54:40 knikolla[m]: what it means for our "reputation" 16:54:56 noonedeadpunk: well we can move that deliverables form TripleO to heat and no deprecation thngs for that deliverbales 16:55:03 knikolla[m]: and tripleo being very niche doesn't help, because the easy thing is to say "oh well, nobody cares anyway" but it sets the precedent for the next thing 16:55:07 ++ 16:55:23 we can do that before release things happen. I will check that right after the meeting 16:55:45 dansmith: ++ 16:55:48 let's move next now 16:55:50 #topic Cleanup of PyPI maintainer list for OpenStack Projects 16:55:55 Etherpad for audit and cleanup of additional PyPi maintainers 16:56:03 #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup 16:56:17 ML discussion: #link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848.html 16:56:28 JayF: any update on email template things ? 16:56:42 I think its good to go now unless no objection on etherpad 16:56:44 it exists; I think it's linked in there? 16:57:03 #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template 16:57:09 FYI, QA team reachout out to all additionla maintainers and they removed themself and given the ownership to openstackci 16:57:10 it's not linked, but I'll add it now 16:57:24 althoguh it's not really good to go until after my infra-manual change lands 16:57:34 JayF: ok, I am saying we can go ahead on the email template. or you are waiting for infra patch to merge? 16:57:37 and it'll be able to be more strongly worded if we land noonedeadpunk's proposed policy 16:57:45 ohk, will check after meeting 16:57:47 I would suggest waiting; fungi has a +1 on my infra-manuals patch now 16:57:53 so I suspect it's extremely close to landing 16:57:53 ack 16:58:01 we have little stannding to ask without hte policy being written 16:58:05 I will update my patch right after the meeting 16:58:10 like, we can ask; but there's no power of TC-force to apply to it yet 16:58:10 cool 16:58:12 I hope being able to predict URL :D 16:58:20 JayF: sure 16:58:25 thanks noonedeadpunk JayF 16:58:32 moving to next topic 16:58:36 #toic Election updates & post-election work 16:58:41 #topic Election updates & post-election work 16:59:07 * gmann fingers are hurting by typing so much :) 16:59:13 Election will be closed by today 23:45 UTC 16:59:17 gmann: suck it up chief! 16:59:22 https://governance.openstack.org/election/ 16:59:26 Leaderless projects 16:59:33 #linkhttps://etherpad.opendev.org/p/2023.2-leaderless 16:59:35 #link https://etherpad.opendev.org/p/2023.2-leaderless 17:00:03 prepared the etherpad for leaderless projects please add your opinion there or any candidate you now for those projects 17:00:26 we are on time but I would like to extend it for 5-10 min to cover next topics. hoe it is ok for eveyrone 17:00:30 We can drop tripleo right away 17:00:44 TC Chair election 17:01:00 as election will be closed today, we need to start the TC chair election process 17:01:16 nomiantion process is listed here #link https://governance.openstack.org/tc/reference/tc-chair-elections.html#tc-chair-nomination 17:01:26 I am not planning to run for chair this cycle 17:01:40 anyone want to run for Chair please add your nomination 17:01:40 boo :( 17:01:45 gmann: thanks for all your service as chair! 17:02:00 As mentioned in my TC candidacy, I'm planning to run. 17:02:01 but i understand that your typing fingers may need a rest 17:02:04 gmann: you're the only one I know of who has a 28 hour day, it's not fair to ask us with only 24 hours to do it 17:02:12 Thanks for your work gmann 17:02:14 gmann: congratulations on the free time that I'm sure the QA project won't fill up immediately ;) 17:02:16 which will be open for 3 days after election are closed. I will calculate the exact time and let you all know 17:02:16 I love that we have a process for that now :) 17:02:25 knikolla[m]: perfect 17:02:26 gmann: thanks for your great work! 17:02:31 rosmaita: :) 17:02:53 JayF: true 17:02:55 thx gmann for all Your work as TC chair 17:03:07 yeah. that's quite a bummer 17:03:23 thanks everyone and I will continue Chair till we select the new CHair and also help in transition 17:03:32 but thatnks indeed, you did really awesome job 17:03:37 thanks again 17:03:40 one last topic 17:03:44 #topic Select time to discuss the 'Less Diversity' discussion with foundation staff (Jimmy) 17:04:03 this one we discussed in last meeting and agreed to have discussion in PTG 17:04:17 but Jimmy is not available in PTG, do we want to do this discussion before PTG or after PTG ? 17:04:42 this is not urgent things to sovle but very important to continue the discussion 17:04:50 the foundation staff are all in a week of in-person meetings 17:04:53 Need to get to next thing on my calendar 17:05:02 i think we were also going to start referring to it as "Need More Diversity" ? 17:05:07 Should we lump in the discussion that TheJulia was requesting above, too? 17:05:11 I think we all will be busy pre-PTG 17:05:18 jimmy mentioned that allison should be able to be ther eat the ptg 17:05:18 If we're setting aside time for foundation-adjacent discussions 17:05:39 what diversity and inclusion issues did you want to discuss? 17:05:39 rosmaita: oh, I think I changed that but i thnk in my weekly sumamry ? I will do 17:05:49 :) 17:05:54 it is for diversity thing 17:06:06 fungi: diversity of contributing companies 17:06:12 yeah that one 17:06:22 rosmaita: and maybe "creating a diverse environment where diversity flourishes" 17:06:27 yes, i will be there 17:06:33 we can do post-PTG also or in PTG with allison from staff ? 17:06:38 please just let me know once that specific time slot is scheduled so I can make sure I am there. 17:06:40 * TheJulia blinks at aprice[m] joining suddenly 17:06:43 aprice[m]: cool 17:06:47 :) 17:07:16 let's do it PTG and I will inform Jimmy, aprice[m] about exact time once we finalized that 17:07:20 oh, a ptg session on increasing diversity of contributing organizations in openstack projects? 17:07:38 ack 17:07:44 fungi: a discussion about feedback the foundation supposedly has for us 17:07:50 thanks, i misunderstood, thought you had concerns about diversity of ptg attendance 17:07:56 fungi: remember, you suggested jimmy? 17:08:01 no 17:08:08 no, it was what from we discussed in baord sync up call 17:08:30 fungi: seems you need more coffee like me :) 17:08:39 * TheJulia could also use more coffee 17:08:59 anyways. skipping 'Recurring tasks check' and 'Open Reviews' topic and let's close the meeting 17:09:14 thanks everyone for joining 17:09:15 thx :) 17:09:21 #endmeeting