March 2020 - infrastructure - Fedora mailing-lists

About JS framework
by Pierre-Yves Chibon 17 Oct '22

17 Oct '22

Good Morning Everyone, Our infrastructure is mostly a python store, meaning almost all our apps are written in python and most using wsgi. However in python we are using a number of framework: * flask for most * pyramid for some of the biggest (bodhi, FAS3) * Django (askbot, Hyperkitty) * TurboGears2 (fedora-packages) * aiohttp (python3, async app: mdapi) While this makes sometime things difficult, these are fairly standard framework and most of our developers are able to help on all. However, as I see us starting to look at JS for some of our apps (fedora-hubs, wartaa...), I wonder if we could start the discussion early about the different framework and eventually see if we can unify around one. This would also allow those of us not familiar with any JS framework to look at the recommended one instead of picking one up semi-randomly. So has anyone experience with one or more JS framework? Do you have one that would you recommend? Why? Thanks for your inputs, Pierre

10 12

The packages app has a short runway
by Randy Barlow 24 Apr '20

24 Apr '20

Greetings! The packages app is running on Fedora 30, and its dependencies are not available in Fedora 31+ as I understand it. This means it has about 7 months before we need to do something about it, or shut it off. Do we know if it can run on RHEL 7?

9 31

Re: Issue with Fedora GeoIP service
by Kevin Fenzi 09 Apr '20

09 Apr '20

On Fri, Dec 06, 2019 at 04:49:15PM +0000, Tom Hughes wrote: > On 06/12/2019 16:41, Martin Kolman wrote: > > On Fri, 2019-12-06 at 08:38 -0600, Chris Adams wrote: > > > > > I also installed the Fedora 31 GeoIP packages and ran the geoipupdate, > > > and that DB has the correct info. > > > > IIRC the infra team mentioned some issues with the new geoip database > > being incompatible with how the service is currently implemented, > > resulting in being stuck with an outdated database until this is resolved. > > Sounds like it maybe doesn't have support for GeoLite2 and is using the > old MaxMind GeoLite Legacy databases which haven't been updated since > the start of this year. Yes, that is exactly the case. We recently looked at this to see if we could retire the service, but it looks like it's still needed, so we need to figure out how to get cycles to update it. If someone wants to work on this, let us know! kevin

7 13

Update geoip-city
by Adrian Reber 31 Mar '20

31 Mar '20

Attached is the patch to take the upstream update of geoip-city to Fedora infrastructure. I would like to try this first in staging and need some help to run the corresponding playbook to see if it works in our environment. Adrian

2 2

Re: The Git forge decision (was CPE Weekly: 2020-03-28)
by Neal Gompa 30 Mar '20

30 Mar '20

On Mon, Mar 30, 2020 at 8:13 AM Nicolas Mailhot via devel <devel(a)lists.fedoraproject.org> wrote: > > Le dimanche 29 mars 2020 à 23:47 -0400, Neal Gompa a écrit : > > > > > As a General User > > > I want to access repos fully over https > > > For environments where SSH is blocked > > > > I would be really curious if the Red Hat Infrastructure Security guys > > have changed their opinion on this after four years of blocking the > > development of this feature in Pagure. The two major reasons we don't > > have this in Pagure are: > > Neal, > > Security is the usual excuse not to implement stuff. That does not work > when competing with others that did their homework. As you noted > yourself ssh accesss is not blameless either. > > Gitlab and Github work in https mode. Pagure does not. End of story. > > Expecting others to hole their security with corkscrew because of the > ssh holy cow was never going to impress any third party. > You don't have to tell me, I already know. It was intentionally not implemented. And even with all that, we *do* have HTTPS through SSO on src.fp.o. We just don't have it on pagure.io. Don't expect it to be available with the move to GitLab. GitLab admins have a toggle they can use to disable HTTPS pushing for policy reasons, and I will strongly bet on it being flipped so that HTTPS pushing will not be available in our GitLab. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

The Git forge decision (was CPE Weekly: 2020-03-28)
by Neal Gompa 30 Mar '20

30 Mar '20

On Sat, Mar 28, 2020 at 4:12 PM Aoife Moloney <amoloney(a)redhat.com> wrote: > > ### Other Updates > > #### GitForge Decision > * After evaluating over 300 user stories from multiple stakeholders we > have aligned on a decision for the Gitforge that CPE will operate for > the coming years. We are opting for Gitlab for our dist git and > project hosting and will continue to run pagure.io with community > assistance. > * Check out our GitForge decision on the Fedora Community blog > https://communityblog.fedoraproject.org/ > * And at the CentOS blog page > https://blog.centos.org/2020/03/git-forge-decision/ > * Keep an eye out for mails in the coming months to the devel lists as > we plan transitions and next steps with GitLab > * We would like to express our sincere thank you to all who > contributed requirements to us! > > I'm going to start with the delivery of this decision sucked. If I hadn't been alerted to look for this by other folks due to my advocacy and community building work around Pagure, I would *not* have known that the decision had been made. This is in contrast to the *big deal* that was made about starting this "decision process". I don't know if there were folks counting on nobody noticing this or not, but this is not a good way to deliver effectively a major decision like this. I also absolutely *refuse* to deal with the fact that this thread was split into three mailing lists. All three are connected to this thread, and I will take responses from all of them and follow them accordingly. Enough about that, let's talk about the actual decision. So, you're going with GitLab. It's interesting to note that the particulars about going to GitLab are not even figured out. It is curious that "SAAS" is mentioned very prominently. That made me a bit more curious, so I looked at the "final" feature requirements. Needless to say, I was extremely disappointed. To put it bluntly, there are *zero* free and open source solutions that satisfy your needs. From this, I understood why you said GitLab and SaaS. You want GitLab Ultimate, the proprietary solution that includes several extra features on top to satisfy the following requirements (quoted from your blog post): > * There is a need for CentOS Stream to integrate with a kernel workflow that is an automated bot driven merging solution (merge trains). This allows for richer CI capabilities and minimizes the need for human interaction > * Gitlab allows for project planning capability which could make multiple trackers such as Taiga redundant, allowing for the planning and tracking to reside within the repo. It would enrich the current ticket based solution that Pagure has evolved into for some groups These two requirements *alone* automatically force us to GitLab Enterprise Ultimate Edition, as there is no other solution available that satisfies those requirements in one product. Merge trains *is* a feature of Pagure when combined with Zuul, but GitLab's project planning features do not exist in *any* FOSS product, including GitLab CE (or GitLab Core as they call it now). There are mentions of other work that CPE team wants to do to better improve Fedora. Okay, sure. I even agree with some of them. And the time bomb that is FAS is definitely worth the attention (note that I am somewhat involved in the development of the Fedora AAA solution and am also working on trying to develop a community around it so it doesn't implode like virtually every other project under the Fedora umbrella, more on *that* a bit later). However, nobody has given me or anyone else in the Pagure community (which yes, is more than Pierre-Yves, thank you very much!) any concrete details of deficiencies they'd see that is not satisfiable by the community within a year before now. I've spent a little over a day analyzing the user stories and thinking about the gaps between Pagure and what the community wants, and I want to give some perspective here for some of these. I'm happy to accept refutations and other details to further enhance the color of these stories, of course. > 5 > As a RH Developer > I need the ability to privately comment on a PR > so that confidential information does not leak outside Red Hat Ignoring the mountainous levels of terrible problems that such a feature causes us *now* in the Red Hat Bugzilla, Pierre-Yves and I were literally discussing this with a Mageian who was interested in this feature for Pagure weeks ago. We had identified the feature as not difficult to implement but also simultaneously nobody really *wanted it now*. It surprises me that this is something that should be considered an important feature to preserve. It's actually a very *rare* feature, and does not exist in any forge today, presumably because it's actually a horrifically bad idea and antithetical to open development. GitLab itself lacks this feature, in all variants. > 16 > As a general user > I want to be able to create a bot/service account > That integrates with the gitforge in the same way as a human does This is a nice ask, but it's not a reasonably easy one to implement with our current system. This is a problem I've struggled with at $DAYJOB with GitLab as well, and frankly, if you have account integration with a single-sign-on system (which virtually all large-scale Git forge instances do), you can't really easily have this without causing major problems. Not the least of which is how you resolve account namespace collisions. There are also problems with maintaining and auditing, too. But it's certainly something I'd like to see in any forge (note that none implement this today either). > 29 > As a General User > I want to access repos fully over https > For environments where SSH is blocked I would be really curious if the Red Hat Infrastructure Security guys have changed their opinion on this after four years of blocking the development of this feature in Pagure. The two major reasons we don't have this in Pagure are: * There is a very strong push to not provide a way to bypass the SSO (ignoring the fact that SSH keys are effectively a bypass, but most security people are two-faced about this anyway) * There is a very strong push to not provide LDAP integration so that the required HTTP(S) Git proxy server would not be able to be implemented. Note that for GitLab, unless you configure it to have access to LDAP or set up personal access tokens, you cannot use HTTP(S) push at all. Once again, this totally bypasses SSO. If the same rules that applied to Pagure apply to GitLab, nobody is getting this feature anytime soon with GitLab. If the attitude toward this feature has finally changed, I'd love to know. Also, for those who don't know, Fedora's Dist-Git supports HTTPS push, and has for almost a year: https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits This is done by *forcing* an SSO flow for *fedpkg* itself and leveraging it as a credential and auth point. Unfortunately, this is not a general purpose feature because there's not an easy way to do that, so it's unavailable on pagure.io at this time. This mechanism for HTTP push is *not* possible with GitLab, and would be quite difficult to implement due to the crazy architecture internally. But if more *normal* HTTPS is acceptable (like through auth tokens or LDAP auth), then this is something that could be relatively quickly added to Pagure (there was some old code that never got merged two years ago, I still have it archived somewhere...). > 31 > As a General User > I can request access rights to a repository > So that I can contribute in a low friction manner I honestly don't know entirely what this means. Are we talking about having partial commit access (commit access to only some branches)? If so, there's a PR out for implementing this in Pagure under review: https://pagure.io/pagure/pull-request/4786 > 34 > As a General User > I want a mobile native app > To allow me contribute while away from my desk I don't have words for this... You folks know that only GitHub.com has an official mobile app, right? And the experience is not great... 🤦‍♂️ > 42 > As a General User > want a GUI to interface with the system as well as a CLI > so new users have an easier way to interface with it I'd like to point out that most popular GUIs for Git stuff are not forge specific and do not even do much for forge integration. But sure...? > 44 > As a General User > I want a temporary file (gist) > So that I can share code easily There seems to be a misunderstanding here... Gists are not temporary. They're lightweight *permanent* Git repos (in GitHub). GitLab stores them (called Snippets) as permanent things in the database (not a Git repo). Are you trying to conflate pastebin use-cases here? That's probably a very bad idea... > 46 > As a General User > I want to be notified of CVEs in my code > so that I can stay on top of critical vulnerabilities There are *zero* FOSS solutions for this in the forge space. This feature does *not* exist below GitLab Ultimate (the former Gemnasium service was integrated into it). > 47 > As a General User > I want integrated keyword support > to allow me automate a lot of my actions such as a rebuild / retest This is not a forge feature, this is a CI service feature. And note, GitLab CI does not support this. > 49 > As a General User > I want to gain analytics and insights from my code > so that I can have historic context to make decisions moving forward GitLab Enterprise features... > 51 > As a General User > I would like to track my work in an Agile manner > allowing me centralise all my planning in my forge and gain insights into how I am working. GitLab Enterprise features, as mentioned earlier. > 56 > As a General User > I want registry integration > so that I can store dependencies No, you don't. You *really* don't want this. Are you *sure* you know what you're asking for? You're suggesting three things here: * OSS solutions for this (including Fedora's own package/container infrastructure and hosted quay.io) are not good enough * You are ready to have even more arbitrary data stored in the Git system that may not follow our legal compliance * You are willing to pay the cost of having even more data stored > 57 > As a General User > I want the ability to have a private branch > So that I do not need to leave the code tree I am already in Just so everyone is *crystal clear*: you literally cannot do this. Git does not have a concept of private branches or private refs within a repository. You can have private forks, of course. And Pagure supports those just fine, just like GitLab and GitHub do. (also note, we *intentionally* do not have private repos turned on... if we want this, we could just flip a switch...) > 62 > As a General User > I want automerges when specific acceptance criteria are met > So that I do not need manual intervention So... Mergify then? This is not *currently* a GitLab feature, and Mergify does not support GitLab, last I checked. Only GitHub.com. It's been on my bucket for a while to look at extending Mergify to support Pagure for this, as it's a really nice feature... I want to take a moment to reflect on something that has been on my mind for a while now: Fedora has not done a good job being an umbrella organization. As an organization, we have done a huge disservice to all Fedora-affiliated projects by not allocating any community development effort or marketing effort. I know that Matthew Miller feels Fedora should evolve to being an operating systems factory[1] and to some extent that isn't a bad thought. But the Fedora Project was always intended to be more than just the Fedora Linux distribution. It has always been intended to be a home for Free and Open Source innovation. In a Hacker News thread last year[2], I had reflected on how proud I have been to be part of Fedora because we, as a community, weren't willing to just give up like so many others do. When FOSS solutions were inadequate, we built better ones. We've invented things that didn't exist before, and jump-started conversations about concepts that people didn't think of before. But there has been a bit of a dark side to this for Fedora. We've rarely given our projects an opportunity to grow beyond us. Off the top of my head, the *only* project that technically *started* in Fedora and became successful was Ansible. And if I'm being totally brutally honest, it was only successful because the engineers who were passionate about it had to quit Red Hat and create AnsibleWorks to push it to success. It was successful *despite* Fedora. Maybe soon we'll be able to add HyperKitty and Postorius to that, as I've been seeing deployments of that come online over the past few months. It's taken a while, but HyperKitty is finally taking off. There was one person I talked to who told me that HyperKitty made mailing lists enjoyable and she didn't know the project came from Fedora originally. Again, seeing success despite Fedora. When I talk to folks in other communities and show them some of the infrastructure projects we've developed as part of trying to build communities around them, I've literally had people tell me that they wish they had known we made them before, because it solved all their problems they were struggling with. That's both amazingly uplifting and terribly depressing at the same time. I'm not even putting in a lot of effort and we get so much more out of it. It didn't take a lot for me to get openSUSE interested in our new AAA solution and contributing. That tells me that we're just not trying. And really, that's obvious. Even a simple comparison of the Fedora and openSUSE project landing pages show that Fedora gives zero attention to the projects that exist under its umbrella. When you look at the openSUSE landing page, the distribution and major software projects under the umbrella are all broadcasted there. It makes it so much easier to discover and generate interest. I'm not saying I love every aspect of the openSUSE marketing. Far from it! But this is one thing they do right that we do terribly wrong. And then we sit back and wonder why our projects fail to generate interest beyond a few folks in Fedora itself. It's a self-fulfilling prophecy. This is something we need to fix for *all* our projects: present and future. In the end, I think the biggest disappointment of this process is that it feels like it demonstrates that Fedora leadership and management is not as committed to its mission and vision[3] as I hoped it was. I realize that I should not be surprised by this. Most of the leadership and management are no longer the idealistic people they were when they first became involved. And it's even harder to be idealistic when it's so easy to give in when you work for "open source company" that increasingly uses proprietary software to manage its workflow (to be fair, I think at this point virtually all major companies do this, which more or less demonstrates the amoral nature of these entities). Maybe I'm just an old remnant of a bygone era, but I personally remain somewhat idealistic, even as I have progressed over the years. I also remain hopeful that other members of the community are of similar mind. And perhaps this is a bit of a fool's hope, but I hope the CPE team reconsiders their decision, or at least would be willing to provide more context on the gaps they felt pushed them over so they could be prioritized for Pagure development (and maybe we can develop them fast enough so that we don't have to switch...). I think this is also an important indicator that Open Source has *not* won and it is *not* the default. People who keep saying otherwise need to seriously look hard at the landscape and realize that we have a long way to go before Open Source becomes the true default. It behooves us to become cognizant of this and push for freedom whenever and wherever we can. As for me? Well, I will do my best to try to help develop the Pagure community. I'm still committed to assisting the Free Software Foundation and other communities with using and contributing to Pagure. I hope others within the community will consider helping too. Pagure provides unique features that do not exist in any other forge, in large part because it is driven by an ideal that open data and freedom should be core tenants of software project management. And hey, I hear whispers of new Pagure instances being set up all the time! We're doing something right here, and it'd be a shame to squander it. Heh, the irony is that I started using and contributing to Pagure *because* I was burned by GitLab... [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [2]: https://news.ycombinator.com/item?id=19356307 [3]: https://docs.fedoraproject.org/en-US/project/ -- 真実はいつも一つ！/ Always, there's only one truth!

