infrastructure January 2023

infrastructure@lists.fedoraproject.org

19 participants
20 discussions

planet
by Kevin Fenzi 19 Apr '23

19 Apr '23

Hey folks. I thought I would open a discussion about fedoraplanet and possibly some plans for it. Right now: fedoraplanet.org runs on people02.fedoraproject.org (aka fedorapeople). To add a blog/rss feed you have to login there and edit your .planet file, then scripting pulls all those .planet files and tries to fetch all the feeds and then serves them up at http://fedoraplanet.org. It uses a app called 'venus' to do this. venus is written in very old python2 and very very dead upstream. We run into the following problems with it: * Sometimes it gets stuck and just stops processing until it's killed. * It's serving on a http site, which causes people to ask us to make it https, but that would just change the errors because many feeds it pulls are still http since they were added back before letsencrypt existed. * We have a handy 'website' field in our new account system, but aren't using it at all. * The .planet parsing is poor, any number of things can cause it to break. We have two open tickets on it: - https://pagure.io/fedora-infrastructure/issue/10383 (upgrade to pluto, a ruby based, but maintained thing) - https://pagure.io/fedora-infrastructure/issue/10490 ( planet not served via ssl) Which I am just going to close now. So, I can think of a number of options and would love everyone who has thoughts on it to chime in: 1. Do nothing. Venus "works" and .planet files are cool and retro. 2. Switch to pluto and use account system 'website' fields of contributors. We could likely shove it in openshift and serve it directly from there to avoid fedorapeople entirely. (This would likely break anyone who has multiple feeds in there) 3. Switch to something better/bigger. I would think (although I don't know) that there might be something that would not only aggregate rss feeds for contributors, but perhaps mastodon/twitter/whatever also. 4. Planets are old and tired, just drop the entire thing. People can maintain their own rss lists. 5. Planets are old and tired, just drop the entire thing. But also, get our social media people to maintain contributor / interesting lists. ie, the fedoraproject twitter account could maintain a list of 'fedora contributors' and 'fedora packagers' or whatever. 6. Switch to pluto as in 2, but also setup some curators. Have a 'firehose' of all feeds, but the main fedora planet would be just curated things that are known to be related to fedora and not off topic or unrelated. 6. Get someones (not it!) to take in all the twitter/facebook/mastodon/blog posts/rss feeds and post some kind of curated round up every week or something. 7. Your brilliant idea here! So, thoughts? this is not at all urgent, but we should end up doing something with it sometime. :) kevin

13 44

Pyramid 2.0 update proposal for F38
by Mattia Verga 26 Feb '23

26 Feb '23

As you may have read in the announcement on the devel mailing list, I've started a change proposal about bumping Pyramid to version 2.0 for F38. I cross-announce here because Pyramid and its dependencies are mostly maintained by infra-sig and I don't want to bypass main-admins, but I think it's time to move forward (and I have some projects about using pyramid-openapi3 to provide REST APIs in Bodhi which will need Pyramid 2). I intend to upgrade Pyramid and rebuild dependent packages also updating spec files to latest packaging guidelines and possibly upgrade packages to the latest versions. The list of packages is: * python-pyramid - Maintained by kevin / infra-sig * bodhi-server - Maintained by humaton * python-cornice - Maintained by hguemar / python-packagers-sig * python-pyramid-fas-openid - Maintained by abompard / infra-sig * python-pyramid-mako - Maintained by kevin / infra-sig * python-pyramid-tm - Maintained by kevin / infra-sig * python-pyramid_sawing - Maintained by abompard The dependent packages rebuild is not really needed, but it will ensure that the tests will not fail with Pyramid 2.0. In fact, python-pyramid-mako is the only one which needs an upgrade to be compatible with Pyramid 2.0. I have set up a COPR repository to test the upgrade: https://copr.fedorainfracloud.org/coprs/mattia/Pyramid2/ Let me know if there's any objection to the proposal. Mattia

2 4

rhel9 and /boot | /boot/efi
by Kevin Fenzi 01 Feb '23

01 Feb '23

Greetings everyone. I've been working on migrating things to rhel9 of late. I reinstalled a staging virthost or two and found that while rhel8 would allow /boot and /boot/efi to be on raid, rhel9 does not all this at all. So, what do people do for this? 1. Just put /boot | /boot/efi on a primary partition on one disk and hope that disk doesn't die. 2. Put them on one disk, but have duplicate partitions on the other raid disks and some script that copies the 'primary' copies to the backups when kernels are changed. 3. Something else more clever? Whats best practice here? If 2 is the answer, does anyone have already scripts to do this and tie into dnf for kernel updates? I'd like to get this sorted out before moving any more bare metal hosts over to rhel9 if possible. Thanks, kevin

3 3

Proposed change to rendering of release schedule ics file
by Ben Cotton 30 Jan '23

30 Jan '23

