- service-discuss - lists.openstack.org

Deploy a new refstack.openstack.org instance
by Martin Kopec 28 Jan '21

28 Jan '21

Hi, I'd like to ask for help with deploying a new refstack.openstack.org instance [1]. I also added this topic to the weekly meeting agenda [2]. I'll help with testing the new instance before we put it to the production. [1] https://review.opendev.org/c/opendev/system-config/+/705258 [2] https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Weekly_Project_In… Thank you for your help. Regards, -- Martin Kopec Software Quality Engineer Red Hat EMEA <https://www.redhat.com>

2 1

Fwd: [All][StoryBoard] Angular.js Alternatives
by Kendall Nelson 26 Jan '21

26 Jan '21

Hello Everyone! The StoryBoard team is looking at alternatives to Angular.js since its going end of life. After some research, we've boiled all the options down to two possibilities: Vue.js or React.js I am diving more deeply into researching those two options this week, but any opinions or feedback on your experiences with either of them would be helpful! Here is the etherpad with our research so far[3]. Feel free to add opinions there or in response to this thread! -Kendall Nelson (diablo_rojo) & The StoryBoard Team [1] https://vuejs.org/ [2] https://reactjs.org/ [3] https://etherpad.opendev.org/p/replace-angularjs-storyboard-research

5 5

Meeting agenda for January 26, 2021
by Clark Boylan 26 Jan '21

26 Jan '21

We will meet on January 26, 2021 at 19:00 UTC in #opendev-meeting with this agenda: == Agenda for next meeting == * Announcements * 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 *** Service Coordinator position nominations **** http://lists.opendev.org/pipermail/service-discuss/2021-January/000161.html less than a week remaining. *** Gerrit account and group inconsistencies **** ~1 group has a subgroup membership loop. **** We have ~109 accounts with preferred email addresses that don't have a matching external id ***** Some of these are inactive accounts that we can more properly retire, others are accounts that can be set to inactive due to lack of external ids, some have email addresses we might convert to preferred email address, and others will need proper digging. **** We have ~642 accounts with conflicting emails in their external ids. This needs more investigating to better understand the fix for. **** Need to correct the ~642 external id issues before we can push updates to refs/meta/external-ids with Gerrit online. **** Workaround is we can stop gerrit, push to external ids directly, reindex accounts (and groups?), start gerrit, then clear accounts caches (and groups caches?) *** WIP changes (ianw 20210105) **** Zuul should now support these properly. We need to retest. *** Gerrit 3.3.1 includes the fix for Zuul and Zuul has the fixes too. *** Configuration tuning **** Using strong refs for jgit caches **** Batch user groups and threads * General topics ** OpenAFS cluster status (clarkb 20210126) *** https://review.opendev.org/c/opendev/system-config/+/771521 properly install new openafs on xenial openafs clients. *** What is server cluster status? Have they all been upgraded to 1.8.6? **** Upgrading servers to bionic then focal in place is next? ** Bup and Borg Backups (clarkb 20210126) *** wiki backup status *** borg disk consumption workarounds ** Picking up steam on Puppet -> Ansible rewrites (clarkb 20210126) *** Enable Xenial -> Bionic/Focal system upgrades *** Clarkb to write up an etherpad that captures the rough TODO list. ** two-review rule impact on low-activity projects (zbr 20210126) *** projects like git-review rely on infra team and delay changes *** Properly setting expectations for what our small team is able to pay attention to *** Communicating the topics that are consuming our time day to day **** We update the priority efforts documentation and possibly link to a storyboard dashboard there that is populated with the current fires. * Open discussion

1 0

Requesting help with OpenStack configuration files
by Bessghaier, Narjes 19 Jan '21

19 Jan '21

Dear OpenStack team, I’m a Ph.D. student in software engineering at the ETS Montreal, University of Quebec working on the quality and configuration of web-based software systems. I’m particularly interested in analyzing configuration files from different OpenStack files. One of the main challenges I am currently facing is the proper identification of configuration files. I’m mostly confused between the python files used for production and the python files used for configuration. I am kindly requesting your precious help with the following questions: 1- How to distinguish between python files used for configuration and python files used for production? It will be very helpful if there are some configuration-based patterns (eg, textual patterns or expressions) that we can find in python files to help us distinguish between source code and configuration files? 2- Certain python files use the oslo_config to access and define configuration options. Could "all" these python files be considered as configuration files? For example, the following python file of the keystone project: keystone/keystone/conf/auth.py, is it considered a source code or a configuration file? 3- Why are there different source code and configuration repositories for OpenStack projects (eg, nova and puppet-nova)? For instance, does the OpenStack-nova service have some configuration files in its repository and have the puppet-nova as a separate configuration repository as well? Thank you very much in advance for your time and your help! Kind regards, Narjes Bessghaier Narjes Bessghaier Ph.D student in Software Engineering École de Technologie Supérieure (ETS)| University of Quebec Montreal, Canada narjes.bessghaier.1(a)ens.etsmtl.ca<mailto:yasmine.makroum.1@ens.etsmtl.ca>

2 1

Team Meeting Agenda for January 19, 2021
by Clark Boylan 18 Jan '21

18 Jan '21