2 1

[PATCH] s3-mirror: sync s3-sync-path script with ideas from s3.sh
by Pavel Raiskup 29 Mar '20

29 Mar '20

1. sync everything except for repomd.xml 2. then sync repomd.xml files only, and invalidate caches 3. gently wait a bit to give current downloads a chance 4. delete old metadata, shouldn't be needed --- roles/s3-mirror/files/s3-sync-path.sh | 99 ++++++++++++++------------- 1 file changed, 53 insertions(+), 46 deletions(-) diff --git a/roles/s3-mirror/files/s3-sync-path.sh b/roles/s3-mirror/files/s3-sync-path.sh index 79b4d63eb..5a414e3ad 100644 --- a/roles/s3-mirror/files/s3-sync-path.sh +++ b/roles/s3-mirror/files/s3-sync-path.sh @@ -9,58 +9,65 @@ if [[ "$1" == "" ]] || [[ $1 != /pub* ]] || [[ $1 != */ ]]; then exit 1 fi +aws_sync=( aws s3 sync --no-follow-symlinks ) + # first run do not delete anything or copy the repodata. -CMD1="aws s3 sync \ - --exclude */repodata/* \ - --exclude *.snapshot/* \ - --exclude *source/* \ - --exclude *SRPMS/* \ - --exclude *debug/* \ - --exclude *beta/* \ - --exclude *ppc/* \ - --exclude *ppc64/* \ - --exclude *repoview/* \ - --exclude *Fedora/* \ - --exclude *EFI/* \ - --exclude *core/* \ - --exclude *extras/* \ - --exclude *LiveOS/* \ - --exclude *development/rawhide/* \ - --no-follow-symlinks \ - --only-show-errors \ - " - #--dryrun \ +exclude=( + --exclude "*/repodata/*" + --exclude "*.snapshot/*" + --exclude "*source/*" + --exclude "*SRPMS/*" + --exclude "*debug/*" + --exclude "*beta/*" + --exclude "*ppc/*" + --exclude "*ppc64/*" + --exclude "*repoview/*" + --exclude "*Fedora/*" + --exclude "*EFI/*" + --exclude "*core/*" + --exclude "*extras/*" + --exclude "*LiveOS/*" + --exclude "*development/rawhide/*" + --only-show-errors +) -# second we delete old content and also copy the repodata -CMD2="aws s3 sync \ - --delete \ - --exclude *.snapshot/* \ - --exclude *source/* \ - --exclude *SRPMS/* \ - --exclude *debug/* \ - --exclude *beta/* \ - --exclude *ppc/* \ - --exclude *ppc64/* \ - --exclude *repoview/* \ - --exclude *Fedora/* \ - --exclude *EFI/* \ - --exclude *core/* \ - --exclude *extras/* \ - --exclude *LiveOS/* \ - --exclude *development/rawhide/* \ - --no-follow-symlinks \ - --only-show-errors \ - " - #--dryrun \ +S3_MIRROR=s3-mirror-us-west-1-02.fedoraproject.org +DIST_ID=E2KJMDC0QAJDMU +MAX_CACHE_SEC=60 +DNF_GENTLY_TIMEOUT=120 + +# First run this command that syncs, but does not delete. +# It also excludes repomd.xml. +CMD1=( "${aws_sync[@]}" "${excludes[@]}" --exclude "*/repomd.xml" ) + +# Next we run this command which syncs repomd.xml files. Include must precede +# the large set of excludes. Make sure that the 'max-age' isn't too large so +# we know that we can start removing old data ASAP. +CMD2=( "${aws_sync[@]}" --exclude "*" --include "*/repomd.xml" "${excludes[@]}" + --cache-control "max-age=$MAX_CACHE_SEC" ) + +# Then we delete old RPMs and old metadata (but after invalidating caches). +CMD3=( "${aws_sync[@]}" "${excludes[@]}" --delete ) #echo "$CMD /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1" echo "Starting $1 sync at $(date)" >> /var/log/s3-mirror/timestamps -$CMD1 /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1 -$CMD1 /srv$1/repodata/ s3://s3-mirror-us-west-1-02.fedoraproject.org$1/repodata/ +"${CMD1[@]}" "/srv$1" "s3://$S3_MIRROR$1" +"${CMD2[@]}" "/srv$1" "s3://$S3_MIRROR$1" + # Always do the invalidations because they are quick and prevent issues # depending on which path is synced. -for file in $(echo $1/repodata/* ); do - aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU --paths "$file" > /dev/null +for file in $(echo $1/repodata/repomd.xml ); do + aws cloudfront create-invalidation --distribution-id $DIST_ID --paths "$file" > /dev/null done -$CMD2 /srv$1 s3://s3-mirror-us-west-1-02.fedoraproject.org$1 + +SLEEP=$(( MAX_CACHE_SEC + DNF_GENTLY_TIMEOUT )) +echo "Ready $1 sync, giving dnf downloads ${SLEEP}s before delete, at $(date)" >> /var/log/s3-mirror/timestamps + +# Consider some DNF processes started downloading metadata before we invalidated +# caches, and started with outdated repomd.xml file. Give it few more seconds +# so they have chance to download the rest of metadata and RPMs. +sleep $SLEEP + +"${CMD3[@]}" "/srv$1" "s3://$S3_MIRROR$1" + echo "Ending $1 sync at $(date)" >> /var/log/s3-mirror/timestamps -- 2.25.1

3 10

CPE Weekly: 2020-03-28
by Aoife Moloney 28 Mar '20