Hi everyone, I want to get feedback before I make a change to how Fedora Linux schedules are generated. As reported in schedule#91[1], the current ics files include very long tasks that aren't particularly useful. I have a plan for how to address that, but first I want to check that it won't impact how people currently use the ics files. If you're using the Fedora Linux schedule ics files, please see the details in the Pagure issue[2]. If this will affect how you or your team use those files, comment in the issue before 13 February. Note that this will not change how the html or json versions are produced. [1] https://pagure.io/fedora-pgm/schedule/issue/91 [2] https://pagure.io/fedora-pgm/schedule/issue/91#comment-838492 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

[Fedocal] Reminder meeting : Websites & Apps Team Meeting
by t0xic0der＠fedoraproject.org 30 Jan '23

30 Jan '23

Dear all, You are kindly invited to the meeting: Websites & Apps Team Meeting on 2023-01-31 from 15:00:00 to 16:00:00 UTC At https://meet.jit.si/fedora-websites-apps-meeting The meeting will be about: Weekly team meeting for the Websites & Apps Team. This is part of the [Websites & Apps Community Revamp Objective](https://fedoraproject.org/wiki/Objectives/Websites_%26_Apps_Comm…. See [past discussion]( https://discussion.fedoraproject.org/t/planning-meeting-for-websites-apps-t…) to learn more about the Websites & Apps Team and how it came together. More information available at: [hackmd.io/Mxm2We3yTqKybLsdohadOA](https://hackmd.io/Mxm2We3yTqKybLsdohadOA?view) Source: https://calendar.fedoraproject.org//meeting/9990/

1 0

Anitya [release-monitoring.org] 1.7.0
by Michal Konecny 26 Jan '23

26 Jan '23

Hi everyone, the new version of Anitya [0] (1.7.0) is deployed on production. The major change in this version is the migration to Bootstrap 5 [1], this means that there is a new design of Anitya. It also helped to unify the page design in Anitya. The reason to move to Bootstrap 5 was the change of dependency management for CSS and javascript packages. Anitya is now using npm [2] for management of those packages and the old version of Bootstrap package was not available on npm anymore. I hope you will like the new design. :-) The full changelog can be found in the release page on GitHub [3]. Michal Mage from release-monitoring.org [0] - https://release-monitoring.org [1] - https://getbootstrap.com/ [2] - https://www.npmjs.com/ [3] - https://github.com/fedora-infra/anitya/releases/tag/1.7.0

1 0

fedora-infrastructure issues
by Reon Beon 23 Jan '23

23 Jan '23

https://pagure.io/fedora-infrastructure/issues If people are interested in working on it.

2 2

[Fedocal] Reminder meeting : Websites & Apps Team Meeting
by t0xic0der＠fedoraproject.org 23 Jan '23

23 Jan '23

Dear all, You are kindly invited to the meeting: Websites & Apps Team Meeting on 2023-01-24 from 15:00:00 to 16:00:00 UTC At https://meet.jit.si/fedora-websites-apps-meeting The meeting will be about: Weekly team meeting for the Websites & Apps Team. This is part of the [Websites & Apps Community Revamp Objective](https://fedoraproject.org/wiki/Objectives/Websites_%26_Apps_Comm…. See [past discussion]( https://discussion.fedoraproject.org/t/planning-meeting-for-websites-apps-t…) to learn more about the Websites & Apps Team and how it came together. More information available at: [hackmd.io/Mxm2We3yTqKybLsdohadOA](https://hackmd.io/Mxm2We3yTqKybLsdohadOA?view) Source: https://calendar.fedoraproject.org//meeting/9990/

1 0

Sysadmin Main Membership
by Jonathan Steffan 21 Jan '23

21 Jan '23

Fedora Infra Team, I was looking into some delays/failures on the main web properties and noticed a couple nodes are likely the cause. Please see https://pagure.io/fedora-infrastructure/issue/11097 for details. I would like to be considered for sysadmin-main again. I've been a long-term contributor, have had access before, and would like to contribute again. Please let me know what the next steps are to make this happen. Thanks for all you do, -- Jonathan Steffan jonathansteffan(a)gmail.com

2 2

Automation of Fedora SCM requests
by Michal Konecny 18 Jan '23

18 Jan '23

Hello everyone, for some time CPE (Community Platform Engineering) team is working on automating Fedora SCM requests [0]. The automation is currently live on staging. You can see the output (closed tickets) in Fedora SCM requests staging repo [1]. The automation is done using a plugin in toddlers [2]. We have a documentation [3] for the new toddler, if you want to know more about it. There is also a ticket [4] tracking this work. We plan to deploy this in production on *10th January 2023*, after that all the Fedora SCM request will be processed automatically and it will ping correct people if the manual intervention is needed. This will not change anything in user workflow, it will just make the job of Fedora Release Engineering Team easier and let them focus on other things. On behalf of CPE Team, Michal [0] - https://pagure.io/releng/fedora-scm-requests [1] - https://stg.pagure.io/releng/fedora-scm-requests [2] - https://pagure.io/fedora-infra/toddlers [3] - https://pagure.io/fedora-infra/toddlers/blob/main/f/docs [4] - https://pagure.io/releng/issue/9274

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure January 2023