| opendevreview | OpenStack Proposal Bot proposed openstack/project-config master: Normalize projects.yaml https://review.opendev.org/c/openstack/project-config/+/949824 | 02:19 |
|---|---|---|
| mnaser | went back and forth a bit with setuptools maintainers | 02:35 |
| mnaser | they thought they had it fixed but missed our pbr use case :) | 02:35 |
| mnaser | so should be all good now | 02:35 |
| mnaser | and 80.7.1 was tagged 14 minutes ago | 02:36 |
| JayF | mnaser: maybe post an update in the ^ above linked PBR bug too? | 02:40 |
| Clark[m] | JayF that linked PBR issue is unrelated | 03:45 |
| Clark[m] | The issue today was a bug on setuptools part that happens to affect pbr packaged projects but doesn't require PBR to break. It was just buggy code. The PBR issue you linked is for planned cleanup of deprecated code that will break PBR | 03:46 |
| opendevreview | Merged openstack/project-config master: Normalize projects.yaml https://review.opendev.org/c/openstack/project-config/+/949824 | 04:40 |
| opendevreview | Michal Nasiadka proposed openstack/project-config master: kolla: Allow kolla-core to remove RP votes https://review.opendev.org/c/openstack/project-config/+/949842 | 05:34 |
| opendevreview | Michal Nasiadka proposed openstack/project-config master: kolla: Allow kolla-core to remove RP votes https://review.opendev.org/c/openstack/project-config/+/949842 | 05:43 |
| opendevreview | Michal Nasiadka proposed openstack/project-config master: kolla: Allow kolla-core to remove RP votes https://review.opendev.org/c/openstack/project-config/+/949842 | 05:57 |
| opendevreview | Michal Nasiadka proposed openstack/project-config master: kolla: Allow kolla-core to remove RP votes https://review.opendev.org/c/openstack/project-config/+/949842 | 07:02 |
| opendevreview | Michal Nasiadka proposed openstack/project-config master: kolla: Allow kolla-core to remove RP votes https://review.opendev.org/c/openstack/project-config/+/949842 | 07:02 |
| *** ykarel_ is now known as ykarel | 11:41 | |
| opendevreview | Merged openstack/project-config master: Add collections required by OpenStack-Ansible to github projects https://review.opendev.org/c/openstack/project-config/+/949325 | 13:29 |
| opendevreview | Merged opendev/zuul-providers master: Build images daily https://review.opendev.org/c/opendev/zuul-providers/+/949806 | 13:56 |
| opendevreview | James E. Blair proposed opendev/zuul-providers master: Remove max-ready-age https://review.opendev.org/c/opendev/zuul-providers/+/949896 | 13:58 |
| opendevreview | Michal Nasiadka proposed openstack/diskimage-builder master: CI: Use opendevmirror/ubuntu for functests https://review.opendev.org/c/openstack/diskimage-builder/+/949897 | 14:01 |
| fungi | i just realized that i've not been on matrix since saturday when my shell server got unexpectedly rebooted in flex and the python-based weechat-matrix plugin started throwing an exception deep in pyca/cryptography | 14:05 |
| fungi | i guess an update at some point broke it, but since that plugin is abandoned anyway i'm going to take this opportunity to try out the (wip) rust rewrite | 14:07 |
| opendevreview | Tony Breeds proposed openstack/diskimage-builder master: WIP: Add support for CentOS Stream 10 https://review.opendev.org/c/openstack/diskimage-builder/+/934045 | 14:10 |
| clarkb | I'm starting to put the gerrit 3.11 upgrade process and notes together in https://etherpad.opendev.org/p/gerrit-upgrade-3.11 | 15:31 |
| clarkb | Gerrit 3.11 adds a rest api endpoint to bulk abandon changes based on their age and whether or not they are mergeable | 15:42 |
| *** kevko6 is now known as kevko | 15:49 | |
| opendevreview | Clark Boylan proposed opendev/system-config master: Test gerrit.requireChangeForConfigUpdate=false https://review.opendev.org/c/opendev/system-config/+/949914 | 16:06 |
| clarkb | I'm trying to test if we can make the new install test setup for Gerrit 3.11 match the current 3.10 behavior of not requiring code review for project config updates. That way we can get consistent behavior in testing and in prod before and after the upgrade (mostly as a belts and suspenders we won't run into problems with acls after the upgrade) | 16:12 |
| fungi | wouldn't be a bad idea to up the default gerrit version in git-review's tests too | 16:14 |
| fungi | i'm approving some pending changes for it, and will then update the testing | 16:15 |
| clarkb | looking at the gerrit upgrade I think the upgrade process itself is actually the simplest one we've had like ever. There are no index or schema updates | 16:16 |
| clarkb | so all the effort is in considering all the changes to other things (like acl updates needing code review by default and new apis and so on) | 16:16 |
| clarkb | while thats running I think we should consider https://review.opendev.org/c/opendev/system-config/+/882900 (moving gerrit images to quay) and https://review.opendev.org/c/opendev/system-config/+/949778 updating gerrit images to the latest point releases. We can land them together and do a single restart. Or do them separately if we think there is sufficient concern to spread them | 16:31 |
| clarkb | out. Mostly looking for feedback on that. I think it wouldn't be crazy to split them up and do two restarts just due to the previous issues we had with moving to quay | 16:31 |
| fungi | looks like i'm already +2 on both of those | 16:33 |
| fungi | oh, or i was until the rebase | 16:33 |
| fungi | never mind, it carried over | 16:34 |
| opendevreview | Merged opendev/git-review master: Allow specifying remote branch at listing changes https://review.opendev.org/c/opendev/git-review/+/872988 | 16:36 |
| opendevreview | Merged opendev/git-review master: Show remote side colors when color is enabled https://review.opendev.org/c/opendev/git-review/+/914000 | 16:36 |
| opendevreview | Merged opendev/git-review master: Fix TypeError when reporting old git version https://review.opendev.org/c/opendev/git-review/+/947145 | 16:36 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Update higher Gerrit versions used in testing https://review.opendev.org/c/opendev/git-review/+/949916 | 16:37 |
| corvus | the main annoyance i'm seeing for the zuul-launcher right now is the infinite loop trying to download images that have expired (so that it can upload them to new clouds). that should be addressed by building new images periodically, or manually building new ones. | 16:42 |
| corvus | a change to build images daily has merged, which will help | 16:42 |
| corvus | i'm also slowly manually triggering image builds, which will help | 16:42 |
| corvus | and a change to zuul to allow more than one image build to be enqueued at a time should merge soon, and that should help speed up the process of manually building them. | 16:43 |
| corvus | fungi: https://zuul.opendev.org/t/opendev/build/25ccf5103d3342659319cd414f8fa0ad happened to notice that failure for your git-review/gerrit change | 16:45 |
| opendevreview | Michal Nasiadka proposed openstack/diskimage-builder master: WIP: Add support for CentOS Stream 10 https://review.opendev.org/c/openstack/diskimage-builder/+/934045 | 16:45 |
| fungi | thanks! yeah, i was going to dig into that one | 16:48 |
| fungi | i guess i need to pull a more recent jre in the job | 16:49 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Add CC similarly to reviewers https://review.opendev.org/c/opendev/git-review/+/849219 | 16:56 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Update higher Gerrit versions used in testing https://review.opendev.org/c/opendev/git-review/+/949916 | 16:56 |
| fungi | we'll see if openjdk-21 is too new for gerrit 3.10, hopefully not | 16:57 |
| clarkb | fungi: I don't think it is | 16:58 |
| clarkb | setting gerrit.requireChangeForConfigUpdate to false does not allow us to continue to directly push refs/meta/config on 3.11 as we did with 3.10 | 17:02 |
| clarkb | I've asked on gerrit discord what the purpose of this config item is in that case | 17:03 |
| fungi | that could make project creation and acl updates challenging | 17:03 |
| clarkb | fungi: ya the workaround we were using was you update All-Projects acls to allow force push | 17:04 |
| fungi | mmm, okay so not a regression then | 17:04 |
| clarkb | if you allow force push then you can still do the old thing. But they documented this config option and not adding force push perms so I figured I'd try to documented path (also its easier for us to apply) | 17:04 |
| fungi | got it | 17:04 |
| clarkb | so I'm a bit stumped as to why the config option exists at all | 17:04 |
| fungi | less worrisome and more head-scratching | 17:05 |
| clarkb | but if we are concerned we can manually update our all-projects acls on 3.10 prior to upgrading. I've asked them to clarify if this new restriction will apply to installs that upgrade from 3.10 to 3.11 or if it is only for new installs as well (we can also test this as part of upgrade testing) | 17:05 |
| clarkb | this is a situation much like the recent pbr struggles. We've had this functioanlity for over a decade and now that the world has decided we aren't crazy and it is useful they've implemented it in a different manner without asking for input from those of us that have been doing it forever and in the process have broken us | 17:06 |
| clarkb | at least in this case we know of the workarounds upfront its just a matter of reconciling that information with the documentation as I'm digging into it | 17:10 |
| clarkb | fungi: https://opendev.org/opendev/system-config/blame/branch/master/doc/source/gerrit.rst#L227 I think this may have us covered already fwiw | 17:12 |
| clarkb | then in testing the issue is we're using the admin account which is part of administrators which doesn't come with force push to refs/* by default | 17:13 |
| fungi | yeah, we'd need something akin to our project-bootstrappers group | 17:14 |
| clarkb | the workaround we have been using is to add force push to refs/* for administrators via a proposed change that we immediately approve | 17:15 |
| clarkb | I was tryign to stop needing to do that since we won't do that in production. But ya I guess an alternative is to setup bootstrappers in the ci jobs instead | 17:16 |
| fungi | infra-root (and anyone else interested): i'm looking at trimming the content on our splash page at https://opendev.org/ and wondering what do you think about maybe moving the faq into infra-manual and linking to it? and what about making the "how is development different..." section of the page part of the faq (or at least some of it, and just have a shorter paragraph about gerrit, | 17:38 |
| fungi | maybe something similar for the ci/zuul section too)? | 17:38 |
| clarkb | I like the idea of trimming it down. Makes the page less daunting and also theoretically makes porting to future gitea releases easier if they change the landing page template | 17:39 |
| fungi | for me the important sections to keep there are "what is opendev," "free software needs free tools," and "cloud donors" | 17:40 |
| fungi | oh, and "contact info" and "service vulnerabilities" of course | 17:40 |
| fungi | i might also shift the donors higher up the page, like right after the "what is..." section | 17:41 |
| tonyb | All of that sounds good to me. | 17:41 |
| fungi | starting on a draft later today, just softballing the pitch as i brainstorm | 17:41 |
| frickler | +1 sounds like a good idea to me | 17:42 |
| fungi | part of the incentive is the blog post about rackspace flex and opendev, the foundation is looking at reaching out to our other cloud donors to write up similar stories and i'm hoping to link them with the donors on the page | 17:42 |
| opendevreview | Tony Breeds proposed zuul/zuul-jobs master: ensure-devstack: Add the ability is specify a custom cpu model https://review.opendev.org/c/zuul/zuul-jobs/+/949547 | 18:00 |
| opendevreview | Jeremy Stanley proposed opendev/infra-manual master: Add frequently asked questions https://review.opendev.org/c/opendev/infra-manual/+/949924 | 18:15 |
| fungi | there's the first part ^ | 18:16 |
| fungi | heading out to grab a late lunch and then i'll push up the corresponding content removal change for system-config | 18:16 |
| michelthebeau | Hi, a peer was asking about "has dupicates" error for gerrit. The docs suggest "tell an admin" or create a bug report for gerrit: | 18:46 |
| michelthebeau | https://review.opendev.org/q/Ifb2f618f47ce403321c04f4eceeb7240758e71bc https://review.opendev.org/Documentation/error-has-duplicates.html | 18:46 |
| michelthebeau | Is this a good channel for that? | 18:46 |
| tonyb | michelthebeau: Is the first link the one you're trying to upload? | 18:47 |
| michelthebeau | The first link is the example. I've already had the user fix the review with a new change ID. I was just intending to follow the documented instruction when I came here "Since this error should never occur in practice, you should inform your Gerrit administrator if you hit this problem and/or open a Gerrit issue." | 18:48 |
| tonyb | michelthebeau: Well those docs are a little ... simple, it's pretty easy for a user to include a Change-ID especially when using cherry-picks or similar workflows | 18:54 |
| tonyb | Do you have any idea (docs?) on the process the user used to hit the problem? | 18:55 |
| tonyb | michelthebeau: Would you rather discuss this in the StarlingX matrix room? | 18:56 |
| clarkb | tonyb: in theory gerrit should update the existing change when pushing the same change id to the same project + branch tuple though | 19:05 |
| clarkb | so it is a bit unexpected that gerrit would hae two distinct changes here. And yes understanding how the user is pushing changes to gerrit would be helpful. Without that info I don't think there is much we can do | 19:05 |
| michelthebeau | I had only hinted at "how did you do that" when talking to Gustavo. I believe Gustavo understands the issue now. "The docs are a little simple" :) that is fair. | 19:05 |
| tonyb | clarkb: That's true. I wasn't considering that | 19:07 |
| clarkb | michelthebeau: if you have information on how this happened that may be useful in filing a bug with gerrit | 19:07 |
| michelthebeau | querying Gustavo. will get git and git-review version too | 19:08 |
| clarkb | but also the first chagne was createon april 4 and the second on april 7 | 19:08 |
| clarkb | so that info may not be in memory anymore I guess | 19:08 |
| clarkb | to be clear there is almost certainly a gerrit bug here, but in order to understand how that bug occurs we need more info. Without htat information we're likely stuck accepting this situation then waiting to see if it happens again | 19:10 |
| michelthebeau | git-review version 2.4.0 git version 2.34.; says "just use git review" command | 19:10 |
| michelthebeau | "I just used the 'git review' command' | 19:10 |
| michelthebeau | git version 3.24.1 (It wasn't supposed to be an end of sentence dot) | 19:12 |
| clarkb | so on april 4 eb28e5e is pushed to https://review.opendev.org/c/starlingx/app-rook-ceph/+/946355 then on april 7 that commit is updated creating 0f7dd25 and pushed to https://review.opendev.org/c/starlingx/app-rook-ceph/+/946585/1 both using git review? | 19:13 |
| michelthebeau | That's what he's indicating. | 19:13 |
| clarkb | I notice 946355 got no zuul testing either | 19:14 |
| clarkb | I wonder if the problem occurs on april 4 with the initial push | 19:14 |
| tonyb | clarkb: I noticed that too | 19:15 |
| clarkb | my notes say that is the day we upgrade gerrit to 3.10.5 | 19:15 |
| clarkb | hrm maybe its just the image though and we didn't do a restart there? I'm not seeing discussion of it in the irc logs | 19:16 |
| clarkb | https://review.opendev.org/c/opendev/system-config/+/946050 | 19:17 |
| clarkb | oh beacuse I'm looking at 2024 not 2025 | 19:17 |
| clarkb | yes 946355 appears to coincide with restarting gerrit | 19:19 |
| clarkb | https://meetings.opendev.org/irclogs/%23opendev/%23opendev.2025-04-04.log.html#t2025-04-04T17:18:15 | 19:19 |
| clarkb | theory: gerrit is restarted around 17:18. That change, 946355 is pushed at ~17:15. If that change was not properly indexed when we shut down gerrit it wouldn't be in the index until some later action indexes it. Not being in the index may break gerrits check for preexisting changes with the same changeid? | 19:20 |
| clarkb | and this was before we changed the signal emitted to gerrit to shutdown | 19:22 |
| clarkb | (just to rule out any relationship to that change possibly impacting graceful shutdown) | 19:22 |
| clarkb | michelthebeau: thank you for the report I think ^ with that theory above we have enough to put together a bug report for upstream | 19:23 |
| tonyb | That sounds plausible | 19:23 |
| michelthebeau | cool | 19:24 |
| opendevreview | Michal Nasiadka proposed openstack/diskimage-builder master: WIP: Add support for CentOS Stream 10 https://review.opendev.org/c/openstack/diskimage-builder/+/934045 | 19:28 |
| clarkb | michelthebeau: the second change has 10 patchsets on it. Can you ask if there were any errors pushing those? | 19:30 |
| clarkb | michelthebeau: I'm assuming not, but I want to be accurate in my bug report | 19:31 |
| clarkb | I suspect that the error started because for some reason the first change got reindexed and now the check failed. But that doesn't happen until all 10 of those new patchsets are pushed for some reason | 19:31 |
| michelthebeau | I'm also asking "you abandoned the first review because gerrit created the second?" | 19:31 |
| opendevreview | Michal Nasiadka proposed openstack/diskimage-builder master: WIP: Add support for CentOS Stream 10 https://review.opendev.org/c/openstack/diskimage-builder/+/934045 | 19:32 |
| michelthebeau | clarkb: gustavo writes "Up until patchset 9 I had no problem. But when I tried to rebase the analysis (patchset 10) we had this problem, and after abandoning the first analysis, it was possible. However, it worked once." | 19:38 |
| clarkb | michelthebeau: thank you for confirming | 19:39 |
| michelthebeau | clarkb: gustavo writes "[abandonded the first (apr 4) review] Because a team member tried to rebase the review and got this error. Trying to solve it (When I noticed this issue), I abandoned the first review." | 19:39 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Update higher Gerrit versions used in testing https://review.opendev.org/c/opendev/git-review/+/949916 | 19:40 |
| clarkb | https://issues.gerritcodereview.com/issues/418025702 has been filed | 19:46 |
| michelthebeau | thanks, signing off | 19:47 |
| opendevreview | Jeremy Stanley proposed opendev/system-config master: Remove content duplicated in the Infra Manual FAQ https://review.opendev.org/c/opendev/system-config/+/949939 | 19:51 |
| opendevreview | Tony Breeds proposed openstack/diskimage-builder master: Add new openstack/devstack based functional testing https://review.opendev.org/c/openstack/diskimage-builder/+/949942 | 20:07 |
| opendevreview | James E. Blair proposed opendev/zuul-providers master: Use zuul-supplied image formats https://review.opendev.org/c/opendev/zuul-providers/+/949944 | 20:13 |
| opendevreview | James E. Blair proposed opendev/zuul-providers master: Use zuul-supplied image formats https://review.opendev.org/c/opendev/zuul-providers/+/949944 | 20:14 |
| clarkb | fungi: the faq update to manual lgtm. I think we can probably just alnd that | 20:17 |
| fungi | i have questions about the continued relevance of a few items in there, but figured it was best to start with a verbatim forklift and then we can revise in-place after | 20:18 |
| clarkb | yes oen of them talks about it being early days in the opendev transition :) | 20:19 |
| clarkb | but agree we can forklift then edit later | 20:19 |
| clarkb | on the gitea side I'm waiting for the screenshot to show me things render properly there | 20:19 |
| clarkb | the linux kernel is improving the performance of swap | 20:40 |
| clarkb | maybe in 5 years having jobs swap won't be quite as bad as it is today | 20:41 |
| clarkb | fungi: https://44a737a17d7e744da544-e8c985e942bf44b286d3f5e0d40a9d67.ssl.cf5.rackcdn.com/openstack/c6b69397f8f24c6aa2e4f293a612c23e/bridge99.opendev.org/screenshots/gitea-main.png | 20:46 |
| fungi | looks good for my first attempt | 20:46 |
| clarkb | yup +2 from me | 20:47 |
| tonyb | Looks good! | 20:47 |
| fungi | i'm noticing that the prose in the "free software needs free tools" section seems to build on the earlier removed sections and could use a bit of minor rewording | 20:47 |
| opendevreview | Jeremy Stanley proposed opendev/git-review master: Update higher Gerrit versions used in testing https://review.opendev.org/c/opendev/git-review/+/949916 | 20:52 |
| fungi | switching that ^ to wip for now since i need to crank up the timeout significantly to get proper log collection for the gerrit service to figure out why all the tests are timing out connecting | 20:53 |
| fungi | probably the jdk version is causing it to hang when starting or something | 20:53 |
| clarkb | fungi: gerrit 3.11 is going to require the project acl setup if we're doing any modifications to those | 20:59 |
| clarkb | fungi: I think I would reduce the scope to gerrit 3.10 with java 17 | 20:59 |
| fungi | well, 3.10 is also timing outy | 20:59 |
| clarkb | ya I'm wondering if the upstream 3.10 war can't run under java 21 | 20:59 |
| fungi | yeah, it may be that 3.10 doesn't work with java 21 | 20:59 |
| fungi | but if i can get service logs that will help narrow it down | 21:00 |
| clarkb | ya that would help quite a bit | 21:00 |
| fungi | we were testing with 3.9 previously, so the update to 3.10 is not all that urgent as we weren't very far behind like we have been in the past | 21:00 |
| clarkb | the other thing to consider is the tests run java -jar if that java is java11 and not java17 its possible neither 3.10 or 3.11 are happy | 21:02 |
| clarkb | I don't know how the packaging resolves java to a specific version | 21:02 |
| fungi | fair. but the 3.10 test was working before i switched from installing openjdk-17 to openjdk-21 | 21:03 |
| fungi | leading me to suspect it just may not work with 21 | 21:03 |
| clarkb | aha | 21:04 |
| fungi | the 3.11 test was failing with openjdk-17 and with an error that made it sound like it needed newer java | 21:04 |
| fungi | i was hoping i could just get them both running with openjdk-21 and avoid having to pass custom bindep profiles for choosing java versions on the same platform | 21:05 |
| clarkb | fungi: if you look in the tests' _run_gerrit method it already attemps to attach the gerrit log files as details. Implying it never got far enough to write the logs files (a good indication something with the jvm is indeed at play) | 21:19 |
| clarkb | oh ya its saying error_log not found | 21:21 |
| clarkb | etc | 21:21 |
| clarkb | either the paths are wrong or the files never get written | 21:21 |
| fungi | i'll dig deeper into it tomorrow, coming up on my eod at this point | 21:22 |
| opendevreview | Clark Boylan proposed opendev/git-review master: Add more gerrit startup logging https://review.opendev.org/c/opendev/git-review/+/949950 | 21:28 |
| clarkb | that may be helpful not sure | 21:28 |
| clarkb | ssh'ing into the test nodes running for ^ I don't get a prompt | 21:39 |
| clarkb | that is unexpected | 21:39 |
| clarkb | oh its just very slow? | 21:40 |
| clarkb | fungi: based on not getting output from ^ that change in the logs I suspect that gerrit.sh start isn't actually returning and so we're hanging there and not progressing | 21:42 |
| clarkb | ya if I run ps there are a bunch of gerrit.sh start processes | 21:44 |
| clarkb | I need to put this down but two other things I notice the gerrit.config from the golden site is fairly disjoint from the config template that we write out. Its possible that we need additional config there. However when manually running a copy of the golden site it fails immediately for me (different than the other behavior which doesn't return from gerrit.sh start). Then the other | 21:59 |
| clarkb | thing I notice is that stracing the running gerrit.sh processes they seem to be running dirname . in a tightloop | 21:59 |
| clarkb | this probably needs to be debugged more frmo the bottom up updating things for gerrit we know need updating then see what behaviopr we get since this could all be side effects of staleness | 22:01 |
| clarkb | ok I've just had a conversation wtih Martin Fick on Gerrit's Discord about our two chagnes with one change id situation | 23:14 |
| clarkb | tl;dr is that yes if the index does not have up to date data then you can run into this problem so my hunch was a good one | 23:15 |
| clarkb | It seems this is/was fairly common with the haplugin and restarting constituent nodes of the gerrit cluser where they would get out of sync with one another and if you pushed to the wrong server you could generate this problem | 23:15 |
| clarkb | https://gerrit-review.googlesource.com/c/plugins/high-availability/+/422559 was written to address that. Basically a solution that reindexes things if they are discovered to be stale | 23:15 |
| clarkb | In our case we don't run the ha plugin we have a single server. It sounds like we can just manually trigger reindexing on gerrit startup to mitigate this problem | 23:16 |
| clarkb | bit of a brute force but one that we actually already apply when we do upgrades between gerrit releases most of the time since the index versions update | 23:16 |
| clarkb | the reason we saw it this time is we went from 3.10.4 to 3.10.5 which had no index updates so we don't reindex then boom. I'll note the 3.10 to 3.11 upgrade also does not have index updates. Nor does the 3.10.5 to 3.10.6 update so we've got some upgrades that will need manual reindexing triggers | 23:17 |
| clarkb | but that explains why we don't see this more often I think | 23:17 |
| tonyb | So the suggestion is to include the reindex as part of our general gerrit restart process? | 23:18 |
| tonyb | but also thanks clarkb! | 23:18 |
| clarkb | then finally we can probably have gerrit track staleness of indexes relative to its git pushes inteernally and have it elect to reindex things on its own in a manner similar to the haplugin. But that requires new code and I'm not sure anyone is volunteering to do that (I indicated I could try to look at it if I find time but I'm low on that resource right now) | 23:18 |
| clarkb | tonyb: ya, I basically said "our indexes are small enough we can reindex on startup" and they said yes that should work for you but isn't a general solution because other gerrits are larger and reindex for them is much more costly | 23:19 |
| clarkb | we can use the 3.10.6 update as the guinea pig for the process | 23:20 |
| tonyb | Okay cool | 23:20 |
| tonyb | Sounds good | 23:21 |
| clarkb | I'm not familiar with the internals of Gerrit in this portion of the code (to be fair I'm not really familar with any of GErrit internals but I have read through other different parts of gerrit for random things) | 23:23 |
| clarkb | but maybe taking bits from the haplugin I can slap something together | 23:23 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
