December 2020 - service-discuss

[all] Dynamic Zuul results table in Gerrit 3
by Radosław Piliszek 04 Aug '22

04 Aug '22

Hello Fellow OpenStack and OpenDev Folks! TL;DR click on [3] and enjoy. I am starting this thread to not hijack the discussion happening on [1]. First of all, I would like to thank gibi (Balazs Gibizer) for hacking a way to get the place to render the table in the first place (pun intended). I have been a long-time-now user of [2]. I have improved and customised it for myself but never really got to share back the changes I made. The new Gerrit obviously broke the whole script so it was of no use to share at that particular state. However, inspired by gibi's work, I decided to finally sit down and fix it to work with Gerrit 3 and here it comes: [3]. Works well on Chrome with Tampermonkey. Not tested others. I hope you will enjoy this little helper (I do). I know the script looks super fugly but it generally boils down to a mix of styles of 3 people and Gerrit having funky UI rendering. Finally, I'd also like to thank hrw (Marcin Juszkiewicz) for linking me to the original Michel's script in 2019. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019051… [2] https://opendev.org/x/coats/src/commit/444c95738677593dcfed0cfd9667d4c4f0d5… [3] https://gist.github.com/yoctozepto/7ea1271c299d143388b7c1b1802ee75e Kind regards, -yoctozepto

7 11

OpenDev git error: RPC failed; result=18, HTTP code = 200iB | 57.00 KiB/s
by Pengzhi 18 Dec '20

18 Dec '20

Hi OpenDev team, When trying to pull tripleo from opendev.org, git failed with Fatal Error 128. Can you please check and fix it? [ooo@VM-3O ~]$ git config http.postBuffer 24288000 [ooo@VM-3O ~]$ git clone https://opendev.org/openstack/tripleo-quickstart-extras/ Cloning into 'tripleo-quickstart-extras'... remote: Enumerating objects: 19996, done. remote: Counting objects: 100% (19996/19996), done. remote: Compressing objects: 100% (6835/6835), done. error: RPC failed; result=18, HTTP code = 200iB | 57.00 KiB/s     fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed The Error is reproducible with/without the following git configurations [ooo@VM-3O ~]$ git config --list core.compression=-1 http.postbuffer=24288000 Thanks!

3 4

powerkvm CI nova cloning
by Ian Wienand 11 Dec '20

11 Dec '20

Hello, We've identified that powerkvm CI seems to be in a loop attempting to clone nova. It would be helpful if we could get this to stop :) It's just a guess, but we found a similar problem in OpenDev where the executors were attempting to cache the repo, but their default timeout of 300 seconds wasn't long enough to complete the clone. They would kill their clone attempt and start over again immediately. In the Zuul executor logs you'll see something like 2020-12-10 02:02:08,578 ERROR zuul.ExecutorServer: [e: ...] [build:...] Got exception while updating repo gerrit/openstack/nova with a full traceback above. Our solution was to increase the git_timeout [1] to long enough for the clone to complete. The recent upgrade may be to blame. We're experimenting with different options for gc/repack, but cloning the repo from gerrit directly it close to 2gb. Another option is to convert this to cloning to https://opendev.org. Please reach out if there is anything we can do to help. Thanks, -i [1] https://review.opendev.org/c/opendev/system-config/+/766400

2 1

Re: Opendev review crawler
by Chouchen, Moataz 09 Dec '20

09 Dec '20

Dear Jeremy, Ian, Thank you for your kind support and for removing firewall rules that block my access. I will add more delay and use a User-Agent header with my contact details in my future requests as you recommended. I also agree with you that a dump of specific database tables would be great and can encourage other researchers to conduct more studies on code review and benefit from the available rich review data on Opendev projects. Kind regards, Moataz ________________________________ From: Jeremy Stanley Sent: Wednesday, November 4, 2020 12:12 PM To: service-discuss(a)lists.opendev.org Cc: Chouchen, Moataz; Ouni, Ali; Laurin, François Subject: Re: Opendev review crawler On 2020-11-04 00:02:33 +0000 (+0000), Chouchen, Moataz wrote: [...] > For this purpose of study, we need to collect the whole Opendev > data. Right now, we collected data from 2020 to 2015 and still > need the other years. As per requested we will add more waiting > time to my process to let the server catch up. If you also have > any other suggestions that will help, we will be happy to try it. [...] Just adding that delay/throttle will probably suffice, but also Ian's suggestion to set a custom user agent string with contact info on your API requests can help avoid confusion and make it easier for site administrators to reach you if there's a problem with your queries. I've gone ahead and removed the firewall rules we had temporarily blocking your IP addresses as well. If you have any questions, please don't hesitate to get in touch through our service-discuss mailing list. Good luck on the research too, I can't wait to read your findings! -- Jeremy Stanley

2 1

Meeting Agenda for December 8, 2020
by Clark Boylan 07 Dec '20

07 Dec '20

