| gmann | knikolla[m]: just a reminder in case you missed, we need to send agenda on ML for tomorrow meeting | 02:47 |
|---|---|---|
| *** promethe- is now known as prometheanfire | 02:47 | |
| knikolla[m] | gmann: thanks for the reminder. on it now. | 02:49 |
| gmann | knikolla[m]: thanks | 02:49 |
| *** ralonsoh_ is now known as ralonsoh | 07:36 | |
| bauzas | hey, we have our nova release notes summary patch being debated at the moment about the wording of a SLURP release vs. a non-SLURP | 09:51 |
| bauzas | context : https://review.opendev.org/c/openstack/nova/+/875380/3/releasenotes/notes/antelope-prelude-4a99907b00e739f8.yaml#7 | 09:52 |
| bauzas | it occurs to me by reading https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html#example-sequence that 2023.1 *is* a SLURP release | 09:52 |
| bauzas | but the controversy is : if we claim that 2023.1 is a skip-level-upgrade release, then it would imply that we *should* guarantee upgrade from yogza | 09:54 |
| bauzas | accordingly, 2023.1 can not be a SLURP release | 09:55 |
| bauzas | but, | 09:55 |
| bauzas | I personnally stand on point #1 (Testing) of the resolution that says "we will also test and guarantee that upgrades between two “SLURP” releases are supported." | 09:55 |
| bauzas | which implicitely assume that despite 2023.1 is a SLURP release, we can't guarantee a skip-level-upgrade from Yoga since Yoga *isn't* a SLURP release | 09:56 |
| bauzas | thoughts on it ? | 09:56 |
| bauzas | I'd tend to say that the TC resolution may require a bit of clarification about the expectations of a 'SLURP release' | 09:56 |
| opendevreview | sean mooney proposed openstack/governance master: clarify wording in release cadence resolution https://review.opendev.org/c/openstack/governance/+/875853 | 10:06 |
| bauzas | heh, that's the controversy discussed ^ | 10:07 |
| *** ralonsoh__ is now known as ralonsoh | 10:18 | |
| opendevreview | sean mooney proposed openstack/governance master: clarify wording in release cadence resolution https://review.opendev.org/c/openstack/governance/+/875853 | 10:23 |
| opendevreview | Jake Yip proposed openstack/governance master: Fix doc referencing 'admin_api' rule https://review.opendev.org/c/openstack/governance/+/875860 | 10:23 |
| dansmith | bauzas: I think it's clear in the resolution that "between SLURP releases" implies that you need two of them | 14:46 |
| dansmith | bauzas: I'd be fine with an extra sentence to clarify that, and/or make it clear that yoga was not designated as such, or something | 14:46 |
| dansmith | I'm not in favor of blowing up the terminology as proposed :) | 14:46 |
| bauzas | dansmith: yup, indeed | 14:47 |
| bauzas | that's my point | 14:47 |
| bauzas | I understand we can say that 2023.1 is a SLURP release but it's not a possible skip-level-upgrade :) | 14:48 |
| dansmith | right | 14:48 |
| knikolla[m] | Indeed you need 2 SLURPS to SLURP between SLURPS :) | 15:06 |
| dansmith | knikolla[m]: +1 for adding that to the resolution :) | 15:07 |
| fungi | this is also sort of why yoga to 2023.1 is a "dress rehearsal" for it. we're testing somewhat that it works, just not guaranteeing it | 15:07 |
| bauzas | yeah, I told this in our prelude section in Nova : it will be an experimental rolling-upgrade for Yoga computes https://review.opendev.org/c/openstack/nova/+/875380/3/releasenotes/notes/antelope-prelude-4a99907b00e739f8.yaml#7 | 15:18 |
| bauzas | should work, but we are not guaranteeing it | 15:18 |
| tobias-urdin | if it's experimental then it's probably better to take the long road from yoga to 2013.1 then :) I need to write that up | 15:35 |
| bauzas | tobias-urdin: that's not really experimental, this is just the fact that our skip-level-upgrade job is not voting on the gate | 15:47 |
| bauzas | so I prefer to say 'unttested hence experimental' | 15:48 |
| dansmith | it's not really untested though | 15:48 |
| dansmith | "unsupported" is the right word I think | 15:48 |
| bauzas | we don't really have such of a support model upstream, the motto is more like "what's not tested is not supported" | 15:48 |
| dansmith | or "unsupported but probably works" | 15:49 |
| bauzas | yeah, sorry, I went too far | 15:49 |
| bauzas | TC folks can actually welcome to review our nova prelude section to weigh on the SLURP mentioning here https://review.opendev.org/c/openstack/nova/+/875380/3/releasenotes/notes/antelope-prelude-4a99907b00e739f8.yaml#7 | 15:50 |
| bauzas | btw. tc members, I see you have a zoom meeting in 10 mins, am i correct ? | 15:50 |
| knikolla[m] | bauzas: correct | 15:50 |
| bauzas | OK, I'll try to join and sit down close to the window | 15:53 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: Switch project and OpenStack versions in releases https://review.opendev.org/c/openstack/governance/+/875942 | 15:54 |
| noonedeadpunk | `evacuated instances will remain stopped on the destination host` o_O | 15:56 |
| gmann | I agree on those SLURP things, intension was to write it from 2023.1 to 2024.1 upgrade is supported. I think mentioning 2023.1 as first SLURP convey the same but I am ok to explicitly mention it in resolution if needed | 15:57 |
| knikolla[m] | #startmeeting tc | 16:01 |
| opendevmeet | Meeting started Wed Mar 1 16:01:02 2023 UTC and is due to finish in 60 minutes. The chair is knikolla[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'tc' | 16:01 |
| knikolla[m] | tc-members, please join on Zoom for weekly meeting | 16:01 |
| knikolla[m] | #topic Roll call | 16:01 |
| gmann | o/ | 16:01 |
| JayF | o/ | 16:01 |
| knikolla[m] | o/ | 16:01 |
| dansmith | o/ | 16:01 |
| noonedeadpunk | Would be great to have link as can't find it in mail | 16:01 |
| JayF | https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 | 16:01 |
| JayF | from https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 16:01 |
| bauzas | \o (sitting in the cave) | 16:02 |
| knikolla[m] | #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting | 16:02 |
| knikolla[m] | #link https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 | 16:02 |
| fungi | (it's also linked from the agenda, which is linked from the meetings.opendev.org schedule page) | 16:02 |
| knikolla[m] | #topic Follow up on past action items | 16:05 |
| gmann | #link https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-22-16.00.html | 16:05 |
| knikolla[m] | #topic Gate health check | 16:12 |
| gmann | #action gmann to prepare etherpad for grenade skip upgrade job testing process/data and send email asking required projects to add job | 16:12 |
| dansmith | rosmaita: https://review.opendev.org/c/openstack/tempest/+/875500 | 16:14 |
| dansmith | rosmaita: https://review.opendev.org/c/openstack/tempest/+/874700 | 16:14 |
| knikolla[m] | #link https://review.opendev.org/c/openstack/tempest/+/875500 | 16:14 |
| knikolla[m] | #link https://review.opendev.org/c/openstack/tempest/+/874700 | 16:14 |
| spotz[m] | Having connection issues | 16:16 |
| knikolla[m] | no worries spotz | 16:17 |
| dansmith | rosmaita: https://review.opendev.org/c/openstack/tempest/+/873653 | 16:20 |
| knikolla[m] | #link https://review.opendev.org/c/openstack/tempest/+/873653 | 16:20 |
| bauzas | was enabled in nova ceph job https://review.opendev.org/c/openstack/nova/+/874664 | 16:21 |
| knikolla[m] | #link https://review.opendev.org/c/openstack/nova/+/874664 | 16:21 |
| knikolla[m] | #topic Discussion on uwsgi alternative and if we should define wsgi standard server in PTI | 16:22 |
| spotz[m] | I can’t get back in. I’ll keep trying | 16:22 |
| knikolla[m] | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032345.html | 16:23 |
| bauzas | dansmith: fwiw, I did run logsearch on our previous job runs we have and I can say it definitely fixes the oom issue :) | 16:23 |
| knikolla[m] | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032369.html | 16:23 |
| bauzas | well, | 16:30 |
| bauzas | we only really care of WSGI servers that support paste pipelines | 16:31 |
| bauzas | that's our real requirement | 16:31 |
| JayF | > if you attempt to import uwsgi and receive an ImportError you’re not running under uWSGI. | 16:37 |
| JayF | Seems like if we can run any tests at all without uwsgi, we don't have a hard dep on it. | 16:37 |
| JayF | #link https://uwsgi-docs.readthedocs.io/en/latest/PythonModule.html | 16:37 |
| jamespage | its not widely used | 16:37 |
| jamespage | #link https://codesearch.opendev.org/?q=import%20uwsgi&i=nope&literal=nope&files=&excludeFiles=&repos= | 16:37 |
| jamespage | and largely looks opportunistically imported | 16:38 |
| JayF | https://opendev.org/airship/armada/src/branch/master/armada/handlers/metrics.py#L152 is an example of a hard dep, but it's not an openstack project | 16:38 |
| JayF | but that's the pattern to look out for, an import uwsgi w/o a try | 16:38 |
| jamespage | agreed | 16:38 |
| JayF | might be worth just emailing the list and mentioning this explicitly | 16:38 |
| knikolla[m] | #topic Discussion of "Add guidelines about naming versions of the OpenStack projects" | 16:40 |
| bauzas | I honestely think this notation is bad "The OpenStack 2023.1 (Nova 27.0.0)" https://review.opendev.org/c/openstack/nova/+/875380/3/releasenotes/notes/antelope-prelude-4a99907b00e739f8.yaml#3 | 16:46 |
| bauzas | I'd rather say 'The OpenStack Nova 2023.1 release does this." | 16:47 |
| dansmith | me too | 16:47 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: Switch project and OpenStack versions in releases https://review.opendev.org/c/openstack/governance/+/875942 | 16:47 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: Switch project and OpenStack versions in releases https://review.opendev.org/c/openstack/governance/+/875942 | 16:51 |
| JayF | https://docs.openstack.org/releasenotes/ironic/zed.html specifically says "Zed Series (a.b.c - x.y.z.)" on the header. With the new guidelines, it'd be "OpenStack 2023.1 (Ironic a.b.c - x.y.z)". | 16:59 |
| knikolla[m] | #endmeeting | 17:00 |
| opendevmeet | Meeting ended Wed Mar 1 17:00:08 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-01-16.01.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-01-16.01.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-01-16.01.log.html | 17:00 |
| jamespage | thanks knikolla[m] | 17:00 |
| JayF | rosmaita might be right that it's not that significant of a difference. | 17:00 |
| knikolla[m] | thanks all :) | 17:00 |
| gmann | knikolla[m]: I think i missed it in adding agenda but leaderless projects is something we need to work on, will be good to have it in agenda so that we do not forget https://etherpad.opendev.org/p/2023.2-leaderless | 17:10 |
| bauzas | a bit of an hard thought, but it looks like pep440 allows us to define final releases that differ thru a single bit which is an epoch | 17:15 |
| bauzas | https://peps.python.org/pep-0440/#final-releases | 17:15 |
| bauzas | so, technically, OpenStack Nova 2023.1.0.0 may exist but also OpenStack Ironic 2023.1!1.0.0 or other cycle-with-intermediary project | 17:16 |
| bauzas | which governance reference should I amend for letting the TC vote on it ? | 17:16 |
| bauzas | I guess https://governance.openstack.org/tc/reference/release-naming.html | 17:17 |
| gmann | bauzas: yes this is the one | 17:18 |
| * bauzas goes writing a third alternative proposal | 17:18 | |
| noonedeadpunk | bauzas: I'm just really not sure about adding epoch to date-based ones... While I don't see it being prohibited anywhere and it kind of passes regexp, but that is not mentioned as supported either | 17:37 |
| fungi | in the past we explicitly avoided epochs. they significantly complicate things, and may not do what you think they do (they're typically a "hidden" part of the version number, not meant to be displayed and only for handling disjoint in version series where you need to sort them non-sequentially) | 17:38 |
| noonedeadpunk | as mix of date with epoch is confusing at the first place... But overall I do like syncing of versions across all projects | 17:38 |
| bauzas | noonedeadpunk: that's a reasonable concern which can be addressed by testing to build a toy project | 17:39 |
| fungi | it's also funny that we're coming full-circle, back to synchronized date-based versions across projects which we intentionally stopped doing because of specific problems it created | 17:40 |
| bauzas | fungi: I don't disagree with your point, but I'm trying to address the need for a specific release tagging of projects with cycle-with-intermediary model that would be consistent with other projects if we were using the same version numbret | 17:40 |
| bauzas | number* | 17:40 |
| fungi | i wonder if it's because the people who experienced those problems are mostly no longer around and the reasons have been forgotten, or they're still here but have concluded that the solution was worse than the problems | 17:40 |
| * noonedeadpunk not aware of these reasons | 17:40 | |
| bauzas | fungi: my overall point is that I'd like us to get rid of the project-based numbers that don't help a bit | 17:41 |
| bauzas | like I voiced a couple of times since last week, nova 27.0.0 is meaningless to a lot of consumers | 17:41 |
| noonedeadpunk | And I'm completey not in agreement with that ^ | 17:42 |
| fungi | one of the main problems was that projects don't make point releases in lock-step, and users were getting confused that nova 2013.2.1 had to be used with cinder 2013.4.3 | 17:42 |
| fungi | giving them completely distinct versioning made it clearer that they did not release in lock-step | 17:42 |
| bauzas | noonedeadpunk: if I was providing you a openstack-nova-2023.1.0.0 wouldn't that rather help you more ? | 17:42 |
| noonedeadpunk | I hope it's not gonna be all package name :D | 17:43 |
| JayF | bauzas: does your proposal completely abandon the concept of semver? | 17:43 |
| bauzas | JayF: I hope not | 17:43 |
| fungi | another reason was the adoption of semver signalling, and libraries needing to be able to increase the major version number possibly more than once a year | 17:43 |
| JayF | I don't see how a cycle-with-intermediary project could have a major version bump between cycle-releases in this proposal | 17:43 |
| noonedeadpunk | yeah, valid point ^ | 17:45 |
| noonedeadpunk | actually both of them... | 17:45 |
| fungi | it's worth noting that we transitioned off of date-based versions approximately a decade ago, so possible that the problems we experienced with year-based versioning and synchronized major version numbers back then are not problems now, but i would be surprised | 17:45 |
| dansmith | fungi: well, pep440 is certainly a detail that changes some of the calculus now | 17:46 |
| fungi | this is clearly a chesterton's fence situation, and people who want to change the version process very much need to do the research to identify and counter all the reasons we stopped doing it last time | 17:46 |
| bauzas | JayF: if a cycle-with-intermediary project starts saying 2023.1!1 it would be a final release | 17:46 |
| bauzas | JayF: and 2023.1!2 would be a distinct final release | 17:47 |
| dansmith | bauzas: although pep440 doesn't seem to allow a dot in the epoch right/ | 17:47 |
| JayF | fungi: thank you for teaching me the term 'chesterton's fence' | 17:47 |
| bauzas | fungi: I assume having opened a can of worms and I can do some lecture before updating my patch | 17:47 |
| fungi | also, probably worth bringing up on the upcoming call with foundation account management, since one thing i recall jimmy saying is that the most common complaint he hears is that the openstack community needs to stop changing things like release numbering schemes because it's the lack of stability for stuff like that which makes openstack adoption harder | 17:48 |
| bauzas | s/updating/uploading | 17:48 |
| bauzas | fungi: what makes adoption difficult IMHO is that our project version numbers diff | 17:48 |
| bauzas | differ* | 17:48 |
| bauzas | like, I don't know top of my head which neutron release can work with nova 26.0.0 | 17:49 |
| fungi | yes, if we could combine openstack into a single product and synchronize all releasing of all of it then that would probably make things simpler. if we can't do that, then partially synchronizing things just leads to more confusion because users are going to assume synchronization which isn't there | 17:49 |
| JayF | I've dedicated a nontrivial amount of my time since working at this current job on trying to figure out how to drive openstack adoption and some of the reasons that stopped it. None of the high level conversations I've had in that context have involved confusing versioning as a concern; in fact, I've gotten more concerning comments from users who are confused by our recent | 17:50 |
| JayF | "letter-name -> date-based-version-name" conversion | 17:50 |
| JayF | It's hard for me to imagine a new scheme being better-enough to be worth another round of churn. | 17:50 |
| dansmith | especially this close to the previous one, I agree | 17:51 |
| bauzas | OK, then I withdraw my proposal | 17:52 |
| bauzas | we still need some indirection between the openstack release number and the project version | 17:52 |
| dansmith | bauzas: to be clear, I very much would prefer the consistent date-based project versions, I just don't see it being likely we're going to convince and execute on it right now | 17:53 |
| fungi | the releases.openstack.org site was originally created to answer precisely that question | 17:53 |
| fungi | but maybe reorganizing it could help, or referring to it more | 17:54 |
| dansmith | fungi: it just sucks to have to use a decoder ring for things like this | 17:54 |
| bauzas | dansmith: yup, I withdraw because of the shortness of the current release naming usage, which is a valid concern | 17:54 |
| fungi | some sort of complex mapping is going to be necessary when users want to know what the latest recommended version is unless we want to force all projects to synchronize their point releases and branch support | 17:55 |
| gmann | well 'consistent date-based project versions' can be discussed I also feel its worth to have such if we can. | 17:55 |
| JayF | I don't see a world where consistent date-based project versions and a cycle-with-intermediary release model can exist simultaneously | 17:55 |
| fungi | right, we'd also need to go back to more or less a single release model | 17:56 |
| fungi | all of those changes to the release process were interrelated and introduced around the same timeframe | 17:56 |
| fungi | if you take away some of that set of changes, it has implications for other aspects as well | 17:57 |
| gmann | it can be x.y.z.<cycle-with-intermediary version> for example tempest 2023.1.33, 2023.1.34 where 33 34 are the multiple versions in '2023.1' version ? | 17:57 |
| JayF | I guess I should say; you cannot have semver, cycle-with-intermediary, and consistent date-based project versions | 17:58 |
| fungi | well, you can't really have semver and date-based models in the same version number anyway | 17:59 |
| JayF | and for projects that maintain branches of intermediate releases (Ironic bugfix branches), not having semver removes our ability to do that | 17:59 |
| JayF | fungi: I've seen YYYY.MAJ.MIN-postPATCH type of constructs before | 17:59 |
| JayF | I don't like them, but I don't want to suggest it's not possible to merge the two in some way | 18:00 |
| fungi | sure, that's no longer semver really though | 18:00 |
| dansmith | I dunno, | 18:00 |
| JayF | https://calver.org/ is an interesting resource for what other projects do around calendar based versioning. | 18:00 |
| dansmith | 2023.1.0 is still semver, but with "major breaking change" every year even if you don't have it right? | 18:00 |
| fungi | as long as you don't introduce breaking changes more often than once a year, sure | 18:01 |
| JayF | That's what I was trying to reference when I said YYYY.MAJ.MIN (or YYYY.MIN.PATCH depending on perspective) | 18:01 |
| JayF | fungi just hit on my concern for cycle-with-intermediary projects though | 18:01 |
| dansmith | fungi: yeah, which might be a benefit :) | 18:01 |
| fungi | sure, it's an option if you can guarantee it | 18:01 |
| dansmith | fungi: we already have major versions more often than we actually have major breaking changes | 18:02 |
| fungi | if that becomes part of the slurp model itself maybe | 18:02 |
| JayF | really that would boil down to a dictation from the TC that breaking changes must happen at cycle boundries (for cycle-with-intermediary projects) | 18:02 |
| fungi | some projects have major version bumps more often than once a cycle too though | 18:02 |
| JayF | I am PTL of some of them :D | 18:02 |
| JayF | lol | 18:02 |
| dansmith | (by "we" I meant projects like nova and glance, not all of openstack) | 18:03 |
| fungi | and here's where the discussion pivots to "let's bring back the core projects idea" | 18:03 |
| fungi | but anyway, where this breaks down even for nova and glance is that there are libraries required as part of openstack which would also need to follow the same synchronized date-based versioning scheme if the desire is to get rid of the "decoder ring" | 18:07 |
| fungi | one of the pressures which pushed us to decoupled versioning for services in the first place was that the libraries didn't follow the date-based version model and we needed a list of which versions of those to use for a given coordinated release anyway | 18:08 |
| fungi | so it was more consistent to do things in a similar way for all projects and not treat services and libraries differently in that regard | 18:08 |
| dansmith | I see no reason for the libraries to need to follow that, fwiw | 18:11 |
| fungi | then we still need a list of which versions go with which release | 18:11 |
| fungi | i.e. the "decoder ring" to which you referred | 18:11 |
| dansmith | the decoder ring problem is annoying for service versions, not so much for libraries, | 18:11 |
| dansmith | and the mapping is in our requirements files for the libraries, IMHO | 18:11 |
| JayF | Does a metapackage solve any of this concern? | 18:13 |
| fungi | there could certainly be a "requirements file" for services too | 18:13 |
| JayF | pip install openstack-2023.1[ironic] # gets you latest 2023.1-integrated ironic | 18:13 |
| fungi | well, not so much requirements as constraints (we don't track versions explicitly in requirements) | 18:13 |
| bauzas | I dropped that bomb and now I need to leave (end of the day for me) | 18:16 |
| fungi | ;) | 18:21 |
| fungi | it was a good discussion topic! | 18:21 |
| gmann | knikolla[m]: to publish meeting recording on youtube I have invited you to the channel owner role. please check and let me know if you are able to upload video there. I sent on knikolla@bu.edu | 20:53 |
| gmann | or let me know if you prefer any other email id | 20:54 |
| knikolla[m] | gmann: that works, thank you. | 22:29 |
| gmann | cool | 22:31 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!