28 Mar '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-06 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Freeze is over! * New version of pagure (5.9.0) has been released and deployed in staging and on pagure.io * Document being worked on about how to onboard new CI systems in Fedora - this is a work in progress! https://hackmd.io/5gk_kHFhSR6sKa1huPA-4Q ### Request for Review * Fedora magazine: Article proposals about Silverblue rebase to F32 https://pagure.io/fedora-magazine-proposals/issue/59 * Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 ### Data Centre Move * Communishift will be unavailable from 2020-04-13 until 2020-05-08 * Check out our detailed move shedule here https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync=&type= * Covid-19 has seen restrictions added to the data centres we are moving from and to, however we are unaffected as of yet for the move. * If or when our timelines become affected, we will inform you immediately of any outages, downtimes, etc a delay could cause. * Thank you for your understanding at this particularly uncertain and worrying times. ### AAA Replacement * We are nearly complete in our phase one development! * Below are some of the features the team have developed since beginning the project in mid-Jan * UI where people register and login * Add groups function * Change personal details * Enroll OPT * Reset password * View group owner details * Use a search engine * Our next steps in this project is to demo to the team for feedback and then continue to develop CentOS authentication, more user focused features, request for more feedback and test, test test! ### CI/CD * Monitor-gating is now running in production and has already caught a couple of issues with bodhi (both in stg and in prod)! * Rpmautospec * This is in review as a Fedora package: https://bugzilla.redhat.com/show_bug.cgi?id=1816124 * Work progressing on Koji tagging plugin (post-build), full use case support for bumping releases * The team hope to deploy this in staging soon! ### Sustaining Team * Mbbox * Some progress on CRD for koji-builder and koji-hub components has been made this week * Bodhi 5.2.2 released * Some issues with celery tasks & rawhide monitoring has been super useful with this. * Compose Tracker enhancement * Tagging issues have been resolved * Ability to ping maintainers * Fedora Minimal Compose * Odcs-backend-releng01 has been provisioned to enable testing ## CentOS Updates ### CentOS * ppc64le and aarch64, 8 and 8-stream nodes now available in cico for tenants to checkout. -- Email sent to ci-user list * New signing for SIGs (through https://cbs.centos.org) live this week! ### CentOS Stream * Qt5.12 pushed in response to an internal request * NetworkManager re-imported ### Other Updates #### GitForge Decision * After evaluating over 300 user stories from multiple stakeholders we have aligned on a decision for the Gitforge that CPE will operate for the coming years. We are opting for Gitlab for our dist git and project hosting and will continue to run pagure.io with community assistance. * Check out our GitForge decision on the Fedora Community blog https://communityblog.fedoraproject.org/ * And at the CentOS blog page https://blog.centos.org/2020/03/git-forge-decision/ * Keep an eye out for mails in the coming months to the devel lists as we plan transitions and next steps with GitLab * We would like to express our sincere thank you to all who contributed requirements to us! As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

Proposing keeping multiple versions of the same package in the updates repo
by Michel Alexandre Salim 27 Mar '20

27 Mar '20

Hi, We run a diverse fleet of Linux laptops and desktops (at Facebook), and sometimes there are regressions that affect some of our fleet but not others. To pick the latest example: - pulseaudio 1.3.99.1 (both -1 and -2) breaks Bluetooth support on a Dell XPS 15: https://bugzilla.redhat.com/show_bug.cgi?id=1814556 - but it fixes HDA audio input on ThinkPad T490s and X1 Carbon: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c3e19f5098 We've had similar issues with kernel regressions (e.g. 5.4 kernels had issues with Intel GPUs, and on ThinkPads with Nvidia GPUs). (Ideally we catch all this before they land -- over the medium term I'm trying to find a way to encourage our users to help test updates) Would it be possible to keep 2 or 3 versions of the same package in the updates repo, so we can easily keep some of our fleet at a previous version known to work on that particular hardware? And is there a process for proposing this (e.g. file a ticket on Pagure)? Our workaround right now is to check in the older versions in our internal repo. Thanks, -- Michel Alexandre Salim FAS: salimma work email: michel AT fb DOT com

4 8

Pagure for EL8 (EPEL8)
by Neal Gompa 26 Mar '20

26 Mar '20

Hey all, In the interest of helping to modernize the infrastructure Fedora runs on, I'm working on introducing Pagure into EPEL8. This will hopefully allow us to upgrade our Pagure instances to use RHEL 8 instead of RHEL 7, and notably, make the transition (mostly) complete for moving all Python software Fedora runs to Python 3. I've done an early build locally to determine what's needed to make this possible. The following report from DNF indicates the missing packages that need to be added to EPEL 8 before I can introduce Pagure into EPEL8: Problem 1: conflicting requests - nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch Problem 2: conflicting requests - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(binaryornot) needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(flask-wtf) needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(straight.plugin) needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(wtforms) needed by pagure-5.8-1.el8.noarch - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by pagure-5.8-1.el8.noarch Problem 3: conflicting requests - nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch One of the reasons I'd like to have this done sooner rather than later is so that we can drop Python 2 support from Pagure with version 6.0. I think it's quite reasonable to say that version 6.0 isn't going to happen until we can get our Pagure servers running on EL8 using Python 3. So now, I need some help making this happen. I already own trololio, and I'm going to make that available in EPEL 8 ASAP. Can anyone help with some of the other dependencies here? Thanks in advance, Neal -- 真実はいつも一つ！/ Always, there's only one truth!

3 7

[Fedocal] Reminder meeting : Fedora Infrastructure
by smooge＠gmail.com 25 Mar '20

25 Mar '20

Dear all, You are kindly invited to the meeting: Fedora Infrastructure on 2020-03-26 from 15:00:00 to 16:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly Fedora Infrastructure meeting. See infrastructure list for agenda a day before. Source: https://apps.fedoraproject.org/calendar/meeting/9675/

1 0

Bodhi 5.2.0 deployed in production.
by Clement Verna 23 Mar '20

23 Mar '20

Hi all, I have just deployed Bodhi 5.2.0 in production. This version should improve the performance of updates creation since the expansive task of tagging builds in koji has been moved to an async process using a celery workers. Also this version will also allow the use of side-tags to all releases (ie not limited to rawhide anymore). For a more detail view of the changes you can consult the release notes [0]. I would like to thanks everyone that has contributed to this release [1]. Thanks Clément [0] - https://bodhi.fedoraproject.org/docs/user/release_notes.html [1] - https://bodhi.fedoraproject.org/docs/user/release_notes.html#contributors

2 3

[PATCH] s3-mirror: avoid potential unexpected shell-expansion, dedup
by Pavel Raiskup 23 Mar '20

23 Mar '20