We will meet on December 8, 2020 at 19:00 UTC in #opendev-meeting with this agenda: == Agenda for next meeting == * Announcements ** Need volunteer to run next week's meeting. Or we can cancel. * Actions from last meeting * Specs approval * Priority Efforts (Standing meeting agenda items. Please expand if you have subtopics.) ** [http://specs.openstack.org/openstack-infra/infra-specs/specs/update-config-… Update Config Management] *** topic:update-cfg-mgmt *** Zuul as CD engine ** OpenDev *** Post Gerrit Upgrade Updates **** Configuration tuning ***** Adding config to jgit.config ***** Using strong refs for jgit caches ***** Enabling git protocol v2 ***** Batch user groups and threads **** Zuul results table rendering (ianw 20201208) **** WIP changes (ianw 20201208) **** Zuul needs updates to properly support Gerrit 3.3.0 * General topics ** Bup and Borg Backups (clarkb 20201208) ** Docker rate limiting is being seen (at least in limestone) (clarkb 20201208) ** PTG followups (clarkb 20201208) ** meetpad was not useable for (some?) participants from China (frickler 20201208) *** clarkb trying to set up time with Horace to test a meetpad call with a participant in China. ** Splitting puppet else into specific infra-prod jobs (clarkb 20201208) *** Should be mostly mechanical *** Does it make sense to try and sprint this? Have several people work on getting it done in a short period of time? ** Trusty Upgrade Progress (clarkb 20200929) *** Wiki updates * Open discussion

1 0

Re: [all][infra] CI test result table in the new gerrit review UI
by Ian Wienand 02 Dec '20

02 Dec '20

On Fri, Nov 27, 2020 at 02:11:21PM +0000, Tristan Cacqueray wrote: > From what I understand, we can either use java and the polymer template > system, or the javascript api to implement the zuul results table. This was discussed today in the infra meeting @ [1] There was a couple of broad conclusions. There's no dispute that it works, for now. The maintenace of this in perpituity is the major concern. Some points: There are already two Zuul plugins in the upstream repos zuul : https://gerrit.googlesource.com/plugins/zuul -- This is rather badly namespaced, and is focused on showing the status of Depends-On: changes a cyclic dependencies zuul-status : https://gerrit.googlesource.com/plugins/zuul-status/ -- This is also using a broad namespace, and appears to be related to showing the ongoing job status in the UI directly, but does not show final results. An example I found at [2] from an old wikimedia thread Upstream have shown to take some interest in these plugins when undertaking upgrades to polymer, etc. and thus integrating there is seen as the best practice. Unless we have a strong reason not to, we would like to consume any plugins from upstream for this reason. It would be in our best interest to work with these existing plugins to clarify what they do more directly and come up with some better namespacing to make it more obvious as potential number of plugins grows. The current proposed implementation does not look like any of the upstream plugins. Admittedly, [3] shows this is not a strong eco-system; the documentation is mostly TODO and examples are thin. Implementing this with Reason [4] adds one more significant hurdle; we have no track record of maintaing this javascript dialect and it is not used upstream in any way. It also doesn't use the same build and test frameworks; this may not be a blocker but again creates hurdles by being different to upstream. One more concrete comment is that I'm pretty sure walking the shadow DOM to update things is [5] not quite as intended and we should be using endpoints. In trying to find the best place to start, I've pulled out bits of the checks plugin, image-diff plugin and codeeditor plugin into the simplest thing I could get to a tab with a table in it @ [6]. You can see this for now @ [7]. I think we're going to get more potential eyes using polymer components and making things look like the existing plugins. It's a matter of taste but I think the blank canvas of a separate tab serves the purpose well. I think with the Bazel build bits, we can ultimately write an upstream Zuul job to build this for us in gerrit's Zuul (corvus might know if that's right?) Tristan -- maybe as step one, we could try integrating what you have into that framework? Maybe we rewrite the ReasonML ... but having it something is step 1. Overall I think this is the broad strokes of what we would look at sending upstream. If they think it's too specific, Zuul tenant seems a logical home. We would also like to expand the gate testing to better handle testing plugins. This will involve us automatically adding a repo, sample change, and Zuul user comments during the gate test. A logical extension of this would be to take samples using a headless browser for reporting as artifacts; held nodes can also be used for advanced debugging. This will give us better confidence as we keep our Gerrit up-to-date. I'd like to solict some feedback on the checks plugin/API, which Zuul added support for with [8]. My understanding is that this has never really consolidated upstream and is under redevelopment [9]. I don't think there's much there for us at this point; even still seeing as we are so Zuul centric we might be able to do things with a specific plugin this API will never do. -i [1] http://eavesdrop.openstack.org/meetings/infra/2020/infra.2020-12-01-19.01.l… [2] https://imgur.com/a/uBk2oxQ [3] https://gerrit-review.googlesource.com/Documentation/pg-plugin-dev.html [4] https://reasonml.github.io/ [5] https://github.com/softwarefactory-project/zuul-results-gerrit-plugin/blob/… [6] https://github.com/ianw/gerrit-zuul-summary-status [7] https://104.130.172.52/c/openstack/diskimage-builder/+/554002 [8] https://opendev.org/zuul/zuul/commit/e78e948284392477d385d493fc9ec194d54448… [9] https://www.gerritcodereview.com/design-docs/ci-reboot.html

2 1