We will meet January 19, 2021 at 19:00UTC in #opendev-meeting with this agenda: == Agenda for next meeting == * Announcements * 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 *** Service Coordinator position nominations **** http://lists.opendev.org/pipermail/service-discuss/2021-January/000161.html *** Zuul results table rendering (ianw 20210105) **** https://review.opendev.org/q/topic:%22gerrit-admin-user%22+status:open *** WIP changes (ianw 20210105) **** Zuul should now support these properly. We need to retest. *** Gerrit 3.3.1 includes the fix for Zuul *** Configuration tuning **** Using strong refs for jgit caches **** Batch user groups and threads *** Gitea 1.13.1 now available **** https://review.opendev.org/c/opendev/system-config/+/769226 * General topics ** OpenAFS cluster status (clarkb 20210119) *** New packages built for CentOS *** Need to sort out openafs-client installation on Debian Buster *** Are we properly installing openafs-client on Xenial? *** https://review.opendev.org/c/opendev/system-config/+/771268 ** Picking up steam on Puppet -> Ansible rewrites (clarkb 20210119) *** Enable Xenial -> Bionic/Focal system upgrades ** Discuss infra-core (on behalf of OpenStack) (mnaser) ** two-review rule impact on low-activity projects (zbr 20210115) *** projects like git-review rely on infra team and delay changes *** risks for enabling exceptions? how could we expose these in gerrit? *** apparently that issue is affecting multiple projects, maybe we can think about a generic solution? ** Bup and Borg Backups (clarkb 20210105) * Open discussion

1 0

OpenAFS timestamp rollover issues, discussion and plan
by Ian Wienand 16 Jan '21

16 Jan '21

Hello, We were made aware of an issue relating to handling of a timestamp rollover affecting OpenAFS deployments [1] that in the worst case results in inability of the client and server to communicate. From the OpenAFS 1.8.7 release: It fixes a critical issue in the generation of Rx connection IDs that prevent Rx clients started after 14 Jan 2021 08:25:36 AM UTC from being able to successfully make connections. In addition to cache managers and client utilities, fileservers and database servers are also affected, since they initiate connections to (other) database servers during their normal operation. The issue occurs only at startup, while generating the initial connection ID, so cache managers or servers that were already running at the time in question will not be affected until they restart. The full extent of the issues for our particular circumstances is still somewhat unclear. We run a heterogeneous deployment with all clients under our control using 1.8.6 release, but all servers running 1.6 era packages from Ubuntu Xenial. My current understanding is that since we started our servers and clients before the problem time, we are currently unaffected. When we restart our servers, due to differences in the code with our 1.6 versions, the bug will manifest more as periodic/random-ish I/O failures rather than a complete inability to communicate. We have rebuilt our openafs packages with the required fixes and deployed these to all clients under our control. Thus if any client restarts for whatever reason, they will at least be using fixed code. Some clients we have restarted just to ensure sanity of the new version against the existing severs (so far seems good). All clients have been checked for deployment of these new packages. We do not expect issues, but will monitor this situation. This leaves us with the server side. We have been told there are no fixes for the 1.6 servers planned. We do not have a wonderful answer here, unfortunately. We have planned to move our AFS infrastructure off the Xenial hosts it runs on for some time. These servers are all deployed with legacy puppet, something none of us want to spend significant time hacking on. There is also the small matter that 1.6 to 1.8 upgrades are not terribly well documented, to say the least. While we don't intend on restarting the servers, from time to time the cloud provider needs to migrate things or has other issues that affect uptime; we can't predict this other than it will happen, eventually. It seems our best option here is to take some down-time of the AFS services and perform a manual, in-place upgrade of the existing servers to 1.8 code. We will freeze these from ongoing automated config managment (puppet). This will allow us to deploy and evaluate 1.8 servers and keep with the principle of "change one thing at a time". Once we are in a steady state, we should have enough redundancy that we can replace the servers one-at-a-time with no, or very little, downtime. This gives us time to write, test and review Ansible based deployment as usual. When we do switch in new Focal based servers, we have the advantage we are not also trying to change the AFS version too. In some ways, it works out well (something about lemons and lemonade). We usually try to have a rollback plan with any upgrades. Since 1.6 is not getting updates, and as far as I know we still do not have the technology to move reality backwards in the time continum before the problem rollover time (if I do figure out time travel, I will be sure to pre-respond to this message that it can be ignored) our revert plans seem limited. However, we will be no worse off than if the servers decided to reboot themselves now. In it's defence, this is not new code; 1.8.0 came out early 2018 and we have been using 1.8 clients since we started integrating arm64. The queues are very deep at the moment, so we'd obviously like to minimise downtime. I'd suggest that I could start looking at this around 2021-01-17 21:00UTC, following the plan layed out in [2], which interested parties should definitely review. This should hopefully be a quiet time, and give us a decent runway if we do hit issues. -i [1] https://lists.openafs.org/pipermail/openafs-info/2021-January/043013.html [2] https://etherpad.opendev.org/p/infra-openafs-1.8

3 3

Meeting Agenda for January 5, 2021
by Clark Boylan 05 Jan '21

05 Jan '21

Happy New Year and welcome back. We will have a meeting tomorrow, though depending on attendance it may be on the less formal side of things. I figure we'll try to have an agenda though. Here is our agenda for the meeting on January 5, 2021 at 19:00UTC in #opendev: == Agenda for next meeting == * Announcements * 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 ***** Using strong refs for jgit caches ***** Batch user groups and threads **** Zuul results table rendering (ianw 20210105) **** WIP changes (ianw 20210105) ***** This needs work in Zuul to not treat these changes as mergeable. *** Gerrit 3.3.1 includes the fix for Zuul *** Gitea 1.13.1 now available * General topics ** OpenDev Project Update for the Foundation Annual Report (clarkb 20210105) ** Bup and Borg Backups (clarkb 20210105) ** 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

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 10 Dec '20

10 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