Thursday, 2022-09-15

JayFI'm running these on my beefy local desktop00:45
JayFso maybe I can just try and find out tomorrow00:45
TheJuliaJayF: for what it is worth, last year I ran it until I had like 123k rows in my local db... it didn't take tooooo long01:08
TheJuliabut yeah01:08
JayFI mean, I usually work off the laptop and use the desktop when I need beef, this is exactly what it's for01:09
JayFmaybe if 100k doesn't take too long, I'll run it for some exceedingly extreme value of N until my office gets toasty lol01:09
TheJulia... yeah... it did increase the home office temp a bit01:10
stevebaker[m]a lock torture test would be interesting01:13
JayFI'm just running stuff that Julia has already written tbh01:18
JayFbut I'd be all ears for an idea on how to do a lock torture test, whatever that'd mean01:18
ashinclouds[m]You’d need multiple completing threads….01:36
opendevreviewAija Jauntēva proposed openstack/ironic master: Fix idrac-redfish RAID controller mode conversion  https://review.opendev.org/c/openstack/ironic/+/85587207:38
opendevreviewMerged openstack/tenks master: [CI] Gate on CentOS Stream 9 and Rocky Linux 9  https://review.opendev.org/c/openstack/tenks/+/85685908:51
* dtantsur is curious if he really needs to start reminding the core team (incl. 1 former and 2 candidate PTLs) how requirements work or better just give up09:32
dtantsurjk, I've given up long ago..09:36
opendevreviewMerged openstack/tenks master: [CI] Remove CentOS 7 support leftovers  https://review.opendev.org/c/openstack/tenks/+/85686009:41
opendevreviewkamlesh chauvhan proposed openstack/ironic-tempest-plugin master: Add iDRAC Redfish configuration molds test  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/85571009:51
opendevreviewSONG SHUKUN proposed openstack/ironic master: Add support auth protocols for iRMC  https://review.opendev.org/c/openstack/ironic/+/85703510:02
opendevreviewMerged openstack/tenks master: [CI] Optimise ovs setup  https://review.opendev.org/c/openstack/tenks/+/85686110:11
opendevreviewMerged openstack/tenks master: [ansible-lint] Restore sanity  https://review.opendev.org/c/openstack/tenks/+/85689210:11
opendevreviewMerged openstack/tenks master: [ansible-lint] Unignore jinja[spacing]  https://review.opendev.org/c/openstack/tenks/+/85689310:11
opendevreviewMerged openstack/tenks master: [CI] Ignore .ansible-lint in the main jobs  https://review.opendev.org/c/openstack/tenks/+/85689610:11
opendevreviewMerged openstack/tenks master: [CI] Name the Debian version  https://review.opendev.org/c/openstack/tenks/+/85689710:11
iurygregorygood morning Ironic12:15
iurygregorydtantsur, because of the bump in sushy version for zed? .-.12:39
dtantsuriurygregory: yup. sorry if I sound a bit overly sarcastic, but this goes against the agreed requirements approach.12:39
dtantsurnow, we could change the approach and say we just bump version at the end of each cycle. this would even solve some problems. but we have never said it?12:40
dtantsurand I think I'm spending too much time being The Guardian of Requirements here :D12:40
iurygregorydtantsur, no need to be sorry, I do understand that normally we don't have an upper bound for requirements, just trying to understand how bad is to bump (I know it means that "we don't support versions lower than X)12:43
dtantsurit's not "bad", it's inconsistent12:43
dtantsurwe're sending a message to downstreams that is not quite true: ironic can no longer work with sushy<4.3.012:44
dtantsurimagine somebody has a regression (etags anyone) in 4.0. So far they can stick to 3.2, but now we've officially disallowed that12:44
iurygregoryhummm12:44
ashinclouds[m]Well if you’ve got super micro hardware12:44
dtantsurand again, it's partly a question of policy. if we say "you MUST use the latest version of sushy/ironic-lib from the release series", it's fair12:44
dtantsurbut it's not what we say12:45
ashinclouds[m]We almost need we recommend and then we require as different things12:45
dtantsurright12:45
dtantsurrequirements is what we require12:45
dtantsurnormally, requirements are not bumped for bug fixes because of cascading effect on downstreams12:45
dtantsuranother example: imagine proliantutils doing sushy>=3.0,<4.0 for some reason. oops?12:45
dtantsur(I'm not justifying having upper caps, but they do happen)12:46
dtantsurI also see one big advantage of what we've done with 4.3: if we realize we need newer sushy features on stable/zed, we're not screwed12:47
dtantsurso, I don't object making it a new policy, as long as it's a policy12:47
dtantsur(and then we probably need to do it for everything in driver-requirements too)12:48
* TheJulia starts making coffee12:49
dtantsuryep, it's not a good pre-coffee discussion ;)12:49
iurygregorytotally not, I'm still a bit slow since I only had 1 mug of coffee :D12:49
iurygregoryreading carefully to understand all the points12:49
TheJuliaYou know, has one of the major vendors done their typical end of cycle d-r bump yet?12:50
iurygregorythis is a good question...12:51
dtantsura good indeed. if we make it a policy, we can just propose the change for them.12:51
iurygregorythe scenario where I see it's good to bump is specially when we drop support for some python version (in the case the min requirement we have doesn't work properly with new python)12:56
dtantsurit's probably fair, but only has a strong impact on the 2->3 transition12:56
iurygregoryyeah12:56
iurygregorynormally for sushy we are able to backport things and we release for other stable branches12:57
iurygregorymaybe we just couldn't backport some of the SMC fixes? (at least from what I remember we backported most of them)12:58
TheJuliawasn't one of the big things related to etags?13:03
* TheJulia lacks complete understanding of what was needed for SMC in sushy13:04
* TheJulia is also waiting for the coffee to cool a little bit13:04
dtantsurI was under impression we backported the fixes13:51
dtantsurthis was another cause of my surprise by that bump13:52
dtantsurhttps://review.opendev.org/q/Idb2d6bee96bd23cfc4fb8f014661231766998781 backported13:53
dtantsurhttps://review.opendev.org/q/I021d1116613e2b35352ca9749f8bc8a84bf655a1 backported13:53
dtantsurhttps://review.opendev.org/q/I7ea0f7ef856cc47f1d4ea334717bfb4577d0c093 backported13:54
dtantsurwhat fixes do we miss?13:54
dtantsuror maybe we just haven't released them?13:54
dtantsur(I do think we released yoga 4.1.2 with this fix)13:58
iurygregoryhttps://storyboard.openstack.org/#!/story/200986514:16
iurygregorythis was the story14:16
iurygregoryhttps://review.opendev.org/q/I384baf5c27a531be0c4b78e11e1214d6371fa8be14:16
iurygregorybut we did backport to xena and wallaby...14:16
iurygregorymaybe they are using other version and we didn't backport? 14:17
TheJuliaoh migrations... why are you so broken on my machine :(14:18
dtantsurit's not an accident that the words "migrations" and "migraine" look similar14:49
TheJuliablah14:58
JayFisTetheredBig downside to self-hosting your IRC client bastion: when internet is out, my irc is out :( 15:18
dtantsuroops15:22
JayFisTetheredI'm trying to dig on a bifrost failure, but I'm not super experienced in troubleshooting CI for bifrost15:49
JayFisTetheredhttps://zuul.opendev.org/t/openstack/build/062f0c9f6a764cce869b6a3f597c6889/log/logs/bifrost.log#14801 is this the failure being complained about?15:50
JayFisTethered(for https://review.opendev.org/c/openstack/bifrost/+/849247 )15:50
dtantsurJayFisTethered: correct15:54
dtantsurif you scroll a bit down:15:54
dtantsur"You must correct your GRUB install devices before proceeding:",15:54
dtantsur        "",15:54
dtantsur        "  DEBIAN_FRONTEND=dialog dpkg --configure grub-pc",15:54
dtantsur        "  dpkg --configure -a",15:54
dtantsur        "dpkg: error processing package grub-pc (--configure):",15:54
dtantsur        " installed grub-pc package post-installation script subprocess returned error exit status 1",15:54
dtantsurwhich is puzzling...15:54
JayFisTetheredYeah; looked like an upstream distro break to me, potentially15:54
JayFisTetherednothing in that PR could break it afaict15:54
dtantsurhttps://forum.openmediavault.org/index.php?thread/38006-recent-updates-and-upgrades-can-fail-when-updating-to-grub-pc-2-02-dfsg1-20-deb1/15:55
dtantsurjesus15:55
JayFisTetheredaw hell15:55
JayFisTetheredWe should see if there's a bug against this behavior15:56
JayFisTetheredthat's a big break for stable (Right? bullseye is stable, right?)15:56
dtantsuryeahh..15:56
JayFisTetheredhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=53523915:57
JayFisTetheredthat's not exactly it15:57
JayFisTetheredhttps://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=grub-pc15:58
dtantsurwe may need to bring it to the infra16:01
JayFo/16:03
JayFI'm back to normal16:03
dtantsur\o16:03
JayFI mean, this seems like a bifrost-specific break, no?16:04
dtantsurJayF: we could do something like https://github.com/turnkeylinux/tracker/issues/1579#issuecomment-892221912, but it's probably not the right thing to do on bare metal16:04
dtantsurJayF: no, it's CI-specific. I guess grub in the CI is not set up correctly.16:04
JayFoh, it's erroring *on the machine bifrost is running* that it can't install grub16:05
dtantsuryes16:05
dtantsursee my explanation on #opendev now16:06
* TheJulia glares at test_migrations.py16:28
opendevreviewJulia Kreger proposed openstack/ironic master: Phase 2 - SQLAlchemy 2.0 compatability  https://review.opendev.org/c/openstack/ironic/+/85751616:33
opendevreviewJulia Kreger proposed openstack/ironic master: WIP Phase 3 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85793216:33
TheJuliablarg16:33
TheJuliaso... still got some sporadic warnings appearing on test_migrations.py's run, but getting there16:34
opendevreviewJulia Kreger proposed openstack/ironic master: WIP Phase 3 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85793216:44
TheJuliaokay, that takes care of a couple more16:44
TheJuliaw/r/t sqlalchemy stuffs, as much as I'd love to see them merge for Zed, I don't think we should given how much risk that has with it being *that close* to the DB16:50
TheJuliaalthough if openstack wide is shipping the minimum sqlalchemy version at 1.4, we could eventually backport them16:51
opendevreviewDmitry Tantsur proposed openstack/bifrost master: Do not install grub2 and shim on the host system  https://review.opendev.org/c/openstack/bifrost/+/85793516:55
dtantsurJayF: let's see if ^^ works16:55
JayFaight, I'll look once tests finish16:56
dtantsuro/17:02
TheJuliagoodnight dtantsur 17:30
* JayF about to do the 100k nodes benchmarks17:48
JayFcurious how long it'll take just to insert the data lol17:49
TheJuliamysql insert is slow....18:16
TheJuliasoooooooo18:16
TheJulia:)18:16
JayF> Created 100000 nodes in 1630.1096534729004 seconds.18:24
JayFhonestly, not that terrible.18:25
JayFNow I'm going to see if my PC melts as I setup the benchmark lol18:25
JayFcurrent master: > Took 121.13843488693237 seconds to return all 100000 nodes via nodes API call pattern.18:31
JayFwith phase 1+2 patches cherry picked on top: > Took 121.2013418674469 seconds to return all 100000 nodes via nodes API call pattern.18:31
JayFTheJulia: ^^ If it's slower, it's not slower-enough to matter18:31
JayF.07s difference when getting 100k nodes lol18:32
TheJulialol18:51
TheJulia825/nodes/sec is blisteringly fast18:52
JayFI mean, I can multithread the API calls18:56
JayFor add even more nodes18:56
JayFbut I'm fairly convinced there's no slowdown on the python side18:56
TheJuliayeah18:56
JayFpart of why I picked my beefy desktop to run these is to try and remove mysql from the equation... this should all fit in ram so it's all about single threaded python perf18:56
TheJulia100k nodes really exposes it if there is anything18:56
JayFand like, it's reproducably very slightly slower with the changes18:56
JayFooooh18:56
JayFI wonder if I should try with your changes /and sqlalchemy 2.0/18:57
JayFI wonder if I should try with your changes /and sqlalchemy 2.0/18:57
JayFwill that work now/18:57
TheJuliashould 2.0.0b1 is out18:57
JayFit's not in pypi18:59
JayFbut I'll try and get it via git19:00
JayFTheJulia: it doesn't work at all against sqla 2.0 :(19:03
JayF2022-09-15 12:03:38.968 1581244 CRITICAL ironic [-] Unhandled error: sqlalchemy.exc.InvalidRequestError: When initializing mapper Mapper[Node(nodes)], expression "relationship("List['NodeTrait']")" seems to be using a generic class as the argument to relationship(); please state the generic argument using an annotation, e.g. "traits: Mapped[List['NodeTrait']] =19:04
JayFrelationship()"19:04
TheJuliaWOOOT!19:04
JayFsarcastic woot, I presume? lol19:04
JayFyou want me to put this somewhere :( 19:04
JayFlike in a bug or a PR comment or something19:04
TheJuliayeah, please19:04
JayFtell me where and it shall be done19:05
TheJuliainterestingly enough.. I did that19:05
TheJuliaat least, I think i did19:05
JayFdo I need the phase 3 patch, too?19:05
TheJuliano good ideas of where at the moment19:05
TheJulianah, that is all test_migrations19:05
TheJuliaand horribly broken still19:05
JayFdo you want me to dig this?19:06
TheJuliamaybe comment on the change19:06
JayFI've steered clear of actual engineering b/c I figured the coordination would be more pain than I could provide value19:06
JayFhttps://gist.github.com/jayofdoom/cb132e3d39213eb79b195e849bfbcebb and it's a comment on the phase2 patch19:07
JayFTheJulia: I'm going to try and clear this error if I can19:10
JayFand at least comment on your pr how to fix19:10
JayFyeah. it's in the new traits relationship stuff added in phase1, but I'm not sure why/how19:20
TheJuliayeah... oddly enough in 1.4 it works like a champ19:29
TheJuliaand it was added in 1.4 for 2.019:29
TheJuliahi mysql, why you hate me.19:29
TheJuliaerr, mariadb19:29
opendevreviewJulia Kreger proposed openstack/ironic master: Phase 1 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85633619:30
opendevreviewJulia Kreger proposed openstack/ironic master: Phase 2 - SQLAlchemy 2.0 compatability  https://review.opendev.org/c/openstack/ironic/+/85751619:30
opendevreviewJulia Kreger proposed openstack/ironic master: WIP Phase 3 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85793219:30
TheJuliaoh, so I think I know whati s going on with the mapping19:31
TheJuliaafter re-reading it again19:31
TheJuliafixing19:39
opendevreviewJulia Kreger proposed openstack/ironic master: Phase 1 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85633619:40
opendevreviewJulia Kreger proposed openstack/ironic master: Phase 2 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85751619:40
opendevreviewJulia Kreger proposed openstack/ironic master: WIP Phase 3 - SQLAlchemy 2.0 Compatability  https://review.opendev.org/c/openstack/ironic/+/85793219:40
JayFoooh exciting19:40
JayFoooooooh19:41
JayFthat makes so much sense19:41
JayFbenchmark is not going big kaboom!19:43
TheJulia\o/19:43
TheJuliarumor has it, it should be even *faster*19:43
JayFwell, data will has it in about 100 seconds give or take lol19:44
TheJulia15% increase, nice19:44
JayFno, I mean, if we wait it'll be data and not rumor19:45
JayFI have no results yet19:45
TheJuliaoh!19:45
TheJuliaokay19:45
JayFalso was thinking of refactoring this benchmark tool a little19:45
TheJuliaby all means19:45
JayFto make it not really assume you have /etc/ironic/ironic.conf and the like lol19:45
JayFjust adding some cli flags to set the database url would make it containerizable I think19:45
TheJuliaYeah, it was a quick and dirty "i need to exercise these lower layers" code19:45
JayF> Took 117.68264269828796 seconds to return all 100000 nodes via nodes API call pattern.19:46
TheJuliaslightly better!19:46
JayFthat's a real improvement19:46
JayF/home/jay/current-master.txt:Took 121.13843488693237 seconds to return all 100000 nodes via nodes API call pattern.19:46
JayF/home/jay/phase2-with-sqla2.txt:Took 117.68264269828796 seconds to return all 100000 nodes via nodes API call pattern.19:46
JayF/home/jay/with-patches.txt:Took 121.2013418674469 seconds to return all 100000 nodes via nodes API call pattern.19:46
JayFto re-summarize for people who don't want to read above19:46
JayFsqla 1.4 w/patches: small perf hit, barely measurable19:47
TheJulialike... 28/nodes/second faster19:47
JayFsql 2.0 w/patches: improvement of 28/nodes/second19:47
JayFthat's stellar19:47
* TheJulia dances19:48
TheJuliaanyway, I need to go pickup my car and go have my blood drawn19:48
JayFthis is baller nice work TheJulia 19:48
iurygregorywow nice results \o/19:50
TheJuliaI'm likely going to try to wrap phase 3 up tomorrow19:50
JayFI think given these results it should be safe to merge into zed if we want; but I might suggest it'd be wise to wait for Antelope19:51
TheJuliaI *think* I know what is going on with it, but I can't get it to play nicely with the temporarly table namings locally since it ends up in absurdly long keys and then the engine explodes for some reason19:51
JayFif for no other reason than to give CI an entire cycle to beat on it and expose any edges we might have missed19:51
TheJuliayeah, I'm leaning more towards Antelope personally19:51
TheJuliaI did already notice a couple failures which made me think locking in CI, but it is one of those "the right things happened.... maybe something else happend to the VM I can't see that drove it to occur"19:52
TheJulialike an IO pause19:52
TheJulia... one of the two VMs definitely had a pause occur long enough to timeout a rabbit message19:53
iurygregoryand we know that CI always explodes close to the release :D19:53
TheJuliaexactly19:55
JayFcame across this in RFE review: https://storyboard.openstack.org/#!/story/130093921:50
JayFwe don't even have any translations committed, do we? 21:50
JayFThis seems to me like a "it's important enough to do" or "just close the ticket and admit we won't"21:50
TheJuliawow that is an oldie21:53
TheJuliawe have some translations21:54
TheJuliamaybe not21:55
TheJuliaokay, we had translations21:56
TheJuliaI think it makes sense to close because the argument can be made that translating content can be a breaking behavior change21:56
opendevreviewJay Faulkner proposed openstack/ironic master: Document existence of non-production "fake" driver  https://review.opendev.org/c/openstack/ironic/+/85798422:05
JayFthe problem with me doing bug triage is that I stop in the middle to fix them sometimes ^ :P 22:08
JayFThat should get like, content review -- if there are further use cases for the fake driver, I'm unfamiliar with them, but we shoudl include them22:08
JayFhttps://storyboard.openstack.org/#!/story/1427923 this is another one that I'm kinda shocked if it still exists, but in this case, if it does we should consider fixing it22:10
*** bodgix3 is now known as bodgix22:12
TheJuliait does unfortunately, although it is a rare operation and I think you functionally need system/owner admin rights22:18
JayFwe have an entire cycle worth of these kind of "it's bad but not horrible" bugs22:19
* TheJulia wonders why not see if outreachy interns might be interested22:20
TheJuliaIn at least the smaller ones as long as we don't force them through a spec22:20
JayFEh, maybe. None of it is crazy hard but we're not talking low hanging fruit on most of those22:21
TheJuliait is that or we accept they are by design but not ideal22:21
TheJuliayeah, you give them one thing, not multiple22:21
TheJuliabut yeah22:21
JayFI think we're better off to accept it and close the bug if we're not going to fix them22:21
JayFif we want the bugtracker to be useful, we can't keep aspirational rfes-that-are-hiding-in-bugs kinda things like that in there never moving22:22
JayF(or we need a tool that allows better exclusion of such bugs)22:22
TheJuliaagreed22:22
opendevreviewJay Faulkner proposed openstack/ironic master: Document existence of non-production "fake" driver  https://review.opendev.org/c/openstack/ironic/+/85798422:50
opendevreviewJay Faulkner proposed openstack/ironic master: Document existence of non-production "fake" driver  https://review.opendev.org/c/openstack/ironic/+/85798422:51

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