Doing this has risk that '*' expands to directories: $> x='echo *' $> $x bin boot dev etc home So it is better to use bash array (we have bash shebang anyways): $> x=( echo '*' ) $> "${x[@]}" * Also de-duplicate few things so it is easier to concentrate on the code. --- roles/s3-mirror/files/s3.sh | 288 +++++++++++++----------------------- 1 file changed, 106 insertions(+), 182 deletions(-) diff --git a/roles/s3-mirror/files/s3.sh b/roles/s3-mirror/files/s3.sh index c70defb52..163e3dc36 100644 --- a/roles/s3-mirror/files/s3.sh +++ b/roles/s3-mirror/files/s3.sh @@ -3,207 +3,131 @@ # LGPL # Author: Rick Elrod <relrod(a)redhat.com> -# first run this command that syncs, but does not delete. +base_cmd=( + aws s3 sync + --no-follow-symlinks + --exclude "*/.snapshot/*" + --exclude "*/source/*" + --exclude "*/SRPMS/*" + --exclude "*/debug/*" + --exclude "*/beta/*" + --exclude "*/ppc/*" + --exclude "*/ppc64/*" + --exclude "*/repoview/*" + --exclude "*/Fedora/*" + --exclude "*/EFI/*" + --exclude "*/core/*" + --exclude "*/extras/*" + --exclude "*/LiveOS/*" + --exclude "*/development/rawhide/*" + --exclude "*/releases/8/*" + --exclude "*/releases/9/*" + --exclude "*/releases/10/*" + --exclude "*/releases/11/*" + --exclude "*/releases/12/*" + --exclude "*/releases/13/*" + --exclude "*/releases/14/*" + --exclude "*/releases/15/*" + --exclude "*/releases/16/*" + --exclude "*/releases/17/*" + --exclude "*/releases/18/*" + --exclude "*/releases/19/*" + --exclude "*/releases/20/*" + --exclude "*/releases/21/*" + --exclude "*/releases/22/*" + --exclude "*/releases/23/*" + --exclude "*/releases/24/*" + --exclude "*/releases/25/*" + --exclude "*/releases/26/*" + --exclude "*/releases/27/*" + --exclude "*/releases/28/*" + --exclude "*/releases/29/*" + --exclude "*/updates/8/*" + --exclude "*/updates/9/*" + --exclude "*/updates/10/*" + --exclude "*/updates/11/*" + --exclude "*/updates/12/*" + --exclude "*/updates/13/*" + --exclude "*/updates/14/*" + --exclude "*/updates/15/*" + --exclude "*/updates/16/*" + --exclude "*/updates/17/*" + --exclude "*/updates/18/*" + --exclude "*/updates/19/*" + --exclude "*/updates/20/*" + --exclude "*/updates/21/*" + --exclude "*/updates/22/*" + --exclude "*/updates/23/*" + --exclude "*/updates/24/*" + --exclude "*/updates/25/*" + --exclude "*/updates/26/*" + --exclude "*/updates/27/*" + --exclude "*/updates/28/*" + --exclude "*/updates/29/*" + --exclude "*/updates/testing/8/*" + --exclude "*/updates/testing/9/*" + --exclude "*/updates/testing/10/*" + --exclude "*/updates/testing/11/*" + --exclude "*/updates/testing/12/*" + --exclude "*/updates/testing/13/*" + --exclude "*/updates/testing/14/*" + --exclude "*/updates/testing/15/*" + --exclude "*/updates/testing/16/*" + --exclude "*/updates/testing/17/*" + --exclude "*/updates/testing/18/*" + --exclude "*/updates/testing/19/*" + --exclude "*/updates/testing/20/*" + --exclude "*/updates/testing/21/*" + --exclude "*/updates/testing/22/*" + --exclude "*/updates/testing/23/*" + --exclude "*/updates/testing/24/*" + --exclude "*/updates/testing/25/*" + --exclude "*/updates/testing/26/*" + --exclude "*/updates/testing/27/*" + --exclude "*/updates/testing/28/*" + --exclude "*/updates/testing/29/*" +) + +# First run this command that syncs, but does not delete. # It also excludes repodata. -CMD1="aws s3 sync \ - --exclude */repodata/* \ - --exclude */.snapshot/* \ - --exclude */source/* \ - --exclude */SRPMS/* \ - --exclude */debug/* \ - --exclude */beta/* \ - --exclude */ppc/* \ - --exclude */ppc64/* \ - --exclude */repoview/* \ - --exclude */Fedora/* \ - --exclude */EFI/* \ - --exclude */core/* \ - --exclude */extras/* \ - --exclude */LiveOS/* \ - --exclude */development/rawhide/* \ - --exclude */releases/8/* \ - --exclude */releases/9/* \ - --exclude */releases/10/* \ - --exclude */releases/11/* \ - --exclude */releases/12/* \ - --exclude */releases/13/* \ - --exclude */releases/14/* \ - --exclude */releases/15/* \ - --exclude */releases/16/* \ - --exclude */releases/17/* \ - --exclude */releases/18/* \ - --exclude */releases/19/* \ - --exclude */releases/20/* \ - --exclude */releases/21/* \ - --exclude */releases/22/* \ - --exclude */releases/23/* \ - --exclude */releases/24/* \ - --exclude */releases/25/* \ - --exclude */releases/26/* \ - --exclude */releases/27/* \ - --exclude */releases/28/* \ - --exclude */releases/29/* \ - --exclude */updates/8/* \ - --exclude */updates/9/* \ - --exclude */updates/10/* \ - --exclude */updates/11/* \ - --exclude */updates/12/* \ - --exclude */updates/13/* \ - --exclude */updates/14/* \ - --exclude */updates/15/* \ - --exclude */updates/16/* \ - --exclude */updates/17/* \ - --exclude */updates/18/* \ - --exclude */updates/19/* \ - --exclude */updates/20/* \ - --exclude */updates/21/* \ - --exclude */updates/22/* \ - --exclude */updates/23/* \ - --exclude */updates/24/* \ - --exclude */updates/25/* \ - --exclude */updates/26/* \ - --exclude */updates/27/* \ - --exclude */updates/28/* \ - --exclude */updates/29/* \ - --exclude */updates/testing/8/* \ - --exclude */updates/testing/9/* \ - --exclude */updates/testing/10/* \ - --exclude */updates/testing/11/* \ - --exclude */updates/testing/12/* \ - --exclude */updates/testing/13/* \ - --exclude */updates/testing/14/* \ - --exclude */updates/testing/15/* \ - --exclude */updates/testing/16/* \ - --exclude */updates/testing/17/* \ - --exclude */updates/testing/18/* \ - --exclude */updates/testing/19/* \ - --exclude */updates/testing/20/* \ - --exclude */updates/testing/21/* \ - --exclude */updates/testing/22/* \ - --exclude */updates/testing/23/* \ - --exclude */updates/testing/24/* \ - --exclude */updates/testing/25/* \ - --exclude */updates/testing/26/* \ - --exclude */updates/testing/27/* \ - --exclude */updates/testing/28/* \ - --exclude */updates/testing/29/* \ - --no-follow-symlinks \ - " - #--dryrun \ +CMD1=( "${base_cmd[@]}" --exclude "*/repodata/*" ) # Next we run this command which also includes repodata. -CMD2="aws s3 sync \ - --exclude */.snapshot/* \ - --exclude */source/* \ - --exclude */SRPMS/* \ - --exclude */debug/* \ - --exclude */beta/* \ - --exclude */ppc/* \ - --exclude */ppc64/* \ - --exclude */repoview/* \ - --exclude */Fedora/* \ - --exclude */EFI/* \ - --exclude */core/* \ - --exclude */extras/* \ - --exclude */LiveOS/* \ - --exclude */development/rawhide/* \ - --exclude */releases/8/* \ - --exclude */releases/9/* \ - --exclude */releases/10/* \ - --exclude */releases/11/* \ - --exclude */releases/12/* \ - --exclude */releases/13/* \ - --exclude */releases/14/* \ - --exclude */releases/15/* \ - --exclude */releases/16/* \ - --exclude */releases/17/* \ - --exclude */releases/18/* \ - --exclude */releases/19/* \ - --exclude */releases/20/* \ - --exclude */releases/21/* \ - --exclude */releases/22/* \ - --exclude */releases/23/* \ - --exclude */releases/24/* \ - --exclude */releases/25/* \ - --exclude */releases/26/* \ - --exclude */releases/27/* \ - --exclude */releases/28/* \ - --exclude */releases/29/* \ - --exclude */updates/8/* \ - --exclude */updates/9/* \ - --exclude */updates/10/* \ - --exclude */updates/11/* \ - --exclude */updates/12/* \ - --exclude */updates/13/* \ - --exclude */updates/14/* \ - --exclude */updates/15/* \ - --exclude */updates/16/* \ - --exclude */updates/17/* \ - --exclude */updates/18/* \ - --exclude */updates/19/* \ - --exclude */updates/20/* \ - --exclude */updates/21/* \ - --exclude */updates/22/* \ - --exclude */updates/23/* \ - --exclude */updates/24/* \ - --exclude */updates/25/* \ - --exclude */updates/26/* \ - --exclude */updates/27/* \ - --exclude */updates/28/* \ - --exclude */updates/29/* \ - --exclude */updates/testing/8/* \ - --exclude */updates/testing/9/* \ - --exclude */updates/testing/10/* \ - --exclude */updates/testing/11/* \ - --exclude */updates/testing/12/* \ - --exclude */updates/testing/13/* \ - --exclude */updates/testing/14/* \ - --exclude */updates/testing/15/* \ - --exclude */updates/testing/16/* \ - --exclude */updates/testing/17/* \ - --exclude */updates/testing/18/* \ - --exclude */updates/testing/19/* \ - --exclude */updates/testing/20/* \ - --exclude */updates/testing/21/* \ - --exclude */updates/testing/22/* \ - --exclude */updates/testing/23/* \ - --exclude */updates/testing/24/* \ - --exclude */updates/testing/25/* \ - --exclude */updates/testing/26/* \ - --exclude */updates/testing/27/* \ - --exclude */updates/testing/28/* \ - --exclude */updates/testing/29/* \ - --no-follow-symlinks \ - " - #--dryrun \ +CMD2=( "${base_cmd[@]}" ) + +# Then we delete old RPMs and old metadata (but after invalidating caches). +CMD3=( "${base_cmd[@]}" --delete ) + +S3_MIRROR=s3-mirror-us-west-1-02.fedoraproject.org +DIST_ID=E2KJMDC0QAJDMU # Sync EPEL -#echo $CMD /srv/pub/epel/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/epel/ +#echo $CMD /srv/pub/epel/ s3://$S3_MIRROR/pub/epel/ echo "Starting EPEL sync at $(date)" >> /var/log/s3-mirror/timestamps -$CMD1 /srv/pub/epel/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/epel/ -$CMD2 /srv/pub/epel/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/epel/ +"${CMD1[@]}" /srv/pub/epel/ "s3://$S3_MIRROR/pub/epel/" +"${CMD2[@]}" /srv/pub/epel/ "s3://$S3_MIRROR/pub/epel/" echo "Ending EPEL sync at $(date)" >> /var/log/s3-mirror/timestamps for file in $(echo /srv/pub/epel/6/*/repodata/repomd.xml | sed 's#/srv##g'); do - aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU --paths "$file" + aws cloudfront create-invalidation --distribution-id "$DIST_ID" --paths "$file" done for file in $(echo /srv/pub/epel/7/*/repodata/repomd.xml | sed 's#/srv##g'); do - aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU --paths "$file" + aws cloudfront create-invalidation --distribution-id "$DIST_ID" --paths "$file" done for file in $(echo /srv/pub/epel/8/*/repodata/repomd.xml | sed 's#/srv##g'); do - aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU --paths "$file" + aws cloudfront create-invalidation --distribution-id "$DIST_ID" --paths "$file" done -$CMD2 --delete /srv/pub/epel/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/epel/ +"${CMD3[@]}" /srv/pub/epel/ "s3://$S3_MIRROR/pub/epel/" # Sync Fedora -#echo $CMD /srv/pub/fedora/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/fedora/ +#echo $CMD /srv/pub/fedora/ s3://$S3_MIRROR/pub/fedora/ echo "Starting Fedora sync at $(date)" >> /var/log/s3-mirror/timestamps -$CMD1 /srv/pub/fedora/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/fedora/ -$CMD2 /srv/pub/fedora/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/fedora/ +"${CMD1[@]}" /srv/pub/fedora/ "s3://$S3_MIRROR/pub/fedora/" +"${CMD2[@]}" /srv/pub/fedora/ "s3://$S3_MIRROR/pub/fedora/" echo "Ending Fedora sync at $(date)" >> /var/log/s3-mirror/timestamps for file in $(echo /srv/pub/fedora/linux/updates/*/*/*/repodata/repomd.xml | sed 's#/srv##g'); do - aws cloudfront create-invalidation --distribution-id E2KJMDC0QAJDMU --paths "$file" + aws cloudfront create-invalidation --distribution-id "$DIST_ID" --paths "$file" done -$CMD2 --delete /srv/pub/fedora/ s3://s3-mirror-us-west-1-02.fedoraproject.org/pub/fedora/ +"${CMD3[@]}" /srv/pub/fedora/ s3://$S3_MIRROR/pub/fedora/ -- 2.25.1

2 5

CPE Weekly: 2020-03-21
by Aoife Moloney 21 Mar '20

21 Mar '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-21 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Fedora 32 Beta is released * Pungi configs created * RC composes ran * Synched to stg * Checksums signed * Pushed to mirrors * F32 flatpack support added * Silverblue is rebased for f32 - article on proposal to Fedora Magazine https://pagure.io/fedora-magazine-proposals/issue/59 ### Issue FYI's & Request for Review * The team are working on resolving the issues in the staging environment for the packager workflow https://pagure.io/releng/issue/9293 * Help with infra-sig packaging appreciated https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&… * Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 ### Data Centre Move * Communishift will be unavailable from 2020-04-13 until 2020-05-08 * Check out our detailed move shedule here https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync=&type= ### AAA Replacement * OTP & 2FA authentication is now working! * Fedora messaging is also integrated in the project * As always, check out our progress on github here https://github.com/orgs/fedora-infra/projects/6 ### CI/CD * The koji plugin which is triggered post git checkout has been written and merged in the rpmautospec project * Working on finishing the rpmautospec logic for release and changelog and use it in the koji post git-checkout plugin and hope to achieve the following * Write the koji plugin to add git tags on dist-git (via pagure) upon successful builds * Package rpmautospec as an RPM * Deploy to stg * Links to the WIP issues in the POC * https://pagure.io/Fedora-Infra/rpmautospec/pull-request/15 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/9 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/5 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/7 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/8 https://pagure.io/Fedora-Infra/rpmautospec/pull-request/13 ### Sustaining Team * Mbbox upgrade work * Project is kicked off https://github.com/fedora-infra/mbbox/projects/1 Vagrant environment for operator-sdk ready Initial operator project ready Work on koji-hub CRD started Work on koji-builder CRD started * RabbitMQ has an outage so a new troubleshooting section has been added to the SOP https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/rabb… ## Docs * Issue created for problems with SELinux documentation in Fedora Quick Fix https://pagure.io/fedora-docs/quick-docs/issue/207 * Build errors updated in the Fedora Defensive Coding Guide https://pagure.io/defensive-coding-guide/issue/7#comment-634123 * F32 release notes being worked on ### Misc Updates/Review Requests * Upgrade pagure and pagure-dist-git on stg * Bugzilla overrides on src.stg landing * Infra-Sig Package Updates * https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c40290717 https://bodhi.fedoraproject.org/updates/FEDORA-2020-2f3ff7bd46 https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c3c3a9e25 https://bodhi.fedoraproject.org/updates/FEDORA-2020-dcb1f11c25 * Jms-messaging-plugin wire support https://github.com/jenkinsci/jms-messaging-plugin/pull/162 * Create 1.0 milestone for Anitya https://github.com/fedora-infra/anitya/milestone/6 * Openh264 Generated the repos Signed the rpms and repodata Sent them to cisco and waiting ## CentOS Updates ### CentOS * Fedora infra images are added to quay.ie for shared library * ppc64le image in testing ### CentOS Stream * Python38 module is running in c8S! * Kernel + VDO has been created for Stream * The team are refactoring the sync2git role and hope to deploy it soon As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

