Tuesday, 2024-10-01

opendevreviewmelanie witt proposed openstack/nova master: DNM try minimalistic imagebackend refactor  https://review.opendev.org/c/openstack/nova/+/92563502:35
opendevreviewmelanie witt proposed openstack/nova master: DNM try minimalistic imagebackend refactor cont'd  https://review.opendev.org/c/openstack/nova/+/92583802:35
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Move cache filename generation to imagebackend  https://review.opendev.org/c/openstack/nova/+/93096102:35
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Add base image format tracking via file extension  https://review.opendev.org/c/openstack/nova/+/93096202:35
opendevreviewmelanie witt proposed openstack/nova master: libvirt: Handle acceptable but not validatable images  https://review.opendev.org/c/openstack/nova/+/93096302:35
opendevreviewmelanie witt proposed openstack/nova master: db: Add image_type to block_device_mapping table  https://review.opendev.org/c/openstack/nova/+/93096402:35
opendevreviewmelanie witt proposed openstack/nova master: objects: Add image_type to BlockDeviceMapping object  https://review.opendev.org/c/openstack/nova/+/93096502:35
opendevreviewmelanie witt proposed openstack/nova master: virt: Add image_type to relevant DriverBlockDevice  https://review.opendev.org/c/openstack/nova/+/93096602:35
opendevreviewmelanie witt proposed openstack/nova master: WIP libvirt: Add image multi-backend  https://review.opendev.org/c/openstack/nova/+/93096702:35
opendevreviewmelanie witt proposed openstack/nova master: api: Add microversion 2.97 to add image_type to block_device_mapping_v2  https://review.opendev.org/c/openstack/nova/+/93096802:35
opendevreviewRajesh Tailor proposed openstack/nova master: Add support for showing finish_time  https://review.opendev.org/c/openstack/nova/+/92893306:57
opendevreviewTakashi Kajinami proposed openstack/placement master: Replace py38 job by py311 job  https://review.opendev.org/c/openstack/placement/+/93103315:45
opendevreviewTakashi Kajinami proposed openstack/placement master: DNM: testing ...  https://review.opendev.org/c/openstack/placement/+/93103415:46
bauzasreminder : nova meeting in 12 mins here15:49
fwieselo/16:00
bauzas#startmeeting nova16:01
opendevmeetMeeting started Tue Oct  1 16:01:07 2024 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.16:01
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:01
opendevmeetThe meeting name has been set to 'nova'16:01
bauzashey everyone16:01
tkajinamo/16:01
elodilleso/16:01
bauzas#link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting16:01
dansmitho/16:02
bauzasok let's start16:02
bauzas#topic Bugs (stuck/critical) 16:03
bauzas#info No Critical bug16:03
bauzas#info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster16:03
bauzasanything else ?16:03
bauzasok looks not16:04
bauzasmoving on16:04
bauzas#topic Gate status 16:04
bauzas#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:04
bauzas#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:04
bauzas#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status16:04
bauzas#info Please look at the gate failures and file a bug report with the gate-failure tag.16:04
bauzas#info Please try to provide meaningful comment when you recheck16:04
Ugglao/16:05
bauzasabout the periodics, we have a failure on the c9s job16:05
bauzas#link https://zuul.openstack.org/build/0e3b92cd874e4f29b4b252b6f4acb8e916:05
bauzas2024-09-28 08:43:49.610448 | controller | + lib/rpc_backend:install_rpc_backend:61   :   sudo systemctl --now enable rabbitmq-server16:05
bauzas2024-09-28 08:43:49.646533 | controller | Failed to enable unit: Unit file rabbitmq-server.service does not exist.16:05
bauzaslooks like there is a regression16:06
bauzasprobably something people already know ?16:06
tkajinamIs that seen in master ?16:07
bauzashttps://zuul.openstack.org/build/0e3b92cd874e4f29b4b252b6f4acb8e9/log/job-output.txt#489416:07
bauzasno, stable/2024.216:07
bauzasbut, sec, checking master16:08
* gibi joins late16:08
elodillesCentOS9 - Error: Unable to find a match: rabbitmq-server16:08
elodilleswhen installing 'dnf install -y rabbitmq-server'16:08
tkajinamI've not seen it in puppet jobs so I guess it's not a general problem.16:08
bauzasindeed, that's weird, master job run worked fine16:09
tkajinamNo match for argument: centos-release-openstack-2024.216:09
bauzashttps://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly&skip=016:09
tkajinamI guess it's not yet created16:09
tkajinamI remember there were some discussions about it in #rdo16:09
tkajinamI guess we can leave it now until devstack is updated or RDO publishes 2024.2 contents completely16:10
bauzasokay, let's then defer this discussion to next week16:10
bauzaswe'll see whether this fails again16:10
bauzasthanks tkajinam for the help16:10
tkajinam+116:10
bauzasmoving on16:10
bauzasnothing else about our gate stability ?16:10
bauzascontext : I wasn't around this week16:11
tkajinamnothing I'm aware of16:11
sean-k-mooneyya it sound like the rdo release has not happend yet16:11
sean-k-mooneywe might be able to pin to the 2024.1 content as a workaround16:12
bauzasokay, then moving to the next topic16:12
bauzassean-k-mooney: this is a periodic job, we can wait until next week16:12
sean-k-mooneyah then yes lets move on16:12
bauzas#topic Release Planning 16:12
bauzas#link https://releases.openstack.org/dalmatian/schedule.html16:12
bauzas#info Dalmatian GA planned tomorrow16:12
tkajinam\o/16:13
bauzasthat will probably help RDO ^ 16:13
bauzas#link https://releases.openstack.org/epoxy/schedule.html16:13
bauzasas a reminder, we don't have yet nova deadlines for Epoxy, that will be discussed at the PTG16:13
bauzas#topic Review priorities 16:13
bauzas#link https://etherpad.opendev.org/p/nova-2025.1-status16:14
bauzasI need to do some homework and add the already approved blueprints in therre16:14
bauzasat least gibi's series on igb is there16:15
bauzassounds like a quickwin16:15
bauzas#topic PTG planning 16:15
bauzas#info as a reminder, we'll meet (virtually) at the PTG on Oct 21-25 202416:15
bauzas#info Please register yourself to the virtual PTG16:16
bauzas#link https://etherpad.opendev.org/p/nova-2025.1-ptg16:16
bauzasplease add your topics to the above etherpad16:16
bauzasthe more we have before the PTG, the better we are prepared and I can write some agenda :)16:16
bauzaswe'll have the Austin room for the week16:16
bauzas(but I think I already said that last week)16:17
bauzasany questions about the PTG ?16:17
gibibauzas: will we have Asia slot?16:17
bauzasfor the translations docs thing with ian and sungsoo, there is a TC topic about it16:18
bauzasgibi: I don't think so, seongsoo and ian had their topic in the TC etherpad16:18
bauzasI'll clarify that tonight during the TC meeting16:18
gibiOK, so TC won't have an Asia slot either?16:19
bauzasunless of course I see a few topics in the nova PTG etherpad where the owners are in Asian TZ16:19
bauzasgibi: that's the question I'll ask tonight :D16:19
gibicool:)16:20
bauzasI'm fine with addressing the translation issues as a cross-project discussion16:20
bauzasbut I can propose nova for some experimental work16:20
gibime too, I just need to know in advance if there is an extra schedule 16:20
bauzasyeah, I want to prepare my mornings :)16:21
bauzasshould be hopefully settled next week16:21
gibithose sweet lazy mornings of the PTG week :)16:21
bauzasfor the moment, we stick with the usual slots that are 1300-1700UTC Tues to Fri16:21
gibiack16:22
bauzas#topic Stable Branches 16:22
bauzaselodilles: heya16:22
elodilles#info stable/202*.* gates seem to be OK16:22
elodillesat least i'm not aware of any issue :)16:23
elodillesand some patches merged, so probably OK16:23
elodilles#info note, that stable/2023.1 (antelope) will transition to unmaintained/2023.1 in a month16:23
elodilleswe might want a release in 1 or 2 weeks ^^^16:23
bauzastime flies16:23
elodilles*final* stable/2023.1 release16:23
elodillesyepp16:23
elodillesand that's all from me about stable for now16:24
bauzasone open thought16:24
bauzasbut I don't want to start a flamewar now16:24
elodilles:)16:24
bauzasonce we unmaintain 2023.1, we will only have one SLURP release16:25
bauzasthat's maintained16:25
* gibi prepares the torches 16:25
bauzasgiving an extra month before the flag would help people who *really* follow upstream stable support envelope to have more time to upgrade to C16:26
* bauzas awaits the tomatoes16:27
dansmithcan we move this along?16:27
* gibi hands a torch to bauzas 16:27
bauzasI don't know, that's a blind question16:27
bauzasyou know what ? that's not the right place to discuss that and I first need to check the releases support envelopes 16:29
bauzasbut honestly, my thought was about the fact that I can imagine a SLURP release having a shortly longer support envelope than a non-SLURP one (and don't think about LTSes, that's not what I'm thinking)16:30
bauzasaw, moving on16:31
elodillesbauzas: well, now i'm a bit unsure as well. but i'll check the resolution...16:31
bauzas#topic vmwareapi 3rd-party CI efforts Highlights 16:31
elodilles(unmaintained)16:31
bauzasfwiesel: around ?16:31
fwieselNot much to update from my side. Still looking into the flakyness of the CI (occasional port failing to get bound)16:31
fwieseldansmith: Gentle reminder about the open comment: https://review.opendev.org/c/openstack/nova/+/910627?tab=comments16:32
fwieselOtherwise, that's from my side.16:32
bauzascool16:32
bauzasand thanks for the update, g'luck with the flakyness16:33
bauzas#topic Open discussion 16:33
bauzas(tkajinam): How can we restore https://review.opendev.org/c/openstack/nova/+/845660 ? 16:33
bauzastkajinam: your time16:33
tkajinamI noticed I left that stale for long and I'm willing to resume that work16:33
tkajinamthe current problem is that os-brick silently falls back to single path connection in case multipath is not running. os-brick introduce the capability to hard-fail in case mulitpath is not running and that is configurable in cinder and glance, but is not in nova16:34
dansmithfwiesel: ack, but it's not blocking anything16:34
gibitkajinam: yeah make sense to pick that up16:35
tkajinammy main question here is whether this can be spec-less bp or need spec16:35
bauzaswould there be an upgrade impact ?16:35
tkajinamno. the option is disabled by default so the existing behavior is kept during upgrade.16:36
gibiseems like fully backward compatible opt-in behavior16:36
fwieseldansmith: No, the comment not. I assumed you were volunteering for the second required review core review and hoped I addressed everything outsstanding.16:36
gibiso for me it is OK to have it as specless16:36
bauzason a rolling upgrade case, you'd then have *some* computes that would fail instance creations while some others not ?16:36
tkajinamyes > full backward compatible.16:36
gibibauzas: the compute agent will fail to start up if you opt-in to the new behavior but failed to install multipathd16:37
bauzasthen a doc would be sufficient16:37
bauzasdo you plan to change the behaviour in a later cycle ?16:38
tkajinamno. I think we can keep the behavior optional. that's consistent with cinder and glance for now.16:38
bauzasthen I'm indeed cool with a specless BP, provided we document the option correctly (only turn that flag on if you installed multipathd)16:39
bauzasany disagreements ?16:40
bauzasso,16:41
bauzas#agreed https://blueprints.launchpad.net/nova/+spec/enforce-multipath approved as specless16:41
bauzasnext item16:41
bauzas(tkajinam): Python 3.8 support being removed 16:42
tkajinamsean-k-mooney, in case you have any remaining concerns then please let me know ^^^16:42
tkajinamthis is again my topic :-P16:42
tkajinamso as I wrote we are removing python 3.8 support from oslo. This is the timeline we agreed earlier and would move the whole projects to drop python 3.8 support16:42
tkajinamAFAIK py38 job was removed from most of the nova/placement repos but there are a few remaining in placement I'm trying to replace. if you can review the change and also double-check the other repos, that would be nice16:43
bauzaspy3.8 upstream support is planned end of Nov, right?16:43
bauzasupstream support end*16:43
tkajinamhttps://devguide.python.org/versions/ it's reaching its EOL this month16:44
bauzasoh this month16:44
tkajinamso py3.8 is already EOL when Epoxy is released16:44
bauzashttps://governance.openstack.org/tc/reference/runtimes/2025.1.html16:45
bauzasthat's not in our runtimes, so I'm cool16:45
bauzastkajinam: if that's review support you need for your patches, bug me16:45
tkajinamOne thing I want to get agreement about is the min version enforced by python_requires in setup.cfg16:46
bauzaswe can also add your patches in the status etherpad16:46
tkajinamwhich actually defines the min python version during installation16:46
bauzasdo we have a choice here given the Epoxy runtimes ?16:47
tkajinamMy own opinion is that we should bump min to 3.9, because we no longer test 3.8 and we don't aim to fix compatibility with it16:47
gibiyeah, if we don't test it then it is broken16:47
gibiso bump to 3.916:47
elodilleswe had issues in the past when we too early dropped a version and some thing went to error,16:48
elodillesbut i guess with py38 we are probably beyond that line :)16:48
bauzasdon't ask me to send you the pypi query that shows the number of "py2.7 supported" projects16:48
elodillesmaybe not merge it before tomorrow final 2024.2 Dalmatian release? :D16:48
bauzaselodilles: this was due to some oslo libs16:48
tkajinampy38 removal has been discussed for very long time and it was even removed from testing in 2024.2 .16:49
bauzasand this was also happening very late in the development cycle16:49
elodillesyepp16:49
bauzashow many projects import nova.* ?16:49
tkajinamI believe we gave all projects enough time to migrate job and now it's time to force any lagging projects to do their migration.16:50
elodilles+116:50
tkajinambauzas, I'm aware of none, but I've not checked external projects really.16:50
bauzaswell, Blazar did that a decade ago :D16:50
bauzasanyway16:50
tkajinamAs I said we may have new releases from oslo in M1 which drops py38 support. that would allow us to catch problems early16:50
elodilles+116:51
bauzasI'd say that oslo librairies should may be the latest to change their min versions16:51
elodillesor drop it early in the cycle16:51
bauzasbut we're way in advance, so we can cut the cord now and see which projects fail the gap16:51
bauzaselodilles: sure, and then it will become a TC discussion :D16:52
bauzaslike, project X CI fails, why ?16:52
bauzasanyway16:52
elodilles:)16:52
bauzastkajinam: from my sole angle of view which is the Nova project, I'd say you can safely bump our min_version in the descriptor, including os-vif and the clients16:53
tkajinamok16:53
tkajinamI'll submit the bump and see how it goes.16:53
bauzasanyything else then ?16:53
tkajinamno :-) thanks for your time.16:53
bauzastkajinam: and don't hesitate to bug me then16:53
gibitkajinam: thanks for doing the cleanup16:54
bauzasyup, thanks indeed16:54
bauzasanything else to discuss ?16:55
dansmithI just want to point out this patch of mine, which fixes a long-running transgression with us lying to glance about volume snapshots: https://review.opendev.org/c/openstack/nova/+/93075416:55
dansmithas far as I could tell while looking, the snap we create for volumes is not useful for actually booting from and was added for a completely unrelated reason ages ago16:55
dansmithso i think we might want to consider not doing that anymore if there is no reason16:55
dansmithif there is, then we're going to need to consider what we want to do there when we stop allowing nova to boot from unformatted (i.e. raw) images in the future16:56
dansmithbut I have a lot of history summarized there with links if anyone wants to have a look16:56
dansmiththat's blocking glance work because we fail in tempest tests to snapshot BFV instances since glance rejects nova's lies that we're uploading a qcow2 when we're clearly not16:56
bauzasdansmith: fwiw, I trust you on that yet another image backend story16:56
dansmithplease trust but verify :)16:57
dansmithanyway, no time to discuss in depth now, I need to run to something else but wanted to point it out16:57
gibidansmith: thanks for the heads up, I have to read your excellent commit message...16:57
bauzasdansmith: I'll carefully verify your commit msg then 16:58
dansmiththanks16:58
gibibauzas: I feel we are done16:59
bauzasyup, and we're on time16:59
gibiperfect :)17:00
bauzasI was doing some paperwork to add dansmith's patch into the etherpad17:00
bauzasthat's his fault17:00
bauzasthanks all17:00
bauzas#endmeeting17:00
opendevmeetMeeting ended Tue Oct  1 17:00:22 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.html17:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.txt17:00
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-01-16.01.log.html17:00
gibibauzas: thanks17:00
elodillesthanks o/17:00
gibio/17:00
tkajinamthank you17:00
opendevreviewTakashi Kajinami proposed openstack/nova master: libvirt: Add new option to enforce multipath volume connections  https://review.opendev.org/c/openstack/nova/+/84566017:17
opendevreviewTakashi Kajinami proposed openstack/nova master: Remove Python 3.8 support  https://review.opendev.org/c/openstack/nova/+/93104717:27
opendevreviewTakashi Kajinami proposed openstack/nova master: Remove Python 3.8 support  https://review.opendev.org/c/openstack/nova/+/93104717:27
gmanntkajinam: I think we should remove the python_requires itself17:28
sean-k-mooneycurrently tkajinam is not modifying it 17:29
sean-k-mooneyor the verions in setup.cfg at all17:30
sean-k-mooneythere patch is just reverting to using hashlib instead of oslo for md517:30
sean-k-mooneytkajinam: we shoudl proably update https://github.com/openstack/nova/blob/master/setup.cfg#L13-L23 in the same patch17:31
sean-k-mooneywether we remvoe python_requires = >=3.8 or change it to python_requires = >=3.9 i have less opipion on 17:31
sean-k-mooneybut we shoudl drop   Programming Language :: Python :: 3.817:31
gmannyeah and add py3.12 also17:31
sean-k-mooneyyep 17:32
tkajinamI though I modified setup.cfg but I somehow reverted that change...17:32
opendevreviewTakashi Kajinami proposed openstack/nova master: Remove Python 3.8 support  https://review.opendev.org/c/openstack/nova/+/93104717:33
sean-k-mooneythat explains why v1 and v2 are the same exctp the commit message :)17:33
sean-k-mooneygmann: you prefer not to bump python_requires in general yes17:33
sean-k-mooneyto allow it to install even if its not nessiarly compatible17:34
gmannsean-k-mooney: yeah, it create problem more than benefit 17:34
sean-k-mooneywithout a downstream patch python once we revert to hashlibg directly it will fail on vanilla py3817:34
sean-k-mooney usedforsecurity does not exist in the upstream python 3.8 hashlib17:34
gmannpython versions listed in  classifier should tell what all python versions are tested and supported and rest all no guarantee 17:35
tkajinamI'd say classifier is just useless because it does not enforce anything and have been unmantained for very long17:35
gmannif it work as long as it is good17:35
gmannthis is just a info and doc we do not need to enforce things17:35
sean-k-mooneygmann: right my point is nova wont work on py38 with this change (unless the distro backported the hashlib change to 3.8)17:36
tkajinamwhat you are saying is equivalent to drop all min version from requirements, IMHO17:36
tkajinamI don't know why we should maintain these although we won't maintain compat version for core python.17:37
sean-k-mooneyso tkajinam we may not be able to do this change this cycle17:37
sean-k-mooneywe still need ubuntu 22.04 for grenade17:37
sean-k-mooneyand i belive it uses 3.817:37
sean-k-mooneythis is the release whre we are moving all the ci to 24.04 but 22.04 is kept for smoth upgrades17:37
sean-k-mooney22.04 has alternitive pythons liek 3.917:38
sean-k-mooneyso we could use that instead but its not the default17:38
tkajinam22.04 uses 3.10 afaik17:38
sean-k-mooneyoh you might be right17:38
sean-k-mooneyi may have mixed that up17:38
sean-k-mooneytkajinam: ah yes your correct17:39
sean-k-mooney20.04 used 3.8 22.04 is alredy 3.1017:40
tkajinama few projects like cinder, heat, horizon, octavia already removed py38 support but they have survived17:40
tkajinamyeah17:40
sean-k-mooneyso that means the oldest python we have in ci (for master at least) is already 3.9 on centos17:40
tkajinamyes. 3.8 has been untested since 2024.217:41
tkajinamunless the repo contains the job left (eg. placement)17:41
sean-k-mooneyack17:41
sean-k-mooneyoh we missed updatign placement did we not merge the patch to update it for 2024.2?17:41
sean-k-mooneyhttps://review.opendev.org/c/openstack/placement/+/881366 ...17:42
gmannsean-k-mooney: tkajinam I sent on ML to remove this flag. IMO, it will not hurt anything but avoid our effort to update and coordinate it everytime17:42
sean-k-mooneyi tought we merged that17:42
gmannand coordination is always missing among all openstack project and this flag create issue17:43
sean-k-mooneygmann: im ok to remove it but as i said we knwo it wont work this time and ya the cordination is tough17:43
sean-k-mooneyhopefully less of an issue now that python has a yearly releace cadnace and predicable EOL date17:44
gmannyeah, everytime olso bump the min in this flag it fail many projects and it take time for fixing all their CI even fix is very simple17:44
sean-k-mooneyso im wondering if we should merge https://review.opendev.org/c/openstack/placement/+/881366 before https://review.opendev.org/c/openstack/placement/+/931033 or just go strait to tkajinam's patch17:46
sean-k-mooneytkajinam: is there a reaosn you marked that WIP17:46
tkajinamwe do actually remove compatibilities in some repos. if we remove the min then it appears as wired errors instead of explicit failure during installation17:46
tkajinamsean-k-mooney, I tought https://review.opendev.org/c/openstack/placement/+/925648 is the primary way but I'm fine with it... note that 925648 revealed that functional-py39 uses python 3.8 actually which needs to be fixed...17:47
tkajinamI mean I'm ok to merge job update and leave min bump for now17:47
gmann++17:48
sean-k-mooneywe have several patches for it in placement we just need to choose one to proceed with17:48
gmannor merge all in single one, remove py3.8 job + add py301, py311 jobs and leave the min version bump17:49
sean-k-mooneyplacement-perfload by the way is having a wheel build fialure for a missing header17:49
sean-k-mooneyi think that is unrelated and and existing fialure tha twe shoudl fix in a differnt patch17:49
sean-k-mooneyit has quite a few failures https://zuul.opendev.org/t/openstack/builds?job_name=placement-perfload&project=openstack%2Fplacement17:50
sean-k-mooneyim going to finish for today soon17:51
tkajinampy311 functional job already exists and pass so I prefer to use it now and then replace it by py312 if needed17:51
gmannah yeah, ++ for py3.1217:51
sean-k-mooneyim happy to go with gmann's suggestion fo a single path to do everythin and just test the upper and lower python version i.e. 3.9 and 3.12 for tox jobs17:51
tkajinamok17:51
sean-k-mooneyby the way 3.12 support is added by https://review.opendev.org/c/openstack/placement/+/919578/318:00
sean-k-mooneythe pre-commit series was all intended to be in 2024.2...18:01
sean-k-mooneyit would likely be best to merge https://review.opendev.org/c/openstack/placement/+/919578/3 first and then rebase tkajinam change on top18:02
sean-k-mooneygmann: if we wanted to avoid the merge conflict merging up to https://review.opendev.org/c/openstack/placement/+/919580/3 before tkajinam's change woudl make sense18:02
gmannsean-k-mooney: sure, will check after tc meeting18:03
sean-k-mooneyno worries18:03
opendevreviewTakashi Kajinami proposed openstack/placement master: Replace py38 job by py311 job  https://review.opendev.org/c/openstack/placement/+/93103318:10
opendevreviewTakashi Kajinami proposed openstack/placement master: Move upper functional job to py312  https://review.opendev.org/c/openstack/placement/+/93105218:10
opendevreviewMerged openstack/placement master: tox: Simplify functional testenv definitions  https://review.opendev.org/c/openstack/placement/+/91957820:39
opendevreviewMerged openstack/placement master: Integrate pre-commit  https://review.opendev.org/c/openstack/placement/+/91957921:28
opendevreviewMerged openstack/placement master: pre-commit: Add autopep8  https://review.opendev.org/c/openstack/placement/+/92349021:30
opendevreviewMerged openstack/placement master: pre-commit: Add sphinx-lint  https://review.opendev.org/c/openstack/placement/+/91958021:30
opendevreviewMerged openstack/placement master: Replace py38 job by py311 job  https://review.opendev.org/c/openstack/placement/+/93103321:59

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!