infrastructure March 2020

infrastructure@lists.fedoraproject.org

27 participants
43 discussions

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 26 Mar '20

26 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 25 Mar '20

25 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure March 2020