MirrorManager upgraded to 0.13
by Adrian Reber 20 Mar '20

20 Mar '20

I have upgraded MirrorManager in staging to 0.12, saw that the webinterface broke, released 0.13, upgraded staging to 0.13 and after seeing that everything still worked I also upgraded the production instance. It contains a couple of small changes which were already active (EPEL 8 modular repository support) in production, but also a security fix which easily allowed viewing the report_mirror password of all other sites. The biggest change is that I disabled report_mirror for public mirrors. Private mirrors still need to run report_mirror, but for public mirrors the information submitted via report_mirror is ignored. The main reason for dropping report_mirror for public mirrors is that we regularly have seen problems of mirrors being disabled by the crawler because they were out of date and then being re-enabled by report_mirror. The problem was that report_mirror only submits a list of up to date directories without the actual content of the directories (to reduce I/O on the mirrors). Another addition is that MirrorManager can now filter out paths which should be ignored when detecting a version. MirrorManager regularly detected new versions in pub/alt like 25757 or 25748 which were IoT test trees or risc-v trees. So pub/alt is now filtered out when detecting new versions. Please let me know if anything breaks. Adrian

1 0

ODCS prod upgrade tomorrow - 2020-03-20 8:00 UTC
by Jan Kaluza 20 Mar '20

20 Mar '20

Hi, I will be upgrading ODCS prod to new version which is already running on staging. The update will happen tomorrow - 2020-03-20 at 8:00 UTC. ODCS composes submitted around that time might fail. I presume the upgrade should take at max one hour. I will write email here before the upgrade starts and after it ends. I will also try to find out someone with "root" access to assist me in case something goes wrong. If you know you will be available during the Europe's morning tomorrow, please let me know. Regards, Jan Kaluza

1 2

Fedora 32 Beta Freeze now in effect
by Kevin Fenzi 18 Mar '20

18 Mar '20

Greetings. We are now in the infrastructure freeze leading up to the Fedora 32 Beta release. This is a pre release freeze. We do this to ensure that our infrastructure is stable and ready to release the Fedora 32 Beta when it's available. You can see a list of hosts that do not freeze by checking out the ansible repo and running the freezelist script: git clone https://infrastructure.fedoraproject.org/infra/ansible.git ansible/scripts/freezelist -i inventory Any hosts listed as freezes is frozen until 2020-03-17 (or later if release slips). Frozen hosts should have no changes made to them without a sign-off on the change from at least 2 sysadmin-main or rel-eng members, along with (in most cases) a patch of the exact change to be made to this list. Thanks, kevin

1 1

Weekly Backlog Refinement - Week Mar 16 2020
by Clement Verna 18 Mar '20

18 Mar '20

Hi all, Let's look at 5 tickets and rate them using the following categories : * low-trouble, medium-trouble, high-trouble * low-gain, medium-gain, high-gain #6441 Monitoring the worker's queue of pagure - https://pagure.io/fedora-infrastructure/issue/6441 Trouble : ? Gain : ? #6801 run hardlink on fedora-secondary - https://pagure.io/fedora-infrastructure/issue/6801 Trouble : ? Gain : ? #7294 Add GDPR script for release-monitoring.org - https://pagure.io/fedora-infrastructure/issue/7294 Trouble : ? Gain : ? #7377 SSH keys length can prevent user from login in Fedora infrastructure - https://pagure.io/fedora-infrastructure/issue/7377 Trouble : ? Gain : ? #7603 Problem with package-owner-aliases cron script on bastion servers - https://pagure.io/fedora-infrastructure/issue/7603 Trouble : ? Gain : ? Let's use this thread to ask questions and clarifications if needed. Thanks Clément

3 3

[Fedocal] Reminder meeting : Fedora Infrastructure
by smooge＠gmail.com 18 Mar '20

18 Mar '20

Dear all, You are kindly invited to the meeting: Fedora Infrastructure on 2020-03-19 from 15:00:00 to 16:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly Fedora Infrastructure meeting. See infrastructure list for agenda a day before. Source: https://apps.fedoraproject.org/calendar/meeting/9675/

1 0

[PATCH] s3-mirror: fix missing trailing /
by Kevin Fenzi 17 Mar '20

17 Mar '20

This is causing f31 updates to not be synced. The cron job reports: Subject: Cron <s3-mirror@mm-backend01> /usr/local/bin/lock-wrapper s3sync-updates-current "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/31/Everything/x86_64/os" 2>&1 | /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1 Syntax: /usr/local/bin/s3-sync-path.sh /pub/path/to/sync/ NOTE! Path must end with a trailing / Signed-off-by: Kevin Fenzi <kevin(a)scrye.com> --- roles/s3-mirror/tasks/main.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/roles/s3-mirror/tasks/main.yml b/roles/s3-mirror/tasks/main.yml index 5da7a02..395679b 100644 --- a/roles/s3-mirror/tasks/main.yml +++ b/roles/s3-mirror/tasks/main.yml @@ -69,7 +69,7 @@ - name: s3sync cron - updates for current cron: name="s3sync-updates-current" minute="0" hour="3,9,15,21" user="s3-mirror" - job='/usr/local/bin/lock-wrapper s3sync-updates-current "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{ FedoraCycleNumber|int }}/Everything/x86_64/os" 2>&1 | /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1' + job='/usr/local/bin/lock-wrapper s3sync-updates-current "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{ FedoraCycleNumber|int }}/Everything/x86_64/os/" 2>&1 | /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1' cron_file=s3-updates-current.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') tags: -- 1.8.3.1

3 2

[Fedocal, Nuancier] looking for new maintainers
by Francis Gesora 17 Mar '20

17 Mar '20

Hi, I would like to help out with the work for Nuancier. May not be available to take ownership, but willing to assist with the work. Pls advise. -- Regards, Gesora.

2 3

COVID-19 contingency plans for infra and release engineering
by Ben Cotton 16 Mar '20

16 Mar '20

Hi teams, As many of you already know, Red Hat has asked all employees to work from home. I know that many (most?) of you don't work from a Red Hat office normally (particularly if you're not a Red Hat employee!), but I want to check on the impact that an extended shutdown might have on the infrastructure, particularly the release engineering activities as we approach the Fedora 32 GA (currently scheduled for 21 April). In addition, what are our personnel risks? For example, if Mohan gets too sick to work, do we have enough shared knowledge and access to cut a release? Obviously, everyone is going to be impacted in some way, even if none of us get sick. This is a stressful and uncertain time. I've made it clear to Fedora and Red Hat leadership that we will continue with the schedule, but that the priority is the health of our community members. I don't want anyone working beyond what's reasonable for their personal situation. I just need to understand the risks so we can make plans to mitigate them or adjust the release schedule. Thanks, BC -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

3 2

Weekly Backlog Refinement - Week Mar 09 2020
by Clement Verna 16 Mar '20

16 Mar '20

