Tuesday, 2020-12-08

openstackgerritMerged openstack/project-config master: Remove Searchlight projects from infra  https://review.opendev.org/c/openstack/project-config/+/76453500:37
openstackgerritMerged openstack/project-config master: Remove Qinling projects from infra  https://review.opendev.org/c/openstack/project-config/+/76453600:39
openstackgerritMerged openstack/project-config master: Announce openstack/ossa in #openstack-security  https://review.opendev.org/c/openstack/project-config/+/76538900:42
*** tosky has quit IRC00:54
*** openstackgerrit has quit IRC00:58
*** stevebaker has joined #opendev01:05
*** openstackgerrit has joined #opendev01:52
openstackgerritIan Wienand proposed opendev/gerritlib master: docker-compose: update header syntax  https://review.opendev.org/c/opendev/gerritlib/+/76589801:52
openstackgerritIan Wienand proposed opendev/system-config master: WIP: initalize gerrit in testing  https://review.opendev.org/c/opendev/system-config/+/76522402:05
*** zer0c00l has quit IRC02:08
*** paladox has quit IRC02:10
*** paladox has joined #opendev02:15
*** ysandeep|away is now known as ysandeep02:54
*** stevebaker has quit IRC03:41
*** hamalq_ has quit IRC03:45
*** marios has joined #opendev06:17
*** marios is now known as marios|rover06:31
*** elod_pto has joined #opendev06:31
*** elod_pto has quit IRC06:38
*** hamalq has joined #opendev06:44
*** elod_pto has joined #opendev06:45
*** sboyron has joined #opendev07:51
*** lpetrut has joined #opendev07:55
*** hashar has joined #opendev08:07
*** slaweq has joined #opendev08:08
*** rpittau|afk is now known as rpittau08:10
yoctozeptoinfra-root review.opendev.org looks down :/08:11
gibilooks down to me too08:13
yoctozeptoand that's it for the productive morning plan :D08:13
ianwhrm, the host is up and the container is running08:13
ianwit's not responding to ssh08:15
marios|roveryoctozepto: just came here to say same08:16
*** andrewbonney has joined #opendev08:16
yoctozeptomarios|rover: only sad reactions!08:22
slaweqhi, I just came here to say the same but I see that You are already aware :)08:27
ianw#status log gerrit restarted after a short outage08:27
openstackstatusianw: finished logging08:27
ianwit should be coming back up now08:27
marios|roverthanks ianw08:27
ianwwe'll have to dig further to the exact issue08:27
slaweqianw++ it works :)08:28
zbrthanks ianw08:28
zbrany idea what happened? OOM?08:29
ianwmemory usage did seem to spike a couple of hours ago according to cacti08:31
ianwwe'll have to pull the logs and correlate to have more of an idea08:31
yoctozeptothanks ianw08:32
ianwheh well restarting it isn't great.  but i'm out of time for today; i have logged some details for other roots in the usual places08:33
zbrlets hope it survives for the next ~6h until someone else comes online.08:35
zbri observed that my session was reset by the restart, is not gerrit able to persist sessions on disk too? so a restart would not force everyone to login again?08:35
zbrnevermind, i found why it does this, is not configured correctly,I will make a CR to address that.08:37
yoctozeptozbr: oddly, it has not logged me out08:45
yoctozeptobut yeah, I noticed it logs me out more frequently than the old one08:45
openstackgerritSorin Sbârnea proposed opendev/system-config master: Avoid logging out users on restart  https://review.opendev.org/c/opendev/system-config/+/76592108:48
zbri also observed something weird, based on docs the memory caches are measures in bytes, and the values that I seen there seam far too small for our deployment.08:48
zbrfalse alarm, memoryLimit stats is measured in entries not bytes. Apparently google developers did not learn to properly name variables :D08:52
zbrhttps://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cache.name.memoryLimit paragraph is super confusing08:53
zbreven the documentation is misleading. it stated that diskLimit is default 128 MiB except 4 specific caches. But when you read web_sessions, you discover that this defaults to 0.08:58
yoctozeptozbr: well, it did *not* log me out08:58
yoctozeptozbr: so I guess there is *some* cache08:58
zbrdevil may be in the implementation, when using external authentication it is possible to restore session from remote.09:00
zbrlast time i accessed gerrit was ~12h ago, this morning I had to login again. Based on the fact that I do not dicover this each morning, I have a high degree of confidence that these two are related.09:01
zbrlet me survey my collegues....09:01
*** hamalq has quit IRC09:10
*** hamalq has joined #opendev09:14
yoctozeptozbr: well, let's try the config change and see if it helps; should not hurt :D09:15
yoctozeptoI did not notice the auth redirects so unsure what worked09:15
*** hamalq_ has joined #opendev09:16
zbrthat is my view too, but lets see what those with extra experience think. sometimes docs lie.09:16
*** hamalq has quit IRC09:18
*** hamalq_ has quit IRC09:20
*** DSpider has joined #opendev09:52
*** hamalq has joined #opendev10:00
*** hamalq has quit IRC10:04
openstackgerritdaniel.pawlik proposed openstack/diskimage-builder master: Remove centos-repos package for Centos 8.3  https://review.opendev.org/c/openstack/diskimage-builder/+/76596310:34
openstackgerritdaniel.pawlik proposed openstack/diskimage-builder master: Remove centos-repos package for Centos 8.3  https://review.opendev.org/c/openstack/diskimage-builder/+/76596310:38
yoctozeptointeresting case -> recheck only run against arm64 pipeline https://review.opendev.org/c/openstack/kolla/+/76586010:41
ianwyoctozepto: possibly a message got lost during that gerrit downtime?10:56
*** dtantsur|afk is now known as dtantsur11:00
yoctozeptoianw: that could be it; I thought it would queue it11:07
*** dviroel has joined #opendev11:10
gibihi! I saw plenty of "openstack-tox-py38 https://zuul.opendev.org/t/openstack/build/85b94d33f4774bebb61b0a4f7f5ae5e0 : ERROR Failed to update project None in 7m 25s" Zuul results, is it also due to the gerrit outage happen couple hours ago? Example: https://review.opendev.org/c/openstack/nova/+/75710911:12
yoctozeptofailing to do nothing should be a success!11:14
gibiespecially during the incoming holiday season11:16
*** hashar is now known as hasharLunch11:26
slaweqhi infa-team11:44
slaweqcan You take a look at https://bugs.launchpad.net/neutron/+bug/1907242 and check if that can maybe be another pypi cache issue?11:44
openstackLaunchpad bug 1907242 in neutron "ERROR: No matching distribution found for wrapt==1.11.* in the CI jobs" [Critical,Confirmed]11:44
slaweqbecause it happens a lot in the neutron jobs since yesterda11:44
slaweq*yesterday :)11:45
*** hamalq has joined #opendev12:01
*** hamalq has quit IRC12:05
*** fressi has joined #opendev12:25
*** hasharLunch is now known as hashar12:37
*** dtantsur has quit IRC12:50
*** dtantsur has joined #opendev13:06
*** owalsh has quit IRC13:20
*** fressi has quit IRC13:26
*** fressi has joined #opendev13:41
*** tosky has joined #opendev13:44
*** hamalq has joined #opendev14:02
*** slaweq has quit IRC14:03
*** slaweq has joined #opendev14:04
*** hamalq has quit IRC14:07
fricklerslaweq: I see the same issue locally, so not an issue on our side14:09
slaweqfrickler: hmm, I didn't saw it on my vm locally14:09
fricklerslaweq: if you try to reproduce, make sure to upgrade pip in your venv before running tox14:10
slaweqfrickler: ok, maybe that is the case indeed, I will check later14:10
fricklerso "python3 -m venv .tox/shared/; .tox/shared/bin/pip install -U pip; .tox/shared/bin/pip install -chttps://releases.openstack.org/constraints/upper/master -r/opt/stack/neutron/requirements.txt -r/opt/stack/neutron/test-requirements.txt" shows the error for me14:10
*** haleyb has joined #opendev14:13
*** bcafarel has joined #opendev14:13
*** hamalq has joined #opendev14:17
*** hamalq has quit IRC14:22
*** tkajinam has quit IRC14:47
*** tkajinam has joined #opendev14:47
*** marios|rover is now known as marios|call14:57
*** marios|call is now known as marios|rover15:06
*** ysandeep is now known as ysandeep|away15:16
*** tkajinam has quit IRC15:18
*** hashar has quit IRC15:31
openstackgerritClark Boylan proposed opendev/system-config master: Reduce gerrit heap limit to 44g  https://review.opendev.org/c/opendev/system-config/+/76602015:34
yoctozeptocan we start rebuilding centos as part of opendev? 😂15:41
clarkbyoctozepto: I won't :P, in theory the system allows for it, but building a linux distro is a massive undertaking and i already have way too much on my plate15:42
yoctozeptoclarkb: I wonder if we can do a subset though15:42
yoctozepto100% not interested in the graphics bloat15:43
yoctozeptoand otherwise centos is much smaller than debian15:43
yoctozeptobut I feel you15:43
yoctozeptooh what a pandora box there15:43
clarkbya but its also not a super valuable task for our projects, there are many distro options including stable alternatives15:43
clarkbif centos isn't fitting the bill anymore use another15:43
yoctozeptobut rhel is good, and the sources are lying around :D15:44
yoctozeptoas for me, I will probably go with stream for some uses and ubuntu (or debian) for others15:45
*** tosky has quit IRC15:45
yoctozeptounless someone rebuilds elsewhere15:45
dtantsuraha, so the folks are already discussing it. great!15:51
dtantsurI guess the infra folks are just as surprised as I am, but I really wonder what will happen with nodesets for CentOS15:52
dtantsur(as a sub-question, what will happen with DIB support)15:52
clarkbdtantsur: we'll delete centos-8 when it eols (roughyl) and you'll have the option to use stream (stream is already available)15:53
clarkbprior to eol I think everyone should be shifting to stream now15:53
dtantsurclarkb: even for stable branches?15:53
clarkbdtantsur: maybe? the way we handle fedora on stable branches is to just drop those jobs when fedora eols15:54
dtantsurI think you have fedora-latest as an alias?15:54
clarkb(we actually try to switch to fedora latest first iirc and if that breaks drop them, so ya switching to stream, if that beraks drop it)15:54
clarkbdtantsur: yes15:54
clarkbessentially I would stop using centos 8 for anything new right now. FIgure out what using stream looks like for new stuff then decide how to handle old stuff based on that info15:55
dtantsurI assume, since we have nodesets for stream, DIB supports it?15:55
clarkbyes dib supports stream15:55
dtantsurmmmok, thank you. the ironic community has something to think about.15:55
dtantsurhow is the nodeset called? centos-stream?15:56
clarkbdtantsur: fwiw this is based on how we handle other EOLs but I don't expect we'll diverge much for centos 815:56
dtantsursure, we just did not expect centos 8 EOL so soon :)15:57
clarkbthe only real difference here is this eol is unexpected rather than previously planned for15:57
clarkbya that15:57
clarkbbut we don't control that either :/15:57
dtantsurI feel a bit bad since I advocated for relying on CentOS as a reliable foundation for years... and now this.....15:57
yoctozeptoclarkb, dtantsur: just enter #centos-devel and welcome in hell :-)15:57
dtantsurmm, thank you but no thank you15:58
yoctozeptodtantsur: you are welcome nonetheless ;D15:58
dtantsurI feel really, really bad for people working on centos now.. they'll get a shitstorm they don't deserve15:58
yoctozeptoyes, they are now15:58
yoctozeptowell, they actually promised the eol of centos8 in 202915:59
yoctozeptoand now it's in 202415:59
yoctozeptodue to stream15:59
clarkbI guess scientific linux is still alive, I thoughti t was also effectively eol but I probably just confused CERN moving to centos with that15:59
dtantsur"we will shift our investments to CentOS Stream exclusively on December 31, 2021" (c) Red Hat15:59
clarkbyoctozepto: ^ I expect if you want to help a rebuild that is a good bet15:59
yoctozeptodtantsur: for stream in CI you can checkout my change to devstack15:59
dtantsuryoctozepto: 2021, not 2024. 2024 is for CentOS 7.15:59
yoctozeptodtantsur: 2024 for centos 8 stream16:00
*** hashar has joined #opendev16:00
yoctozepto2021 for centos 8 releases16:00
yoctozeptostill 5 years too early from the planned 202916:00
yoctozeptoclarkb: hmm, I thought sl was not going to produce 816:01
yoctozeptoand yes, it does not produce it16:01
yoctozeptoat least not ey16:01
clarkbyoctozepto: I imagine that things have signfiicantly changed today :) but ya they may still avoid it16:01
dtantsurscientific linux was abandoned in favour of centos16:01
yoctozeptoclarkb: yeas, it is one crazy day16:01
dtantsurnow that centos is a different thing.. who knows16:02
dtantsurclarkb: do you plan on making the nodeset versioned? i.e. centos-8-stream vs future centos-9-stream?16:07
clarkbdtantsur: I think it already is centos-8-stream16:08
clarkbso ya I would expect a centos-9-stream once it arrives16:08
dtantsurah, I should have verified my assumptions before asking :)16:08
fungiwe'll presumably follow suit with what rh does, so if they have separate 8 and 9 streams we'd presumably carry both until they eol16:08
dtantsursorry, a crazy day. started with all the lower-constrains madness....16:08
clarkbfungi: ya looks like they will do separate streams beacuse each stream is the feeder for the corresponding rhel release16:08
dtantsurthis ^^16:08
yoctozeptodtantsur: it was lower-constraints and centos 8.3 today for me and now this, crazy day :D16:10
dtantsurah, yeah, 8.3 as well16:11
yoctozeptocentos 8.3 brought repo rename to match stream16:11
yoctozeptoI SEE WHAT YOU DID THERE16:11
yoctozeptodtantsur: the job I mentioned is https://review.opendev.org/c/openstack/devstack/+/75912216:12
dtantsurthanks! so, it's green without too much effort? this is a good sign!16:15
clarkbI imagine the delta is minimal right now since centos 8 just did an update too?16:15
dtantsuryep, 8.3 was out today16:15
*** hamalq has joined #opendev16:18
*** hamalq has quit IRC16:23
*** fressi has quit IRC16:29
openstackgerritMatt McEuen proposed openstack/project-config master: New Project Request: airship/vino  https://review.opendev.org/c/openstack/project-config/+/76388916:35
openstackgerritMatt McEuen proposed openstack/project-config master: New Project Request: airship/sip  https://review.opendev.org/c/openstack/project-config/+/76388816:35
*** kopecmartin has quit IRC16:43
yoctozeptoclarkb: yeah, the tribute has been paid16:45
yoctozeptodtantsur: yes, it's green; it's not that very different16:45
*** kopecmartin has joined #opendev16:48
*** lpetrut has quit IRC16:48
*** hamalq has joined #opendev16:56
*** hamalq has quit IRC17:01
*** hamalq has joined #opendev17:06
zbrclarkb: fungi: this morning gerrit was restarted and forced me to login again. that make me google a bit and check the config. I ended up proposing: https://review.opendev.org/c/opendev/system-config/+/76592117:12
zbrdoes it makes sense?17:12
zbrconfig states that disk persistency is not enabled by default for web-session objects.17:13
zbrand recommends enabling it17:13
*** owalsh has joined #opendev17:13
zbri am not yet sure if the value is correct, the docs are very confusing regarding the meaning of limit, varies a lot between different fields.17:14
clarkbzbr: can you link to that because I'm raeding the docs and it says it is17:14
fungishow-caches is showing it disk-backed on our deployment17:14
clarkbunder cache.<name>.diskLimit it talks about defaulting to 128MB except for specific cases. web sessions is not a specific case17:14
clarkbhttps://gerrit-review.googlesource.com/Documentation/config-gerrit.html#cache that is the documentation I am lokoing at17:15
fungi  Name                          |Entries              |  AvgGet |Hit Ratio|17:15
fungi                                |   Mem   Disk   Space|         |Mem  Disk|17:15
zbrthe page is linked from CR, search for: "cache "web_sessions" -- yep not anchors17:15
fungiD web_sessions                  |   382 285323 128.02m|         | 86%   1%|17:15
yoctozeptofungi: that would align with my observation of not being logged out17:15
*** marios|rover is now known as marios|out17:15
zbrIf no disk cache is configured (or cache.web_sessions.diskLimit is set to 0) a server restart will force all users17:15
zbrthat is copy/paste from docs17:16
zbrmost caches have defaults, that one is zero, but is not listed among those....17:16
fungizbr: fair warning, we're discovering lots of places where gerrit's docs are not entirely correct too, so have been making sure to check any assumptions before believing them17:16
clarkbzbr: the docs don't say its default is zero?17:16
clarkbthey say if it is zerop17:16
clarkband where they talk about defaults they don't mention web sessions as being special impying it has a 128mb limit17:17
clarkbwhich lines up with what we see from show-caches17:17
clarkbI don't think that configuration will change anything for us17:17
zbrtbh, these docs are a total mess, i spent an hour this morning trying to understand how these limits work. different sections have contradicting statements.17:17
clarkbzbr: agreed, I'm still waiting on a response to my question if specific values need to go in jgit.cofnig or not because the docs don't make that clear17:18
clarkbzbr: I think I've decided we'll just set them in jgit.config and gerrit.config until we understand it better17:18
zbrfor this particular option I think is clear that is inside gerrit.config17:19
clarkbzbr: yes for this one its fine. But per our cache overservations the default seems to be 128MB on disk17:19
clarkbwhich should be plenty. I don't think we need your change based on fungi's metric gathering17:19
zbrhttps://review.opendev.org/c/opendev/system-config/+/765921/ -- is the review.17:19
clarkb(I don't know why you were forced to log back in again, I was too)17:20
clarkbs/overservations/observations/ I can't type17:21
zbryeah, that was weird because I asked others, at least two people did not had to login again.17:21
zbrmaybe sometimes the re-auth with ubuntu happens in the background?17:21
clarkbit shouldn't, ubuntu one should always ask you to re acknowledge the log in17:22
fungiopenid doesn't have a "background"17:22
fungiyou literally have to bounce through http redirects to the identity provider and back17:22
zbrdo we had only ~380 users in the last 7 days?17:24
clarkbno thats the memory column17:24
clarkbits ~380 cached entries since the restart17:25
clarkbwhich seems in the realm of posibility (or the memory cache is quite small because the disk cache is large?)17:25
*** tosky has joined #opendev17:26
fungialso cached sessions may not be equal to users, you could have multiple sessions for a single user on different devices17:26
zbri guess you already double checked all memoryLimit values? as the object count vs bytes can easily lead to big mistakes.17:28
clarkbzbr: default should be 1024 web sessions according to the docs for memoryLimit17:30
zbrprobably for accounts* we do want to be sure we have 100% memory hits, as the username lookup is likely to search among them.17:30
*** marios|out has quit IRC17:30
clarkbits harder to confirm that without diggin in the source, or waiting for the show-caches command to show you've hit a round number limit like that17:31
zbrany change we could log all caches daily so we can look for trends?17:32
clarkbmaybe? It is an administrator command iirc so may take some figuring out17:32
zbri wonder if i may have being logged out due to 1024 limit, it would explain why only some users may have.17:33
zbra cron would do17:33
clarkbbut you'd still expect to end up in the disk cache since it is lru?17:33
clarkbbut maybe your session was old enough to have rolled over in the lru or something17:34
zbrthat is what I was wondering, maybe mine was old, now the question is how do you age a session? do they age from last usage or original creation time?17:34
clarkbyou know as much as I do :) probably need to read the docs then cross check against the source code17:35
zbrbecause I am sure the previous page load was about 12h before that.17:35
zbrclarkb: i kinda feel sorry for you having to tune these, tuning live systems is not really a joy.17:37
clarkbya, also its really difficult to get good data out of the test system (I've tried a few times to reproduce and then tune and see if we can monitor differences, but without real world activity its just not the same)17:37
zbrmaybe lucam can have a look at our cache config and tell use if we made a mistake? somehow I believe that gerrithub.io may have more users.17:39
clarkbI think we have more changes than they do (but not sure about users)17:41
clarkband yes I've been pinging upstream periodically for clarification, though still waiting on that last question I asked last week17:41
*** rpittau is now known as rpittau|afk17:43
*** cloudnull has quit IRC17:47
*** cloudnull has joined #opendev17:47
clarkbI need to step out for a bit then prepare for the meeting, back for that.17:48
fungiin the past 35 minutes the web_sessions cache entries have grown from 382 to 397 mem, 285323 to 285329 disk, and 128.02m to 128.03m space. cache hit ratios have remained the same (within the degree of precision reported anyway)17:51
fungizbr: also keep in mind that the maxage for web_sessions may be how long a session is considered valid from the time of creation, not since time of last update?17:52
zbranyone against making that 30days?17:54
clarkbthe 7 days we've set seems reasonable17:55
clarkblogin in every monday17:55
clarkb(or whatever your schedule is, and now really need to eat breakfast and catch up on my morning after the board meeting)17:55
fungineeding to re-log-in takes me a moment because i have to dig out my 2fa key and plug it in and retrieve a code, but still not so long that doing that once a week is a problem for me17:56
zbrmy impression is that asks more often than this but i started to log the timestamps, anyway that is low-prio kind of issue, we have far bigger ones to address17:56
fungiyeah, i mean if you can confirm that we're logging sessions out way faster than weekly, that's probably good to dig into and figure out why17:58
zbrsure, i logged the approx time and remember to see.17:59
zbrwithout written records I do not trust my own memory or "feelings"17:59
fungisame here. it seems believable to me that i log into the gerrit webui roughly once a week, but i really can't say for sure18:00
fungiespecially since i do most reviewing in gertty instead18:00
fungiand administration via the ssh command-line interface it provides18:01
zbrfungi: clarkb can we do the WIP experiment now? https://review.opendev.org/c/openstack/project-config/+/765821 -- is marked as WIP, add workflow to it and lets see if it goes in.18:01
openstackgerritDmitriy Rabotyagov proposed openstack/project-config master: Revive os_monasca  https://review.opendev.org/c/openstack/project-config/+/76579918:01
fungisure, taking a look18:01
zbreven if it goes in, there is no damage done. but we will know the answer to the the yesterday question.18:01
*** hashar is now known as hasharDinner18:02
zbrbased on that we can decide if we need to implement changes or only document it.18:02
*** dtantsur is now known as dtantsur|afk18:05
fungizbr: so worth noting, zuul enqueued it into the gate and reported verified +2 but did not submit it to merge18:25
fungii think that means it's not taking wip status into account for enqueuing decisions18:25
fungiwe might want to discourage use of the wip state in gerrit until we get it solved, in projects like tripleo that's likely to just cause more unnecessary delays and gate resets as people accidentally approve wip changes and then those make it all the way to the top of the gate and pass all their testing and then get their submit call rejected by gerrit in the end18:32
fungi(and so everything queued behind them has to be retested)18:33
fungii'll add this to our tracking etherpad18:35
zbrfungi: i will try to make a PR tomorrow to make zuul avoid that, if I figure out how to do it.18:42
fungizbr: ooh, thanks! corvus just mentioned a good path forward in #zuul if you're looking for where to start18:42
*** andrewbonney has quit IRC18:51
zbrI wonder if we can change the default sort-order on dashboard to consider Review-Priority flags.18:55
zbrnow it only looks for Update, but it should be double key:  RP first, update second.18:55
clarkbzbr: I think someone put a similar thought on the post upgrade notes etherpad and i suggseted an upstream bug19:00
clarkbas I expect that whatever ordering they are doing is somewhat intended19:00
clarkb(it almost looks like its based on the hierarchy of the config where the category comes from)19:00
*** stevebaker has joined #opendev20:07
*** hasharDinner has quit IRC21:34
*** sboyron has quit IRC22:20
zigoHi guys! First, thanks for the new Gerrit. Now, I just want to know: do you intend at some point to have the gitweb link working again? I very much liked it, and miss it.22:23
fungizigo: yep, we're collecting a list of stuff which needs solving post-upgrade at https://etherpad.opendev.org/p/gerrit-3.2-post-upgrade-notes and that's line 39 at the moment i think22:26
zigoAh, thanks, good to know it's in the TODO.22:26
fungiyeah, the more immediate concerns have been related to stability and performance tuning under load22:27
corvusclarkb: sn8 test in 2m https://www.youtube.com/watch?v=nf83yzzme2I22:27
corvusthis one looks like a spaceship and not a water tower or grain silo22:28
openstackgerritMerged opendev/system-config master: Reduce gerrit heap limit to 44g  https://review.opendev.org/c/opendev/system-config/+/76602022:29
zigofungi: In fact, what I really would appreciate, would be a direct link to the actual .diff file (and *not* a .diff.base64 or .diff.zip ...).22:29
zigoBecause I very often just need to download the patch with wget -O debian/patch/bla.patch22:30
zigoI don't know the internals of gerrit, but if it's simple to do, please do it.22:30
fungiseems like we can programmatically assign hyperlinks for stuff like the old gitweb linking, in which case it may be possible to link to the individual raw change diffs on gitea22:35
fungibut first we need to focus on getting everything working again22:35
clarkbcorvus: did I miss it? /me about to eat some lunch22:35
corvusclarkb: raptor abort at t-122:36
corvusi'm guessing that means try again tomorrow22:37
clarkboh too bad for them I guess22:37
corvusyep; livestream says done for the day22:39
mordredfungi: I have an old probably bitrotted change for updating the links to link to gitea instead of gitweb22:58
mordredfungi: I don't know if it will provide any use of not22:58
mordredfungi: https://review.opendev.org/c/opendev/system-config/+/72352622:59
openstackgerritMonty Taylor proposed opendev/system-config master: Use gitea for gerrit gitweb links  https://review.opendev.org/c/opendev/system-config/+/72352623:01
*** tkajinam has joined #opendev23:01
fungimordred: oh, yep, i recall seeing that one in there though i assumed it may no longer be relevant for polygerrit (even the built-in gitweb linking seems to be broken in ours)23:11
fungibut definitely worth trying out23:11
mordredyeah - I have no idea of the relevance, but figured if that's an area you're thinking about - maybe that patch points in a direction that might shorten any work you consider doing. or maybe not :)23:11
fungiabsolutely, thanks for writing it and for the reminder it's there!23:14
clarkbre gitweb ya I think we should ocnsider turning it off then I think the gitiles will default in23:52
clarkbthen for gitea we can figure it out form there?23:52

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