| *** PagliaccisCloud[m] is now known as PagliaccisCloud | 01:22 | |
| *** diablo_rojo_phone is now known as Guest2493 | 11:45 | |
| *** blarnath is now known as d34dh0r53 | 12:27 | |
| *** dasm|off is now known as dasm | 13:31 | |
| knikolla[m] | o/, sorry, i was out sick the past couple of days | 13:38 |
|---|---|---|
| *** iurygregory_ is now known as iurygregory | 14:04 | |
| *** jpodivin_ is now known as jpodivin | 14:44 | |
| gmann | tc-members: today meeting on google meet in ~7 min from now. link to join is mentioned in wiki https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 14:53 |
| fungi | i'll be chairing another meeting at that time, but let me know in here if you need any info from me | 14:55 |
| gmann | spotz: spotz[m]: need you to start the call https://meet.google.com/uzo-tfkt-top?pli=1 | 14:58 |
| spotz | gmann open, Dan was already in and can let folks in as well | 14:58 |
| gmann | let's start | 15:00 |
| gmann | #startmeeting tc | 15:00 |
| opendevmeet | Meeting started Thu Oct 6 15:00:35 2022 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'tc' | 15:00 |
| gmann | it is video call, link to join #link https://meet.google.com/uzo-tfkt-top?pli=1 | 15:00 |
| gmann | #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 15:01 |
| gmann | today agenda | 15:01 |
| gmann | #topic Roll call | 15:01 |
| rosmaita | o/ | 15:02 |
| gmann | #topic Follow up on past action items | 15:03 |
| slaweq | o/ | 15:03 |
| noonedeadpunk | o/ | 15:03 |
| gmann | slaweq to send email to projects on openstack-discuss ML about add the grenade-skip-level (or prepare project specific job using this base job) in their gate | 15:03 |
| gmann | gmann to add a separate step in repo rename process about fixing the renaming repo in zuul jobs across stable branches also | 15:04 |
| knikolla[m] | o/ | 15:04 |
| JayF | o/ | 15:04 |
| spotz | o/ | 15:04 |
| arne_wiebalck | o/ | 15:05 |
| gmann | #link https://review.opendev.org/c/openstack/project-team-guide/+/859886 | 15:05 |
| gmann | #link https://review.opendev.org/c/openstack/project-team-guide/+/839807 | 15:05 |
| gmann | #topic Gate health check | 15:05 |
| gmann | ovn failure fix #link https://review.opendev.org/c/openstack/devstack/+/860577 | 15:08 |
| gmann | Bare 'recheck' state | 15:08 |
| gmann | #link https://etherpad.opendev.org/p/recheck-weekly-summary | 15:08 |
| gmann | Zuul config error | 15:11 |
| gmann | #link https://etherpad.opendev.org/p/zuul-config-error-openstack | 15:11 |
| opendevreview | Merged openstack/project-team-guide master: Explicitly mention the each steps of repo retirement https://review.opendev.org/c/openstack/project-team-guide/+/839807 | 15:13 |
| gmann | #agree keep stable supported branch as priority for fixing zuul config error and EM stable as best effort but it is ok if we have their gate broken. anyone backporting to EM branch can fix or minimize the testing there. | 15:45 |
| gmann | #action gmann to update the wording the EM branch status and reality of maintenance policy/expectation | 15:46 |
| gmann | #topic Checks on Zed cycle tracker | 15:46 |
| gmann | #link https://etherpad.opendev.org/p/tc-zed-tracker | 15:49 |
| gmann | #link 2023.1 cycle PTG Planning | 15:50 |
| gmann | #link https://review.opendev.org/c/opendev/system-config/+/856834 | 15:52 |
| gmann | #link https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 | 15:52 |
| gmann | #link https://etherpad.opendev.org/p/tc-2023-1-ptg | 15:52 |
| gmann | #topic 2023.1 cycle Technical Election & Leaderless projects | 15:57 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/858980/1 | 15:58 |
| gmann | #topic Open Reviews | 16:05 |
| gmann | #link https://review.opendev.org/q/projects:openstack/governance+is:open | 16:05 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/860352 | 16:06 |
| gmann | #endmeeting | 16:06 |
| opendevmeet | Meeting ended Thu Oct 6 16:06:42 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2022/tc.2022-10-06-15.00.html | 16:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2022/tc.2022-10-06-15.00.txt | 16:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2022/tc.2022-10-06-15.00.log.html | 16:06 |
| fungi | are upgrade testing expectations recorded anywhere? i know it's been pointed out in the past that our upgrade expectation is to upgrade openstack in-place first and then upgrade the operating system, for releases where we transition from one tested platform version to another | 16:44 |
| fungi | it's come up in a thread on openstack-discuss, where neutron expects to start relying on a version of ovn which isn't available on ubuntu focal, bringing their upgrade story for 2023.1 and 2023.2 into question | 16:46 |
| gmann | we do not test upgrading operating system directly but we do validate that by grenade job on previous release using old OS passing and new release doing integrated testing on new OS so basically OpenStack old version to new version can work fine | 16:47 |
| fungi | right, but aside from "you must comply with whatever grenade does" do we actually document that expectation? it doesn't seem to be mentioned in either the pti nor the slurp resolution | 16:48 |
| gmann | you mean testing grenade on old OS and then upgrade openstack? neutron thing should have been catched in grenade job in old branch running on focal | 16:49 |
| dansmith | yeah I'm not sure we really specify that the OS upgrade comes later necessarily, do we/ | 16:49 |
| fungi | and needing to be able to continue running neutron 2023.1 (and even 2023.2) on focal seems to be coming as a surprise to the neutron leadership | 16:49 |
| gmann | thing was neutron override the default config and missed the devstack default configuration testing | 16:49 |
| dansmith | it's an artifact expectation from how we do our tests, but I'm not sure it's spelled out | 16:49 |
| clarkb | gmann: no I disagree on that summary. The issue is neutron require(d|s) a version of OVN that the currently supported platform(s) do not support. | 16:50 |
| clarkb | This isn't a unique situation. For example nodejs is chosen to be newer than what the platforms support as well. But that decision is made intentioanlly knowing the trade offs | 16:51 |
| dansmith | I think what gmann meant is we didn't catch it because neutron doesn't test the same way as the others right? | 16:51 |
| dansmith | i.e. they broke neutron in everyone else's gate but their own | 16:51 |
| gmann | yeah, I am not saying version bump that way right or wrong. I am saying it could have been caught in testing only if done with default devstack setting also | 16:52 |
| fungi | right, neutron not testing with devstack's defaults but still affecting devstack jobs for other projects is a significant gap in their current testing, which should be corrected | 16:52 |
| dansmith | yeah | 16:52 |
| gmann | yeah | 16:52 |
| clarkb | ah ok | 16:52 |
| gmann | not catching it in neutron side when merge is the issue | 16:52 |
| fungi | aside from that more immediate concern though, i'm wondering what the impact of their planned solution is to upgradeability, which has highlighted that we don't really seem to provide any documentation to guide their decisions on that | 16:53 |
| fungi | it sounds like the plan now (extrapolating to our upgrade testing) is that anyone running neutron zed on ubuntu focal will need to build ovn from source when upgrading to neutron 2023.1, before they can upgrade to ubuntu jammy | 16:55 |
| clarkb | right I think there are two things that this calls out. The first is that our gating is broken/insufficient. THe second is how do our platform support statements reflect on CI and the reality of people deploying this in the real w orld | 16:55 |
| clarkb | and then a 2.5 which is "should devstack work by default on those supported platforms" as I don't think devstack functions on debian by default | 16:56 |
| fungi | though my bringing slurp up turns out to be irrelevant in this case, since slurp would be from 2023.1 to 2024.1, so anyone doing that would have to upgrade to jammy after reaching 2023.1 anyway | 16:57 |
| fungi | zed->2023.2 wouldn't be slurp, so doesn't need to be solved | 16:57 |
| gmann | yes zed->2023.2 is not officially supported/tested upgrade | 16:58 |
| gmann | and upgrading OVN in 2023.1 make things solved for upgrade | 17:00 |
| gmann | sorry in 2023.2 | 17:00 |
| fungi | right, it sounds like they wanted to do that for 2023.1 instead, but hopefully grenade will prevent them from doing that (except their workaround is instead to build ovn from source on focal in 2023.1 devstack) | 17:01 |
| gmann | yeah | 17:01 |
| fungi | i guess the qa team should reject that proposal on the grounds that it's not a viable upgrade path for users | 17:01 |
| fungi | so anyway, as for documenting platforms used for upgrading, should they get explicitly mentioned in the pti for cycles where that happens? like should https://governance.openstack.org/tc/reference/runtimes/2023.1.html mention ubuntu focal/20.04? since it technically needs to work for grenade jobs to run | 17:02 |
| gmann | sure, let me check which is best place to mention about these support ands test it with grenade testing if not done by project. may be yes in testing runtime document or so | 17:09 |
| *** dasm is now known as dasm|off | 18:22 | |
| opendevreview | Ghanshyam proposed openstack/governance master: Add supported upgrade-path testing in PTI https://review.opendev.org/c/openstack/governance/+/860599 | 18:34 |
| clarkb | fwiw it doesn't look like neutron is running grenade anymore | 19:53 |
| clarkb | I was trying to look into that. So it may be possible that after jammy updates and neutron unreverts the ovn stuff it will break projects that do run grenade | 19:53 |
| melwitt | O.o | 20:15 |
| *** dasm|off is now known as dasm | 20:49 | |
| clarkb | digging futher there are grenade jobs but their irrelevant files lists are quite long. I think the reason they haven't run in this case is that ovn files are explicitly excluded from triggering grenade | 20:54 |
| clarkb | which basically means no grenade testing with ovn so the upgrade case wouldn't be covered? | 20:54 |
| clarkb | there are experimental ovn grenade jobs | 20:56 |
| clarkb | so I guess the intent was that we'd get ovn grenade working and the nswitch to it maybe? I do think this goes back to questions about defaults and platform support though. Why is ovn the devstack default if we cannot test that it is upgradeable? | 20:57 |
| clarkb | With slurp it seems like being able to test this stuff has become far more important, but our default deployment options don't seem to align | 20:58 |
| fungi | if ovn is devstack's default then aren't devstack changes at least testing it with grenade? or do devstack changes not gate on whether grenade works? | 21:02 |
| clarkb | grenade disables ovn from what I can tell. Then neutron has ovn + grenade jobs in experimental only | 21:05 |
| clarkb | so what we test with grenade must be neutron + ovs not ovn. But then our devstack default is neutron + ovn? | 21:05 |
| clarkb | Basically what we test upgrades for is not what we present as the better standard | 21:05 |
| clarkb | fungi: devstack changes do run grenade but all with ovs I think | 21:06 |
| clarkb | I think what I'm trying to get at is that we shouldn't haev the default testing tool (devstack) default to a deplyoment or things we consider should be standard and then not test the upgradeability of that. Particularly if we want to start doing skip level upgrades which makes the opportunity for stuff to break much great | 21:07 |
| JayF | spotz: I believe it was you who mentioned in the TC meeting that we get more pickup for deprecation notices and the like when they are put on twitter; is there currently a way for me to send out an official notice via that method? | 21:43 |
| fungi | JayF: i can get the foundation social media marketing folks who run the openstack twitter handle to circulate just about anything you wantr | 21:44 |
| spotz | jayf If you send it to the ML I can tweet the link from the OPS Meetup account | 21:45 |
| clarkb | the two appraoches we've done with zuul are to give them specific content to tweet from the official handles or you tweet something and request them to retweet | 21:45 |
| JayF | fungi: spotz: Traditionally; has that been used for things like "Hey does anyone use Ironic T/U/V? Speak now or the will be unsupported" :) | 21:45 |
| fungi | JayF: i can't think of examples, but it doesn't seem like an unusual request. that's definitely the sort of thing where a personal tweet and then retweeting that from widely-followed handles probably works better, since you can respond more directly i think? | 21:46 |
| JayF | Ack; okay. I am just getting a feel for the options before the Ironic meeting. | 21:47 |
| JayF | So no request for action or one to be expected now; but I'll see what the community thinks Monday morn | 21:47 |
| spotz | Ok and if there's anything I can help with just ping | 21:47 |
| JayF | absolutely; thank you! | 21:48 |
| JayF | (and that always goes in reverse too) | 21:48 |
| *** Guest2493 is now known as diablo_rojo_phone | 22:04 | |
| *** dasm is now known as dasm|off | 22:15 | |
| gmann | JayF: this is ops twitter if you would like to tag them @osopsmeetup | 22:18 |
| gmann | spotz: thanks for sharing recording, i downloaded, you can unshare it. | 22:27 |
| spotz | gmann ok | 22:28 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!