Hi all, This is the first email with trying to better prioritize our backlog of ticket ( https://pagure.io/fedora-infrastructure/issues ). So let's look at 5 tickets and rate them using the following categories : * low-trouble, medium-trouble, high-trouble * low-gain, medium-gain, high-gain #8455 Move mailman to newer release of Fedora or CentOS - https://pagure.io/fedora-infrastructure/issue/8455 Trouble : ? Gain : ? #8167 Adding topic authorization to our RabbitMQ instances - https://pagure.io/fedora-infrastructure/issue/8167 Trouble : ? Gain : ? #8035 A few final ansible secrets for kerneltest - https://pagure.io/fedora-infrastructure/issue/8035 Trouble : ? Gain : ? #7935 Nightlies (Rawhide and Branched) not imported to PDC - https://pagure.io/fedora-infrastructure/issue/7935 Trouble : ? Gain : ? #7919 Fix fas fedmsg sending in openshift - https://pagure.io/fedora-infrastructure/issue/7919 Trouble : ? Gain : ? Let's also use this thread to ask questions and clarifications if needed. Also if you have any ideas or feedback on how to improve that process I am happy to hear about it :-). Thanks Clément

7 8

CPE WEekly: 2020-03-14
by Aoife Moloney 14 Mar '20

14 Mar '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-06 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Fedora 32 Beta work is underway * Fedora Minimal Compose is being worked on with a dedicated ODCS backend running being investigated * Check out the Fedora Council video meeting to find out more about our team here https://www.youtube.com/watch?v=QN8HqBeoozo * Take a look at our (work in progress!) project taiga board to see what we're working on now, next, and still to do! https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null * Have a read of one of our teams article in Fedora magazine: https://fedoramagazine.org/fish-a-friendly-interactive-shell ### Data Centre Move * Communishift will be unavailable from 2020-04-13 until 2020-05-08 * Check out our detailed move shedule here https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA?sync=&type= ### AAA Replacement * OTP & 2FA authentication is now working! * Fedora messaging is also integrated in the project * As always, check out our progress on github here https://github.com/orgs/fedora-infra/projects/6 ### CI/CD * Progress on tagging package history: tests, robustness * Progress on koji plugin to run the rpmautospec * Most work in this repo: https://pagure.io/Fedora-Infra/rpmautospec ### Sustaining Team * Mbbox upgrade work underway with the team looking at operators to deploy and maintain the different services * Infra tickets are starting to be prioritized https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… * Looking at the ansible operator https://github.com/fedora-infra/mbbox/issues/5 * Creating mbbox sustaining project https://github.com/fedora-infra/mbbox/projects/1 * Vagrant OpenShift 3.11 for mbbox https://github.com/fedora-infra/mbbox/pull/1 ## Docs ### Misc Updates/Review Requests * PR Reviews needed for the following: * Vagrant Operator SDK for mbbox review https://github.com/fedora-infra/mbbox/pull/9 * Rebase Silverblue to Fedora 32 - multi monitor setup issue https://bugzilla.redhat.com/show_bug.cgi?id=1810070 * Fedora magazine: Article proposals about Silverblue rebase to F32 https://pagure.io/fedora-magazine-proposals/issue/60 https://pagure.io/fedora-magazine-proposals/issue/59 * Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 * Jms-messaging-plugin reviews https://github.com/jenkinsci/jms-messaging-plugin/pull/162 * Misc Updates: * Helped firefox maintainer sort out koji auth * Gathered logs for qgis maintainer to debug why builds hang * Checked over rawhide compose after open-h264 repo was enabled by default to make sure no content from it got in. * PR sent to fix f32 media with rawhide kickstarts * Migrated fedora-comps to weblate. * Upgraded koji to 1.20.1 via freeze break * PR's Created this week: * Bodhi 5.2 PR reviews https://github.com/fedora-infra/bodhi/pull/3945 https://github.com/fedora-infra/bodhi/pull/3940 https://github.com/fedora-infra/bodhi/pull/3933 https://github.com/fedora-infra/bodhi/pull/3931 https://github.com/fedora-infra/bodhi/pull/3910 https://github.com/fedora-infra/bodhi/pull/3903 https://github.com/fedora-infra/bodhi/pull/3798 * Infra tickets https://pagure.io/fedora-infrastructure/issue/8684 https://pagure.io/Fedora-Infra/review_stats/issue/2 * Fedmsg-koji-plugin https://pagure.io/koji-fedmsg-plugin/pull-request/12 https://pagure.io/koji-fedmsg-plugin/pull-request/13 * Fedora-messaging https://github.com/fedora-infra/fedora-messaging/pull/163 ## CentOS Updates ### CentOS * CentOS CI uptime is 100% * Kickstarter for CentOS 8 arch ppc64le * Check out the mail thread about dealing with unshipped -devel packages for CentOS Linux & Stream too https://lists.centos.org/pipermail/centos-devel/2020-March/036644.html ### CentOS Stream * Python38 module is running in c8S! * More work being done on the contributor workflow too with help from the Packit Team As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

Freeze Break Request
by Mohan Boddu 13 Mar '20

13 Mar '20

Hi, I need to install compose-utils on bodhi-backend01.phx2.fp.o to use compose-partial-copy which will rsync the compose to the /pub/. +1's please. Thanks.

3 2

[kevin@scrye.com: NOTICE: Upcoming extended downtime for Fedora Project Communishift]
by Kevin Fenzi 13 Mar '20

13 Mar '20

Just forwarding on this to the infrastructure list too in case anyone else needs to know. Spread the word. :) kevin -- ----- Forwarded message from Kevin Fenzi <kevin(a)scrye.com> ----- Date: Fri, 13 Mar 2020 12:55:36 -0700 From: Kevin Fenzi <kevin(a)scrye.com> To: communishift-members(a)fedoraproject.org Cc: kevin(a)scrye.com Subject: NOTICE: Upcoming extended downtime for Fedora Project Communishift Greetings, You are receiving this email because you are in the Fedora Project Communishift system group that tracks users who have been granted provisioning ability in Communishift. We would like to notify you of some upcoming extended downtime for the communishift cluster. As some of you may know, later this year the Fedora Project is moving entirely out of our main datacenter in Phoenix, AZ, USA (where the communishift cluster is currently located). We explored various options to migrate the cluster to minimize downtime, but we just don't have extra hardware or resources to setup a duplicate cluster anywhere currently. So, unfortunately, that means we will need to power off the cluster, ship it to a new datacenter and bring it back up there. The estimated timeline for this looks like: 2020-04-13 - power off, derack, pack and ship 2020-04-20 - Arrival at new DC (or before) 2020-04-23 - Unpack, re-rack, cable, network 2020-04-30 - Reconfigure/reinstall 2020-05-08 - fully back in service Note that these dates are subject to shipping and availability of people to rack and setup and other items beyond our control. We will update the following ticket with progress/status: https://pagure.io/fedora-infrastructure/issue//8748 To be ready for this outage, we recommend you back up all your application configuration and data. Due to network changes we may have to reinstall the cluster and thus you may need to reload your applications/data. You can find information on this at: https://docs.openshift.com/dedicated/3/admin_guide/assembly_backing-up-rest… Please let us know if there is anything we can do to assist you during this move or if you have any questions for us. kevin ----- End forwarded message -----

1 0

Freeze break request: rabbitmq-cluster-adjustments
by Kevin Fenzi 13 Mar '20

13 Mar '20

I'd apply this later tonight when things were not very busy, or early tomorrow morning. (given +1s)

5 6

Freeze Break Request: Make aarch64 workstation image non-failable
by Mohan Boddu 11 Mar '20

11 Mar '20

Hi, The change https://fedoraproject.org/wiki/Changes/ARM_Release_Criteria_Changes asks for making aarch64 workstation image non-failable and armhfp xfce image failable. The patch is available at https://pagure.io/pungi-fedora/pull-request/808/ The recent f32 compose has aarch64 workstation image successfully built, so we should be good with merging this PR. Thanks, Mohan Boddu.

3 2

[Fedocal] Reminder meeting : Fedora Infrastructure
by smooge＠gmail.com 11 Mar '20

11 Mar '20

Dear all, You are kindly invited to the meeting: Fedora Infrastructure on 2020-03-12 from 15:00:00 to 16:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly Fedora Infrastructure meeting. See infrastructure list for agenda a day before. Source: https://apps.fedoraproject.org/calendar/meeting/9675/

1 0

Freeze Break Request: koji 1.20.1
by Kevin Fenzi 10 Mar '20

10 Mar '20

