16:00:06 <gmann> #startmeeting tc
16:00:06 <opendevmeet> 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 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <opendevmeet> The meeting name has been set to 'tc'
16:00:09 <gmann> #topic Roll call
16:00:10 <JayF> o/
16:00:13 <gmann> o/
16:00:14 <noonedeadpunk> o/
16:00:14 <TheJulia> o/
16:00:33 <knikolla[m]> o/
16:00:46 <dansmith> o/
16:00:58 <bauzas> \o /me sits again at the back :)
16:01:35 <gmann> let's wait for couple of min if other tc-members joining
16:01:47 * mnaser sits at the side
16:01:57 <gmann> meanwhile this is today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
16:02:35 <gouthamr> o/
16:03:05 <rosmaita> o/
16:03:12 <gmann> let's start
16:03:16 <gmann> #topic Follow up on past action items
16:03:26 <gmann> #link https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-15-16.00.html
16:03:33 <gmann> two action item from previous meeting
16:03:37 <gmann> noonedeadpunk to add PyPi access policy in governance documentation
16:03:43 <slaweq> o/
16:03:46 <noonedeadpunk> I've pushed 2 patches as of today - https://review.opendev.org/q/topic:tc%252Fopenstackci_pypi
16:04:05 <JayF> 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 <noonedeadpunk> I'm also looking at project-team-guide for place where to better mention this requirement
16:04:20 <JayF> 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 <spotz[m]> o/
16:04:24 <noonedeadpunk> Aha
16:04:42 <JayF> 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 <gmann> sure, that will be helpful, we can make depends-on on JayF patch and modify the governance in parallel on policy
16:05:55 <gmann> thanks noonedeadpunk for pushing those, let's review those
16:06:17 <gmann> 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 <gmann> 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 <gmann> #action gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job
16:07:01 <gmann> topic Gate health check
16:07:05 <gmann> #topic Gate health check
16:07:12 <gmann> any better news on gate?
16:07:19 <noonedeadpunk> timouts still happening
16:07:20 <dansmith> my summary is "slightly better than last week"
16:07:27 <dansmith> but still quite poor
16:07:37 <slaweq> last week wasn't good for sure
16:07:40 <gmann> few timeout are gone but yes it still happening
16:07:48 <dansmith> noonedeadpunk: I've seen fewer (I think) but agree, it's still happening way too often
16:07:54 <slaweq> I also see that in number of rechecks needed to get something merged - gates weren't stable
16:08:21 <bauzas> thanks for the hard efforts on tempest folks !
16:08:34 <noonedeadpunk> Well, yes, I agree it's better, but far from perfect.
16:08:36 <dansmith> slaweq: noonedeadpunk do you two see the volume test failures in your gates?
16:08:40 <dansmith> I'm not sure what you run compared to us
16:08:48 <gmann> 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 <dansmith> I've been trying to fix cinder tests that I find
16:08:55 <bauzas> I wish I could have metrics to share about rechecks
16:09:14 <bauzas> and yeah, cirros-0.6.1 is creating a few issues that need to be addressed
16:09:23 <slaweq> dansmith in Neutron we are running "integrated-networking" tests so no cinder related tests theere
16:09:31 <dansmith> slaweq: okay
16:09:35 <JayF> I now wonder if some of the seemingly-random ironic failures this week were potentially cirros related.
16:09:44 <bauzas> slaweq: but we have sometimes some dhcp problems in the gate
16:09:50 <noonedeadpunk> dansmith: no we run jsut couple of default integrational scenarios, so didn't see anything to off with cinder
16:09:52 <TheJulia> JayF: the failures over the last day after say 8am yesteday are all it
16:09:53 <fungi> is the ovn fix in jammy-updates yet or still only in -proposed?
16:09:58 <bauzas> the client doesn't get the lease in time
16:10:01 <JayF> TheJulia: ack; ty for the detail
16:10:11 <noonedeadpunk> we also don't run devstack, so...
16:10:12 <gmann> dhcp problem was due to cirros, which should be fixed now
16:10:17 <bauzas> after 3 retries, each after 1 min
16:10:18 <slaweq> bauzas can You point me to the failed job with such dhcp issue?
16:10:20 <gmann> bauzas: feel free to recheck now
16:10:32 <bauzas> gmann: because of a cirros upgrade ?
16:10:37 <dansmith> yeah
16:10:39 <gmann> bauzas: yes
16:10:43 <slaweq> regarding cirros 0.6.1 I recently added support for dhcpcd in tempest
16:10:46 <slaweq> it's merged
16:11:11 <TheJulia> 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 <slaweq> 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 <dansmith> well, there are the usual dhcp issues, and the recent ones I think
16:11:37 <bauzas> slaweq: sec, I have a patch up for Nova
16:11:37 <gmann> but volume detach things are big blocker now a days
16:11:51 <dansmith> 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 <TheJulia> dansmith: yeah, they need to be delienated if at all possible :)
16:11:58 <dansmith> right
16:12:41 <TheJulia> my impression and the longer term class is "not configured in time"
16:12:44 <gmann> 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 <bauzas> we tried to test cirros-0.6 with dhcpcd https://review.opendev.org/c/openstack/nova/+/873934
16:13:19 <gmann> that should work
16:13:23 <dansmith> 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 <bauzas> slaweq: this is the bug report we use for tracking the dhcp lease issues https://bugs.launchpad.net/nova/+bug/2006467
16:13:39 <gmann> anywyas let's take this to qa channel after meeting as we have many other topics to discuss today ?
16:13:47 <TheJulia> dansmith: indeed
16:13:50 <gmann> bauzas: thanks, that is helpful
16:13:58 <gmann> any other gate things?
16:14:16 <fungi> is the ovn fix in jammy-updates yet or still only in -proposed?
16:14:56 <fungi> just wondering if nova was still running into those failures too
16:15:05 <dansmith> which ovn fix?
16:15:07 <gmann> which one? slaweq  do you know?
16:15:32 <slaweq> nope
16:15:40 <gmann> fungi: any link please?
16:15:43 <fungi> the one last week which fnordahl pushed an sru for
16:16:05 <fungi> i'd have to dig the lp link out of the nova channel
16:16:07 <slaweq> so I probably missed it, most likely ralonsoh will know
16:16:20 <ralonsoh> let me read first
16:16:37 <bauzas> fungi: hmm, sorry, I remember-ish that without context
16:16:43 <gmann> ok, let's check/talk on nova or qa channel about that
16:16:50 <bauzas> that does ring a bell, but a small one
16:17:04 <fungi> sorry, ovs
16:17:08 <fungi> #link https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/2003060
16:17:10 <bauzas> yup, openstack-qa seems a good place to discuss to me
16:17:24 <gmann> yeah, let's move to next topic
16:17:28 <gmann> #topic Discussion of "Add guidelines about naming versions of the OpenStack projects"
16:17:40 <gmann> #link https://review.opendev.org/c/openstack/governance/+/874484
16:18:09 <gmann> 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 <JayF> 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 <gmann> 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 <JayF> For reasons that are partially my fault; it turned into a conversation about "standalone ironic" which was not my intention
16:19:01 <gmann> JayF: has some updates suggestion on that ^^
16:19:46 <TheJulia> 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 <gmann> 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 <gmann> 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 <JayF> 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 <TheJulia> I think that is totally reasonable. My concern comes up when an explicit single way mandate comes into play.
16:21:07 <gmann> I suggest that two option in that patch becuase using release version '2023.1' without 'openstack' word  seems odd
16:21:19 <bauzas> 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 <noonedeadpunk> I think we still should omit having cooredinated release but for projects with independant release model at very least
16:21:29 <TheJulia> JayF: absolutely agree, there are defintely related discussions occuring in the thread
16:21:38 <noonedeadpunk> As coordinated release is simply not applicable for it
16:22:08 <bauzas> a coordinated release implies that we ensure all our projects are tested between themselves, even the standalone ones
16:22:10 <dansmith> noonedeadpunk: meaning make the doc say "independent release projects should omit the OpensStack 2023.1 part" ?
16:22:14 <JayF> 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 <knikolla[m]> 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 <gmann> noonedeadpunk: but you mean standalone project to move to intendent release model too ?
16:22:51 <bauzas> but people can start consuming a project and after that integrating it with other projects
16:23:02 <knikolla[m]> There's also the fact that the integrated release name is on the url path of the docs
16:23:08 <noonedeadpunk> dansmith: well, you don't really know part of what they are?
16:23:25 <JayF> 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 <gmann> yes, removing integrated release version completly is hard
16:23:32 <dansmith> noonedeadpunk: I'm asking if you're suggesting drawing the line at "independent release or not"
16:23:32 <noonedeadpunk> For exemple - they can have last release 2 years ago
16:24:21 <noonedeadpunk> 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 <slaweq> noonedeadpunk like Tripleo for example :)
16:24:34 <noonedeadpunk> dansmith: but they still can/should be mentioned on releases page
16:24:49 <gmann> but ironic is independent release model or coordinated ?
16:24:57 <TheJulia> cycle with intermediacy
16:24:58 <noonedeadpunk> slaweq: I was thinking more about tempest or oslo, but yeah... :D
16:25:02 <dansmith> 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 <dansmith> yeah, cycle-with-intermediate is what I meant ^
16:25:18 <gmann> then mentioning only about independent release does not solve ironic case right?
16:25:23 <noonedeadpunk> dansmith: yeah, sure
16:25:35 <dansmith> gmann: correct, but I think that's what noonedeadpunk is suggesting
16:25:38 <JayF> 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 <JayF> And I would not be in favor of a different change that drew that line.
16:25:58 <gmann> standalone vs non-standalone is right thing to suggest?
16:26:01 <dansmith> 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 <dansmith> value in consistency
16:26:33 <gmann> consistency is the key and from where these guidelines requirement came from
16:27:06 <TheJulia> 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 <gmann> 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 <dansmith> 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 <TheJulia> 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 <noonedeadpunk> 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 <spotz[m]> Could we refer to other projects by release or tag?
16:28:27 <mnaser> consistency is super important
16:28:29 <gmann> spotz[m]: tag? tag are release version for projects
16:28:33 <bauzas> +1
16:29:00 <TheJulia> consistency is important, but to be consistent one has to be mindful of their audience
16:29:05 <bauzas> 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 <bauzas> project A* my bad
16:29:15 <JayF> 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 <mnaser> 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 <TheJulia> 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 <TheJulia> mnaser: that is one of the feedback items we tend to get
16:30:07 <mnaser> "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 <mnaser> well maybe educating those people might be the way to go rather than dodging the whole thing
16:30:27 <TheJulia> and that is a whole perception issue which is... differnet
16:30:31 <knikolla[m]> I just want to call out that the conversation is devolving.
16:30:37 <TheJulia> knikolla[m]: indeed!
16:30:42 <dansmith> 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 <knikolla[m]> And we're not discussing the item at hand.
16:30:51 <TheJulia> we should stick to the topic at hand, how projects should refer to other projects.
16:31:05 <knikolla[m]> 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 <JayF> 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 <dansmith> 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 <noonedeadpunk> JayF: but would suffixing openstack version isntead of prefixing it solve your issue?
16:31:33 <mnaser> 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 <gmann> 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 <knikolla[m]> 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 <gmann> it is hard to separate the things
16:31:49 <JayF> 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 <dansmith> knikolla[m]: consensus where
16:31:52 <mnaser> its frustrating enoguh opening releases.openstack.org all the time because i have no idea what release nova 23 is.
16:32:07 <dansmith> mnaser: I feel the same :)
16:32:08 <noonedeadpunk> mnaser: well, I think that's why we have https://releases.openstack.org/antelope/index.html
16:32:10 <bauzas> ++
16:32:18 <dansmith> mnaser: I work on nova and I don't even know what nova version numbers match up to anything :D
16:32:20 <gmann> mnaser: right, I do check for tempest also many time even I do releaase for it :)
16:32:23 <TheJulia> 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 <noonedeadpunk> Which must be source of truth kind of for integration between components
16:32:33 <mnaser> pip freeze in an env?
16:32:39 <bauzas> it even takes me 0.5secs to remember the nova release number for every cycle when I write the relnotes
16:32:47 <TheJulia> well... that is a *whole* different issue then
16:32:55 <knikolla[m]> 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 <bauzas> this is taking too much brain cycles to calculate this in my mind
16:33:02 <mnaser> no because now i will end up on the ironic 19.0.0 release page docs
16:33:06 <mnaser> and i will have no idea what version of openstack it is
16:33:10 <dansmith> 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 <gmann> do we have any other stanadalone project case here and what they thing?
16:33:40 <dansmith> knikolla[m]: I don't think you're reading that right ;)
16:33:57 <JayF> 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 <gmann> are they also feel having openstack version in doc confuse users?
16:34:19 <knikolla[m]> dansmith: then apologies for that. i will go and read it again.
16:34:28 <noonedeadpunk> To be frank - for me some middle ground would be making main focus on project version and reference openstack version afterwards
16:34:43 <gmann> noonedeadpunk: that is ok if that solve the issue
16:34:52 <noonedeadpunk> So instead saying `OpenStack 2023.1 (Nova 27.0.0)` we can do `Nova 27.0.0 (OpenStack 2023.1)`
16:35:00 <gmann> we had that option in pTG discussion
16:35:04 <JayF> noonedeadpunk: that was essentially my original proposal
16:35:12 <JayF> noonedeadpunk: if you look at Patchset 1, per your original suggestion
16:35:22 <JayF> at this point; I think I prefer my current patchset to that one though
16:35:28 <noonedeadpunk> And I'm not sure where all this fuss about ironic and distantiation from openstack has come from...
16:35:43 <bauzas> noonedeadpunk: I strongly dislike mentioning the nova release number before the openstack release
16:35:55 <noonedeadpunk> oh?
16:36:00 <gmann> JayF: no. proposal; in PS1 was "Nova 2023.1 Series (27.X.Y)"
16:36:06 <bauzas> and I'll encourage my projects contributors to always refer to the openstack release
16:36:25 <dansmith> gmann: right, which is incorrect, because the nova version is not 2023.1
16:36:34 <TheJulia> 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 <bauzas> yeah it's a meaningless 27.0.0
16:36:36 <JayF> gmann: ack; that's fair
16:36:43 <TheJulia> at which point, a higher level discussion is truly needed to validate perceptions
16:36:54 <bauzas> which needs you need to calculate how many nova releases you got since Austin
16:37:05 <bauzas> and for Neutron this is weirder
16:37:09 <noonedeadpunk> 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 <gmann> so we need to solve standalone case and how standalone projects can consume both version for both cases
16:37:24 <bauzas> you have to take in account this was incepted later as a Quantum project, somewhere in Essex release
16:37:31 <gmann> and I think talking to few more standalone projct will give us more clarity now
16:37:48 <JayF> 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 <noonedeadpunk> bauzas: so basically you're saying that "Nova 2023.1 Series (27.X.Y)" would be good for you?
16:38:04 <TheJulia> Folks, there are several different issues at play here, each one is a separate discussion.
16:38:09 <JayF> 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 <bauzas> 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 <spotz[m]> It seems to me this topic is a larger issue needing further discussion and maybe a wider audience
16:38:22 <JayF> This is the focus of my patch; none of this larger picture stuff
16:38:25 <dansmith> noonedeadpunk: not fine with me
16:38:25 <gmann> noonedeadpunk: that is too confusing
16:38:40 <noonedeadpunk> gmann: dansmith I'm just trying to understand
16:38:46 <gmann> k
16:38:55 <dansmith> 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 <bauzas> noonedeadpunk: pesonnally, I think 50% of the users probably misunderstand the different projects we have
16:39:09 <dansmith> 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 <noonedeadpunk> bauzas: I think we're jsut talking now where to place coordinated release and where project version
16:39:23 <bauzas> noonedeadpunk: mentioning the project first seems always weird to me
16:39:31 <JayF> 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 <mnaser> i think this small change is contextual out of a larger context
16:39:45 <gmann> 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 <dansmith> JayF: roger that
16:39:53 <JayF> No; I am not OK with that gmann
16:40:07 <JayF> 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 <JayF> and starting of Bobcat ycle
16:40:36 <JayF> 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 <mnaser> well
16:40:54 <mnaser> then the tc votes
16:40:59 <mnaser> and then we can discuss in the ptg again
16:41:06 <gmann> sure, that work fine
16:41:06 <mnaser> and then we revert all the release notes if we decide agaisnt it
16:41:07 <noonedeadpunk> 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 <mnaser> oops, im not part of the tc, but thats what i was thinking
16:41:23 <spotz[m]> Hehe
16:41:33 <noonedeadpunk> I don't care much what would be first though as it looks quite insufficient for me
16:41:40 <gmann> no it is ok to vote on proposal and if still objection on results we can discus in PTG
16:41:41 <rosmaita> mnaser: you are tc-emeritus, i think
16:41:54 <spotz[m]> He is
16:42:03 <mnaser> i am but i'm running off with it as a tc-member :)
16:42:16 <bauzas> noonedeadpunk: fwiw we pin our RPC versions with the openstack release name, so...
16:42:16 <mnaser> 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 <mnaser> and then anything can be easily reverted
16:42:56 <noonedeadpunk> bauzas: but error out with ID in case of mismath :p
16:43:01 <bauzas> 27.0.0 is only an openstack/releases number that very insightful people know :p
16:43:02 <gmann> tc-members: all ok with that and vote means vote on gerrit right?
16:43:05 <dansmith> 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 <gmann> if any tc members want to ready the patch/conversation
16:43:37 <dansmith> gmann: yep, sounds like it
16:43:50 <gmann> yeah. let's vote on patch and in next video call we take decision if still not concluded on gerrit?
16:43:54 <noonedeadpunk> 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 <slaweq> gmann +1
16:44:28 <gmann> 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 <JayF> 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 <gmann> JayF: it works for you?
16:44:54 <mnaser> JayF: you're not the only one that has been doing openstack and only openstack :)
16:44:55 <JayF> gmann: sure
16:45:01 <gmann> ok
16:45:04 <mnaser> but some of us here do more than just one project and _have_ to know the big context
16:45:10 <JayF> mnaser: I know, I just think some folks are reading bad motives into things here, and there are none
16:45:18 <gmann> moving next, as we are running out of time
16:45:32 <mnaser> 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 <mnaser> :)
16:45:45 <TheJulia> But context here may be entirely different from outside this channel
16:46:11 <gmann> 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 <gmann> #topic TC 2023.1 tracker status checks
16:46:22 <gmann> #link https://etherpad.opendev.org/p/tc-2023.1-tracker
16:46:42 <gmann> I will skip this one but please do check your assigned itme as we are approaching to cycle end
16:47:50 <gmann> #topic Deprecation process for TripleO
16:48:05 <noonedeadpunk> we're full of hot topics todya, huh
16:48:26 <gmann> 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 <knikolla[m]> starting the new tc term with fireworks
16:48:47 <gmann> james mentioned he will check it in tripleO team and get back to TC
16:49:03 <gmann> but no response yet so I will say let's wait and I will ping them again
16:49:13 <gmann> knikolla[m]: noonedeadpunk  :)
16:49:42 <gmann> anything else anyone want to discuss on this ?
16:49:42 <dansmith> 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 <gmann> hope so but not sure what tripleo plan is
16:50:25 <JayF> 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 <JayF> It'd be a good way to get tripleo users on OSA/KA/et
16:50:35 <JayF> *etc
16:50:44 <noonedeadpunk> I think at very least we should provide them with guidance on deperecation process of master branch?
16:50:49 <gmann> its there on ML but i did not see anyone shown interest
16:50:52 <dansmith> JayF: meaning a plan to migrate tripleo users to something else like OSA?
16:51:06 <JayF> Yeah; some kind of off-ramp so they can keep using openstack-blessed deployment methods
16:51:10 <JayF> even with tripleo being retired
16:51:13 <noonedeadpunk> I'm kind of interested, but lacking time right now
16:51:25 <gmann> noonedeadpunk: sure, let me ping them and we can give path forward for master at least
16:51:30 <noonedeadpunk> I think this is really good idea to be frank
16:51:36 <JayF> 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 <knikolla[m]> 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 <noonedeadpunk> And OSA has path wit husage of RDO packages
16:52:30 <gmann> let me check with Tripleo about zed maintenance and way to proceed on master if that is blocking them on something
16:52:49 <gmann> knikolla[m]: there is no xena. its wallaby and then zed tjhat is all confusion
16:52:57 <gmann> k moving to next topic?
16:53:00 <dansmith> 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 <noonedeadpunk> gmann: wait a sec
16:53:12 <JayF> 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 <gmann> k
16:53:13 <knikolla[m]> ah :/ right.
16:53:23 <dansmith> knikolla[m]: yeah, it's really messy :(
16:53:24 <bauzas> as a reminder, tripleo is a collection of repos
16:53:24 <noonedeadpunk> There's also a ML and PR regarding picking up some delivareables by Heat
16:53:44 <bauzas> maybe some have more interests for consumers than others
16:53:59 <gmann> noonedeadpunk: that config one? I did not see that yet but that will be great
16:54:07 <knikolla[m]> 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 <noonedeadpunk> 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 <gmann> noonedeadpunk: agree, any other project taking maaintainance of few thigns is good
16:54:35 <noonedeadpunk> #link https://review.opendev.org/c/openstack/governance/+/874719
16:54:36 <dansmith> knikolla[m]: that's my primary concern btw
16:54:36 <knikolla[m]> errr... maintainance... not support
16:54:40 <dansmith> knikolla[m]: what it means for our "reputation"
16:54:56 <gmann> noonedeadpunk: well we can move that deliverables form TripleO to heat and no deprecation thngs for that deliverbales
16:55:03 <dansmith> 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 <noonedeadpunk> ++
16:55:23 <gmann> we can do that before release things happen. I will check that right after the meeting
16:55:45 <knikolla[m]> dansmith: ++
16:55:48 <gmann> let's move next now
16:55:50 <gmann> #topic Cleanup of PyPI maintainer list for OpenStack Projects
16:55:55 <gmann> Etherpad for audit and cleanup of additional PyPi maintainers
16:56:03 <gmann> #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup
16:56:17 <gmann> ML discussion: #link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848.html
16:56:28 <gmann> JayF: any update on email template things ?
16:56:42 <gmann> I think its good to go now unless no objection on etherpad
16:56:44 <JayF> it exists; I think it's linked in there?
16:57:03 <JayF> #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template
16:57:09 <gmann> FYI, QA team reachout out to all additionla maintainers and they removed themself and given the ownership to openstackci
16:57:10 <JayF> it's not linked, but I'll add it now
16:57:24 <JayF> althoguh it's not really good to go until after my infra-manual change lands
16:57:34 <gmann> 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 <JayF> and it'll be able to be more strongly worded if we land noonedeadpunk's proposed policy
16:57:45 <gmann> ohk, will check after meeting
16:57:47 <JayF> I would suggest waiting; fungi has a +1 on my infra-manuals patch now
16:57:53 <JayF> so I suspect it's extremely close to landing
16:57:53 <gmann> ack
16:58:01 <JayF> we have little stannding to ask without hte policy being written
16:58:05 <noonedeadpunk> I will update my patch right after the meeting
16:58:10 <JayF> like, we can ask; but there's no power of TC-force to apply to it yet
16:58:10 <gmann> cool
16:58:12 <noonedeadpunk> I hope being able to predict URL :D
16:58:20 <gmann> JayF: sure
16:58:25 <gmann> thanks noonedeadpunk JayF
16:58:32 <gmann> moving to next topic
16:58:36 <gmann> #toic Election updates & post-election work
16:58:41 <gmann> #topic Election updates & post-election work
16:59:07 * gmann fingers are hurting by typing so much :)
16:59:13 <gmann> Election will be closed by today 23:45 UTC
16:59:17 <dansmith> gmann: suck it up chief!
16:59:22 <gmann> https://governance.openstack.org/election/
16:59:26 <gmann> Leaderless projects
16:59:33 <gmann> #linkhttps://etherpad.opendev.org/p/2023.2-leaderless
16:59:35 <gmann> #link https://etherpad.opendev.org/p/2023.2-leaderless
17:00:03 <gmann> prepared the etherpad for leaderless projects please add your opinion there or any candidate you now for those projects
17:00:26 <gmann> 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 <noonedeadpunk> We can drop tripleo right away
17:00:44 <gmann> TC Chair election
17:01:00 <gmann> as election will be closed today, we need to start the TC chair election process
17:01:16 <gmann> nomiantion process is listed here #link https://governance.openstack.org/tc/reference/tc-chair-elections.html#tc-chair-nomination
17:01:26 <gmann> I am not planning to run for chair this cycle
17:01:40 <gmann> anyone want to run for Chair please add your nomination
17:01:40 <dansmith> boo :(
17:01:45 <rosmaita> gmann: thanks for all your service as chair!
17:02:00 <knikolla[m]> As mentioned in my TC candidacy, I'm planning to run.
17:02:01 <rosmaita> but i understand that your typing fingers may need a rest
17:02:04 <dansmith> 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 <spotz[m]> Thanks for your work gmann
17:02:14 <JayF> gmann: congratulations on the free time that I'm sure the QA project won't fill up immediately ;)
17:02:16 <gmann> 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 <noonedeadpunk> I love that we have a process for that now :)
17:02:25 <gmann> knikolla[m]: perfect
17:02:26 <knikolla[m]> gmann: thanks for your great work!
17:02:31 <gmann> rosmaita: :)
17:02:53 <gmann> JayF: true
17:02:55 <slaweq> thx gmann for all Your work as TC chair
17:03:07 <noonedeadpunk> yeah. that's quite a bummer
17:03:23 <gmann> thanks everyone and I will continue Chair till we select the new CHair and also help in transition
17:03:32 <noonedeadpunk> but thatnks indeed, you did really awesome job
17:03:37 <gmann> thanks again
17:03:40 <gmann> one last topic
17:03:44 <gmann> #topic Select time to discuss the 'Less Diversity' discussion with foundation staff (Jimmy)
17:04:03 <gmann> this one we discussed in last meeting and agreed to have discussion in PTG
17:04:17 <gmann> but Jimmy is not available in PTG, do we want to do this discussion before PTG or after PTG ?
17:04:42 <gmann> this is not urgent things to sovle but very important to continue the discussion
17:04:50 <fungi> the foundation staff are all in a week of in-person meetings
17:04:53 <spotz[m]> Need to get to next thing on my calendar
17:05:02 <rosmaita> i think we were also going to start referring to it as "Need More Diversity" ?
17:05:07 <JayF> Should we lump in the discussion that TheJulia was requesting above, too?
17:05:11 <gmann> I think we all will be busy pre-PTG
17:05:18 <clarkb> jimmy mentioned that allison should be able to be ther eat the ptg
17:05:18 <JayF> If we're setting aside time for foundation-adjacent discussions
17:05:39 <fungi> what diversity and inclusion issues did you want to discuss?
17:05:39 <gmann> rosmaita: oh, I think I changed that but i thnk in my weekly sumamry ? I will do
17:05:49 <rosmaita> :)
17:05:54 <gmann> it is for diversity thing
17:06:06 <dansmith> fungi: diversity of contributing companies
17:06:12 <gmann> yeah that one
17:06:22 <TheJulia> rosmaita: and maybe "creating a diverse environment where diversity flourishes"
17:06:27 <aprice[m]> yes, i will be there
17:06:33 <gmann> we can do post-PTG also or in PTG with allison from staff ?
17:06:38 <aprice[m]> 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 <gmann> aprice[m]: cool
17:06:47 <aprice[m]> :)
17:07:16 <gmann> let's do it PTG and I will inform Jimmy, aprice[m] about exact time once we finalized that
17:07:20 <fungi> oh, a ptg session on increasing diversity of contributing organizations in openstack projects?
17:07:38 <aprice[m]> ack
17:07:44 <dansmith> fungi: a discussion about feedback the foundation supposedly has for us
17:07:50 <fungi> thanks, i misunderstood, thought you had concerns about diversity of ptg attendance
17:07:56 <dansmith> fungi: remember, you suggested jimmy?
17:08:01 <dansmith> no
17:08:08 <gmann> no, it was what from we discussed in baord sync up call
17:08:30 <gmann> fungi: seems you need more coffee like me :)
17:08:39 * TheJulia could also use more coffee
17:08:59 <gmann> anyways. skipping 'Recurring tasks check' and 'Open Reviews' topic and let's close the meeting
17:09:14 <gmann> thanks everyone for joining
17:09:15 <slaweq> thx :)
17:09:21 <gmann> #endmeeting