Greetings. There's several smallish issues in our koji: * texlive doesn't build ( https://pagure.io/koji/issue/1119 ) * you can't use the interface to look at newRepo and other tasks made by a sidetag thats since been deleted ( https://pagure.io/koji/issue/1866 ) I'd like to propose upgrading to the 1.20.1 bugfix release that has fixes for both these things. There's no schema changes so we can easily roll back to 1.20.0 if needed. https://pagure.io/koji/roadmap/1.20.1/ has the full list of bugfixes in the release. kevin

3 2

Freeze Break Request: s3-mirror adjustments
by Kevin Fenzi 10 Mar '20

10 Mar '20

First, I noticed we are running the full sync twice right now, at the same time: [root@mm-backend01 cron.d][PROD]# cat /etc/cron.d/s3.sh #Ansible: s3sync 0 0,11 * * * s3-mirror /usr/local/bin/lock-wrapper s3sync /usr/local/bin/s3.sh 2>&1 | /usr/local/bin/nag-once s3.sh 1d 2> &1 #Ansible: s3sync-main 0 0 * * * s3-mirror /usr/local/bin/lock-wrapper s3sync-main /usr/local/bin/s3.sh 2>&1 | /usr/local/bin/nag-once s3.sh 1d 2>&1 Second, the attached patch changes the sync scripts to: * do one sync with no --delete and excluding repodata * do another one with --delete and including repodata * invalidate the repodata I adjusted the cron jobs to handle the repodata invalidate (I think). TODO: only sync when things have changed. +1s? kevin --

5 12

Prioritization of tickets and infra work
by Clement Verna 09 Mar '20

09 Mar '20

Hi all, Last week during our weekly meeting we have discuss trying to better prioritize our work and tickets. In order to do that we are going to try to use a "yummy vs trouble" [1] index and use a prioritization matrix [0] to order our work. Yummy representing the added value or benefit of a task and Trouble representing how much effort it would take to complete the task. Each property being either small, medium or large. Starting this week, I ll send a email with a list of 5 tickets from our backlog [1], asking opinions about each tickets yummy and trouble level. We can use this weekly email to ask questions or provide more context. We will then update these tickets with the outcome of the discussion, in case of strong disagreement we can use our weekly IRC meeting to make decision. This will hopefully help us focus on items that provides a high value to our community and also provide a way for everyone to participate in this prioritization. [0] - https://www.process.st/prioritization-matrix/ [1] - https://pagure.io/fedora-infrastructure/issues?status=Open&tags=backlog

2 2

CPE Weekly: 2020-03-06
by Aoife Moloney 06 Mar '20

06 Mar '20

--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-03-06 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * Fedora Minimal Compose is being worked on currently for F32 beta ### Data Centre Move * Please start to plan for 2-3 week outage of communishift starting 2020-04-12 to allow for the move * Due to the data centre move, we cannot get a new box to run odcs-backend https://pagure.io/fedora-infrastructure/issue/8721 * We are also scoping the work required for 'Minimum Viable Fedora' - here is the link to the mail as a refresher of what to expect, and what not https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… Our move dates are as follows: * Move 1 April 13 to IAD2 (essential hardware) * Move 2 April 13 to RDU-CC (communishift) * Move 3 May 11 to IAD2 (QA equipment) * Move 4 June 1 to IAD2 (anything and everything else) ### AAA Replacement * Sprint 5 will see the team focusing on integration with FASJSON API and 2FA token * We have also decided to postpone testing of the new solution until post data centre move to make sure it is * As always, check out our progress on github here https://github.com/orgs/fedora-infra/projects/6 ### CI/CD * Monitor-Gating: Blocked in staging because F32 isn’t branched off there yet (Koji, Bodhi, PDC, https://pagure.io/releng/issue/9293) * Automatic Release Tags and Changelog: Ongoing Devel-list thread here https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… * The team have moved to Jitsi video conferencing with interested community members (ngompa, clime, mboddu, mhroncok) about the different approaches to automatic release tags. Result: Approach considering existing EVRs most palatable (over <#commits>.<#builds>). * We now have a more official looking repo: https://pagure.io/Fedora-Infra/rpmautospec * The team also created implementation details and roadmap: https://hackmd.io/2iQUWeLdR1uTSJ6WL2JqBA ### Sustaining Team * Old cloud is now officially retired * Bodhi XSS vulnerability patched * The team are also looking to prepare a Bodhi 5.2 release * Fedora Minimal Compose (Use ODCS to trigger test composes) * The team are also scoping the Mbbox upgrade and Task breakdown https://github.com/fedora-infra/mbbox/projects/1 * Support community members helping with Badges outage * The teams has started a conversation about Infra Ticket prioritization https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… ## Docs ### Misc Updates/Review Requests * Initial f32-updates-testing push is fixed https://github.com/fedora-infra/bodhi/issues/3936 * Fixed perms on f32 ostree to finish updates pushes * Anitya tests are fixed https://github.com/fedora-infra/anitya/commit/8fe224dbc6b8071f5c5e6f11abe15… * Failing tests in the-new-hotness being resolved https://github.com/fedora-infra/the-new-hotness/pull/273 * Please review Packit integration in the-new-hotness https://github.com/packit-service/packit/issues/689 * Please review KeepassXC flatpak issue https://pagure.io/flatpak-module-tools/issue/6 * Please review Jms-messaging-plugin reviews https://github.com/jenkinsci/jms-messaging-plugin/pull/162 ## CentOS Updates ### CentOS * Ppc64le kickstarter added for CentOS 8 * This will still need to be tested and added in production * The infrastructure is stable overall though! ### CentOS Stream * We are now working on the sync-to-git process * Tycho module was successfully added to Stream in development! * We are also getting closer to having a contributor workflow model available for later this year - watch this space! * We are also working with upstream to generate reports for Stream too As always, feedback is welcome, and we will continue to look at ways to improve the delivery and readability of this weekly report. Have a great weekend! Aoife Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

1 0

Freeze Break Request: Fix pungi configs of F32 for kickstarts
by Mohan Boddu 06 Mar '20

06 Mar '20

Hi, Current pungi configs are using kickstarts from master branch, instead they should use f32 branch. This should be fixed by: https://pagure.io/pungi-fedora/pull-request/812 Look at the last change which is this FBR is totally about. Thanks, Mohan Boddu.

3 2

Revamping the Release Readiness meeting
by Ben Cotton 05 Mar '20

05 Mar '20

(Posting to many mailing lists for visibility. I apologize if you see this more times than you'd like.) You may have already seen my Community Blog post[1] about changing the Release Readiness meeting process. The meeting has questionable value in the current state, so I want to make it more useful. We'll do this by having teams self-report readiness issues on a dedicated wiki page[2] beginning now. This gives the community time to chip in and help with areas that need help without waiting until days before the release. I invite teams to identify a representative to keep the wiki page up to date. Update it as your status changes and I'll post help requests in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC meeting. The Release Readiness meeting will be shortened to one hour and will review open concerns instead of polling for teams that may or may not be there. We will use the logistics mailing list[5] to discuss issues and make announcements, so I encourage representatives to join this list. [1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/ [2] https://fedoraproject.org/wiki/Release_Readiness [3] https://communityblog.fedoraproject.org/category/program-management/ [4] https://apps.fedoraproject.org/calendar/council/#m9570 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 1

Fwd: Re: [Fedora-legal-list] fedoraproject.org in XML namespace name
by Zdenek Veleba 05 Mar '20

05 Mar '20

Hello, Can somebody from web team take a look at this. Just to clarify, we don't need a web page, we just want to use a fedoraproject.org URL as namespace name and make sure everybody is OK with it. Thank you On 2/27/20 3:59 PM, Tom Callaway wrote: > I would say if the web team is fine with it, that's all the approval > you need. > > Tom > > On Thu, Feb 27, 2020, 8:37 AM Zdenek Veleba <zveleba(a)redhat.com > <mailto:zveleba@redhat.com>> wrote: > > Hello, > > My team would like to open-source our testing tool for Anaconda. > Currently it’s using our custom XML namespace with Red Hat URI. We > think it would be best to change it to fedoraproject.org > <http://fedoraproject.org>. Is there some kind of process for > reserving/registering it for our tool? Or are we free coming up > with some URI like: > "http://fedoraproject.org/anaconda-testing/tool-name/recipe" > <http://fedoraproject.org/anaconda-testing/tool-name/recipe> and > using that as our namespace? > > Thank you. > > -- > > Zdenek Veleba > > Quality Engineer > > Red Hat <https://www.redhat.com> > > Location: RH - Brno - TPB-C - 1C373 > > <https://red.ht/sig> > > _______________________________________________ > legal mailing list -- legal(a)lists.fedoraproject.org > <mailto:legal@lists.fedoraproject.org> > To unsubscribe send an email to > legal-leave(a)lists.fedoraproject.org > <mailto:legal-leave@lists.fedoraproject.org> > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org > -- Zdenek Veleba Quality Engineer Red Hat <https://www.redhat.com> Location: RH - Brno - TPB-C - 1C373 <https://red.ht/sig>

1 0

[PATCH] s3-mirror: Run crons to sync s3 mirror a lot more often
by Kevin Fenzi 05 Mar '20

05 Mar '20

We have been getting complaints from copr users that they are hitting out of date cloudfront cached data when they are doing builds. We are syncing not all that often currently, and sometimes if a updates push or rawhide compose finishes after the sync time it coud be a long while before it picks up on it. So, since most of these jobs finish in 5-10min when there is nothing to sync, just have them all run every 15min or so. If this starts hitting locking too much we can spread them back out once we get a sense of when they are hitting that. Additionally, we should just set them up to only sync when their particular thing has finished. This would make it a lot more sane, but require a redesign/rewrite. Amended to use the old values for test releases. Signed-off-by: Kevin Fenzi <kevin(a)scrye.com> --- roles/s3-mirror/tasks/main.yml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/roles/s3-mirror/tasks/main.yml b/roles/s3-mirror/tasks/main.yml index 12351cb..075785e 100644 --- a/roles/s3-mirror/tasks/main.yml +++ b/roles/s3-mirror/tasks/main.yml @@ -68,7 +68,7 @@ - s3-mirror - name: s3sync cron - updates for current - cron: name="s3sync-updates-current" minute="0" hour="3,9,15,21" user="s3-mirror" + cron: name="s3sync-updates-current" minute="2,17,32,47" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-current "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{ FedoraCycleNumber|int }}/" 2>&1 | /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1' cron_file=s3-updates-current.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -76,7 +76,7 @@ - s3-mirror - name: s3sync cron - updates for development/current+1 x86_64 - cron: name="s3sync-updates-current" minute="0" hour="2,7,10" user="s3-mirror" + cron: name="s3sync-updates-current" minute="3,18,33,48" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-dev-cur-plus-1-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/development/{{ FedoraCycleNumber|int + 1 }}/Everything/x86_64/os/" 2>&1 | /usr/local/bin/nag-once s3-updates-dev-cur-plus-1-x86_64.sh 1d 2>&1' cron_file=s3-updates-dev-cur-plus-1-x86_64.sh disabled={{not FedoraBranched|bool}} @@ -85,7 +85,7 @@ - s3-mirror - name: s3sync cron - updates for development/current+1 aarch64 - cron: name="s3sync-updates-current" minute="0" hour="4,11,18" user="s3-mirror" + cron: name="s3sync-updates-current" minute="4,19,34,49" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-dev-cur-plus-1-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/development/{{ FedoraCycleNumber|int + 1 }}/Everything/aarch64/os/" 2>&1 | /usr/local/bin/nag-once s3-updates-dev-cur-plus-1-aarch64.sh 1d 2>&1' cron_file=s3-updates-dev-cur-plus-1-aarch64.sh disabled={{not FedoraBranched|bool}} @@ -94,7 +94,7 @@ - s3-mirror - name: s3sync cron - updates for current-1 - cron: name="s3sync-updates-previous" minute="30" hour="0,6,12,18" user="s3-mirror" + cron: name="s3sync-updates-previous" minute="5,20,35,50" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-previous "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{ FedoraCycleNumber|int - 1 }}/" 2>&1 | /usr/local/bin/nag-once s3-updates-previous.sh 1d 2>&1' cron_file=s3-updates-previous.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -102,7 +102,7 @@ - s3-mirror - name: s3sync cron - epel 7 x86_64 - cron: name="s3sync-epel7-x86_64" minute="10" hour="2,5,8,11,14,17,20,23" user="s3-mirror" + cron: name="s3sync-epel7-x86_64" minute="6,21,36,51" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel7-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/epel/7/x86_64/" 2>&1 | /usr/local/bin/nag-once s3-epel7-x86_64.sh 1d 2>&1' cron_file=s3-epel7-x86_64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -110,7 +110,7 @@ - s3-mirror - name: s3sync cron - epel 7 aarch64 - cron: name="s3sync-epel7-aarch64" minute="20" hour="4,7,10,13,16,19,22" user="s3-mirror" + cron: name="s3sync-epel7-aarch64" minute="7,22,37,52" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel7-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/epel/7/aarch64/" 2>&1 | /usr/local/bin/nag-once s3-epel7-aarch64.sh 1d 2>&1' cron_file=s3-epel7-aarch64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -118,7 +118,7 @@ - s3-mirror - name: s3sync cron - epel 8 Everything x86_64 - cron: name="s3sync-epel8-everything-x86_64" minute="43" hour="3,6,9,12,15,17,20,23" user="s3-mirror" + cron: name="s3sync-epel8-everything-x86_64" minute="8,23,38,53" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-everything-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Everything/x86_64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-everything-x86_64.sh 1d 2>&1' cron_file=s3-epel8-everything-x86_64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -126,7 +126,7 @@ - s3-mirror - name: s3sync cron - epel 8 Everything aarch64 - cron: name="s3sync-epel8-everything-aarch64" minute="38" hour="4,7,10,13,16,19,22" user="s3-mirror" + cron: name="s3sync-epel8-everything-aarch64" minute="9,24,39,54" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-everything-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Everything/aarch64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-everything-aarch64.sh 1d 2>&1' cron_file=s3-epel8-everything-aarch64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -134,7 +134,7 @@ - s3-mirror - name: s3sync cron - epel 8 Modular x86_64 - cron: name="s3sync-epel8-modular-x86_64" minute="32" hour="3,6,9,12,15,17,20,23" user="s3-mirror" + cron: name="s3sync-epel8-modular-x86_64" minute="10,25,40,55" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-modular-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Modular/x86_64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-modular-x86_64.sh 1d 2>&1' cron_file=s3-epel8-modular-x86_64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -142,7 +142,7 @@ - s3-mirror - name: s3sync cron - epel 8 Modular aarch64 - cron: name="s3sync-epel8-modular-aarch64" minute="27" hour="4,7,10,13,16,19,22" user="s3-mirror" + cron: name="s3sync-epel8-modular-aarch64" minute="11,26,41,56" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-modular-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Modular/aarch64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-modular-aarch64.sh 1d 2>&1' cron_file=s3-epel8-modular-aarch64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') -- 1.8.3.1

3 2

[PATCH] s3-mirror: Run crons to sync s3 mirror a lot more often
by Kevin Fenzi 04 Mar '20

04 Mar '20

We have been getting complaints from copr users that they are hitting out of date cloudfront cached data when they are doing builds. We are syncing not all that often currently, and sometimes if a updates push or rawhide compose finishes after the sync time it coud be a long while before it picks up on it. So, since most of these jobs finish in 5-10min when there is nothing to sync, just have them all run every 15min or so. If this starts hitting locking too much we can spread them back out once we get a sense of when they are hitting that. Additionally, we should just set them up to only sync when their particular thing has finished. This would make it a lot more sane, but require a redesign/rewrite. Signed-off-by: Kevin Fenzi <kevin(a)scrye.com> --- roles/s3-mirror/tasks/main.yml | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/roles/s3-mirror/tasks/main.yml b/roles/s3-mirror/tasks/main.yml index 12351cb..6916d01 100644 --- a/roles/s3-mirror/tasks/main.yml +++ b/roles/s3-mirror/tasks/main.yml @@ -60,7 +60,7 @@ - s3-mirror - name: s3sync cron - test releases - cron: name="s3sync-updates-current" minute="40" hour="5,9,13,19" user="s3-mirror" + cron: name="s3sync-updates-current" minute="1,16,31,46" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-test-releases "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/releases/test/" 2>&1 | /usr/local/bin/nag-once s3-test-releases.sh 1d 2>&1' cron_file=s3-test-releases.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -68,7 +68,7 @@ - s3-mirror - name: s3sync cron - updates for current - cron: name="s3sync-updates-current" minute="0" hour="3,9,15,21" user="s3-mirror" + cron: name="s3sync-updates-current" minute="2,17,32,47" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-current "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{ FedoraCycleNumber|int }}/" 2>&1 | /usr/local/bin/nag-once s3-updates-current.sh 1d 2>&1' cron_file=s3-updates-current.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -76,7 +76,7 @@ - s3-mirror - name: s3sync cron - updates for development/current+1 x86_64 - cron: name="s3sync-updates-current" minute="0" hour="2,7,10" user="s3-mirror" + cron: name="s3sync-updates-current" minute="3,18,33,48" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-dev-cur-plus-1-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/development/{{ FedoraCycleNumber|int + 1 }}/Everything/x86_64/os/" 2>&1 | /usr/local/bin/nag-once s3-updates-dev-cur-plus-1-x86_64.sh 1d 2>&1' cron_file=s3-updates-dev-cur-plus-1-x86_64.sh disabled={{not FedoraBranched|bool}} @@ -85,7 +85,7 @@ - s3-mirror - name: s3sync cron - updates for development/current+1 aarch64 - cron: name="s3sync-updates-current" minute="0" hour="4,11,18" user="s3-mirror" + cron: name="s3sync-updates-current" minute="4,19,34,49" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-dev-cur-plus-1-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/development/{{ FedoraCycleNumber|int + 1 }}/Everything/aarch64/os/" 2>&1 | /usr/local/bin/nag-once s3-updates-dev-cur-plus-1-aarch64.sh 1d 2>&1' cron_file=s3-updates-dev-cur-plus-1-aarch64.sh disabled={{not FedoraBranched|bool}} @@ -94,7 +94,7 @@ - s3-mirror - name: s3sync cron - updates for current-1 - cron: name="s3sync-updates-previous" minute="30" hour="0,6,12,18" user="s3-mirror" + cron: name="s3sync-updates-previous" minute="5,20,35,50" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-updates-previous "/usr/local/bin/s3-sync-path.sh /pub/fedora/linux/updates/{{ FedoraCycleNumber|int - 1 }}/" 2>&1 | /usr/local/bin/nag-once s3-updates-previous.sh 1d 2>&1' cron_file=s3-updates-previous.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -102,7 +102,7 @@ - s3-mirror - name: s3sync cron - epel 7 x86_64 - cron: name="s3sync-epel7-x86_64" minute="10" hour="2,5,8,11,14,17,20,23" user="s3-mirror" + cron: name="s3sync-epel7-x86_64" minute="6,21,36,51" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel7-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/epel/7/x86_64/" 2>&1 | /usr/local/bin/nag-once s3-epel7-x86_64.sh 1d 2>&1' cron_file=s3-epel7-x86_64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -110,7 +110,7 @@ - s3-mirror - name: s3sync cron - epel 7 aarch64 - cron: name="s3sync-epel7-aarch64" minute="20" hour="4,7,10,13,16,19,22" user="s3-mirror" + cron: name="s3sync-epel7-aarch64" minute="7,22,37,52" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel7-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/epel/7/aarch64/" 2>&1 | /usr/local/bin/nag-once s3-epel7-aarch64.sh 1d 2>&1' cron_file=s3-epel7-aarch64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -118,7 +118,7 @@ - s3-mirror - name: s3sync cron - epel 8 Everything x86_64 - cron: name="s3sync-epel8-everything-x86_64" minute="43" hour="3,6,9,12,15,17,20,23" user="s3-mirror" + cron: name="s3sync-epel8-everything-x86_64" minute="8,23,38,53" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-everything-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Everything/x86_64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-everything-x86_64.sh 1d 2>&1' cron_file=s3-epel8-everything-x86_64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -126,7 +126,7 @@ - s3-mirror - name: s3sync cron - epel 8 Everything aarch64 - cron: name="s3sync-epel8-everything-aarch64" minute="38" hour="4,7,10,13,16,19,22" user="s3-mirror" + cron: name="s3sync-epel8-everything-aarch64" minute="9,24,39,54" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-everything-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Everything/aarch64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-everything-aarch64.sh 1d 2>&1' cron_file=s3-epel8-everything-aarch64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -134,7 +134,7 @@ - s3-mirror - name: s3sync cron - epel 8 Modular x86_64 - cron: name="s3sync-epel8-modular-x86_64" minute="32" hour="3,6,9,12,15,17,20,23" user="s3-mirror" + cron: name="s3sync-epel8-modular-x86_64" minute="10,25,40,55" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-modular-x86_64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Modular/x86_64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-modular-x86_64.sh 1d 2>&1' cron_file=s3-epel8-modular-x86_64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') @@ -142,7 +142,7 @@ - s3-mirror - name: s3sync cron - epel 8 Modular aarch64 - cron: name="s3sync-epel8-modular-aarch64" minute="27" hour="4,7,10,13,16,19,22" user="s3-mirror" + cron: name="s3sync-epel8-modular-aarch64" minute="11,26,41,56" user="s3-mirror" job='/usr/local/bin/lock-wrapper s3sync-epel8-modular-aarch64 "/usr/local/bin/s3-sync-path.sh /pub/epel/8/Modular/aarch64/" 2>&1 | /usr/local/bin/nag-once s3-epel8-modular-aarch64.sh 1d 2>&1' cron_file=s3-epel8-modular-aarch64.sh when: env != 'staging' and inventory_hostname.startswith('mm-backend01.') -- 1.8.3.1

2 1

Freeze break request: koji autovacuum_freeze_max_age
by Kevin Fenzi 04 Mar '20

04 Mar '20

Greetings. Last night koji alerted due to slowness. It was not backups or anything, but rather the database hitting the limit I raised in commit c678f73b: -autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum +autovacuum_freeze_max_age = 300000000 # maximum XID age before forced vacuum What this means is basicially: postgres records the xid (transaction id) that can 'see' other transactions in the table rows. However, xid is a 32 bit value, meaning there can only be about 2.1billion transactions before it 'wraps around'. When it does so, all the 'old' XID's need to be gone or it will confuse it. It removes the old xids by marking old transactions as 'frozen' (so any other transaction should see them). So, this value tells the autovacuumer to start processing the table for old xids and frezzing them, so by the time the wrap around happens everything will be set. Unfortunately, it's doing this on the buildroot_listing table, which is: public | buildroot_listing | table | koji | 219 GB | So, the i/o load is heavy and koji is slow to respond to real requests. There's (at least) tree things we could do: 1. Bump the autovacuum_freeze_max_age up to 600million. The 100million bump I did in january gave us about 1.5 months, so if we do 600, we might last until june, when we will be migrating to the new datacenter. 600million is still a long way from 2.1 billion, so it should be fine. At that point I hope to move db-koji01 to a rhel8 instance and much newer postgresql. We could also run the vacuum duing downtime and let it finish. 2. Just let it finish now. Things will be slow, I don't know for how long. Users will complain and it will take longer for people to get things done, but at the end we should be in better shape and there's basically no action we need to take (other than handling complaints) 3. Schedule an outage and take the db offline and run the vacuum. This might be quicker than letting the autovac finish, I am not sure. Thoughts? please +1 the freeze break of the option you thing is best, or feel free to ask more info or suggest other options. kevin

6 11

[Fedocal] Reminder meeting : Fedora Infrastructure
by smooge＠gmail.com 04 Mar '20

04 Mar '20

Dear all, You are kindly invited to the meeting: Fedora Infrastructure on 2020-03-05 from 15:00:00 to 16:00:00 UTC At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Weekly Fedora Infrastructure meeting. See infrastructure list for agenda a day before. Source: https://apps.fedoraproject.org/calendar/meeting/9675/

1 0

POST FBR : Bodhi XSS vulnerability
by Clement Verna 04 Mar '20

04 Mar '20

Hi all, An XSS vulnerability was reported against Bodhi, I have patched the staging and production instances [0][1] until I get the fix upstream and deploy a new release. [0] - https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=9b1336… [1] - https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=1a901a… Thanks

2 1

FBR: Change the retirement date to yesterday in pdc
by Mohan Boddu 03 Mar '20

03 Mar '20

Currently when a package is retired, it sets the eol date to today's date in pdc, but that enables people to revert the git retirement commit until the end of the day and that causes a couple of problems 1. When fedpkg retire is called, it sets the eol date in pdc but when people revert it on the very same day, the eol date is not changed back. 2. Since the eol date is not change back, the package gets blocked in koji and people have to request releng to fix it manually and it causes some confusion. To fix this issue, we decided to change the retirement date to yesterday's date and that disables people to revert the commit. Issues: https://pagure.io/releng/issue/8851 and https://pagure.io/releng/issue/9169 Fix: diff --git a/pdcupdater/handlers/retirement.py b/pdcupdater/handlers/retirement.py index 3ccda5a..1fbf23b 100644 --- a/pdcupdater/handlers/retirement.py +++ b/pdcupdater/handlers/retirement.py @@ -1,5 +1,5 @@ import logging -from datetime import datetime +from datetime import datetime, timedelta import requests import pdcupdater.services @@ -189,9 +189,12 @@ def _is_retired_in_dist_git(namespace, repo, branch, requests_session=None): @pdcupdater.utils.retry(wait_on=requests.exceptions.ConnectionError) def _retire_branch(pdc, branch): """ Internal method for retiring a branch in PDC. """ - today = datetime.utcnow().date() + # To disable immediate git reverts + # Fixes: https://pagure.io/releng/issue/8851 - Better solution required + # Fixes: https://pagure.io/releng/issue/9169 - Not ideal, but works + yesterday = datetime.utcnow().date() - timedelta(days=1) for sla in branch['slas']: sla_eol = datetime.strptime(sla['eol'], '%Y-%m-%d').date() - if sla_eol > today: + if sla_eol > yesterday: pdc['component-branch-slas'][sla['id']]._ \ - += {'eol': str(today)} + += {'eol': str(yesterday)} This will be a hotfix in pdc-backend01.phx2.fp.o where pdc-updater is running. Thanks, Mohan Boddu.

3 2

[minutes] [2020-03-02] Badges Outreachy internship planning
by Justin W. Flory 02 Mar '20

02 Mar '20

Hi all, Badges folks wrapped up our weekly meeting for internship planning. Outreachy applicants will see the official project list for the first time on Thursday, 5 March. NOTE: Future meetings shifted to 15:00 UTC / 10:00 EST on Mondays. Calendar invites available on request via email or ask in #fedora-badges. A summary of the conversation is below, also found in the Google Doc: https://docs.google.com/document/d/1R3VndOLYl9A47s_swC03Tci5LpCb8Via9wghDY3… * Plan for 5 March: applicants arrive * Create new “Join Fedora Badges” page in Badges docs based on existing * page from CommOps docs (register FAS, join IRC/Telegram, introduce on mailing list, etc.) * Unify issue tracking to one place * Discussed Badges Pagure, Tahrir, and forking badgr-server to fedora-infra on GitHub * Decided to fork to fedora-infra GitHub and move “story” issues from Tahrir depending if they are still relevant: https://github.com/fedora-infra/badgr-server * Add fedora-messaging onboarding task from fedora-happiness-packets project last summer to new issue tracker * Chat with upstream about identifying “good first issue” tasks for applicants * Action items: * Justin * Open new “How to contribute” docs page for badges * Follow up with a fedora-infra owner about GitHub permissions * Open fedora-messaging issue on badgr-server fork * Marie: Email Concentric Sky/Badgr team * https://github.com/concentricsky/badgr-server/issues * March 5th interns show up * Open “good first issue” bugs/tasks for new contributors * Can also be docs improvements * All: Triage and review Tahrir stories for migration to fedora-infra/badgr-server: https://github.com/fedora-infra/tahrir/issues?q=is%3Aissue+is%3Aopen+label%… -- Cheers, Justin W. Flory (he/him) justinwflory.com TZ=America/New_York

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure March 2020