Re: Cleaning infra groups on Pagure and GitHub
On Fri, Sep 01, 2023 at 02:59:12PM +0200, Michal Konecny wrote: > Hi everyone, > > I did a cleaning in Fedora infra groups in both Github (fedora-infra > organization https://github.com/fedora-infra) and Pagure (fedora-infra group > https://pagure.io/group/fedora-infra). I removed the people that were > inactive in the last year. > > I also removed people from infra-sig FAS group > (https://accounts.fedoraproject.org/group/infra-sig/) I only left the same > members as in fedora-infra pagure group (I didn't add any). I thought that > those groups should be synced, but it doesn't seem like they are. Is this > correct? Groups in FAS and pagure aren't automatically synced (unlike with src.fp.o). I had a script back then that would allow to do it (I believe this may the something that CentOS use or used): https://pagure.io/pagure-utility/blob/master/f/sync_fas_group_membership.py It definitely needs a refresh to become useful again though. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: congrats to another new sysadmin-mainer
On Wed, Aug 09, 2023 at 10:15:58AM -0700, Kevin Fenzi wrote: > I'm happy to announce that We have approved a new member in our > sysadmin-main group: > > adamwill - Adam Williamson Finally! Welcome aboard Adam :) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: congrats to our new sysadmin-mainer
On Mon, Jul 24, 2023 at 01:20:42PM -0700, Kevin Fenzi wrote: > I'm happy to announce that We have approved a new member in our > sysadmin-main group: > > darknao - Francois Andrieu > > This is the core group of trusted folks that high level access to most > everything in fedora infrastructure. > > Francois has done of ton of things around Fedora infrastructure. From > helping manage our OpenShift clusters, to revamping how our docs and > websites are built and deployed, to just helping anyone with issues all > around. > > He has proved his dedication, trustworthiness, and ability. Congratulations and welcome aboard! :) Cheers! Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: clean up on aisle pagure.io
On Tue, Apr 25, 2023 at 02:17:34PM -0700, Kevin Fenzi wrote: > Hey folks. > > So, a few weeks back I noticed some spam projects on pagure.io. > So, I cleaned up about 165 of them and deactivated 165 spam users. I took out a few a week or so ago, but not as many, I'm impressed :) > Now, I see there's another pile of them. :( > > So, I started to look at cleaning things up again, but I think we need a > better solution that doesn't involve admins manually cleaning things up. > ;( Additionally, the clean up is not really very scripted and takes a > long time to do. > > So, thoughts on a longer term solution? I can think of a few: > > 1. only allow fedora 'contributors' to make new projects. (ie, people in > at least one non cla/non base ipa group > Pros: > - Would very likely cut off the spam or at least cut it way down. > - Might be easy to implement? (not sure tho!) > Cons: > - Would block legit people who aren't fedora contributors. That might be the easiest as iirc, it's a simple config change (like the one we had before enforcing fpca on src.fp.o). > 2 Some kind of moderation for new projects > Pros: > - Would let non fedora folks make new projects. > - Would likely cut spam > Cons: > - Would require someone to moderate things > - Would requite us to make some kind of moderation code Another con: - will require code change > 3. A script to do all the cleanup so we could do it easier and some kind > of 'bad words' blocklist we could put in place to stop obvious spammers > (most of these are bogus "exam answers" ones) > Pros: > - Will cut down on spam some, but not fully. > Cons: > - Will have to write the script and implement the blocklist > - It's likely spammers will use different words over time and avoid the > block. We had basset in the past and always had in mind to hook pagure into it, but we decommissioned basset before we hooked pagure into it :/ Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: planet
On Fri, Apr 14, 2023 at 07:22:57PM -0300, Pedro Moura wrote: > > > > Yeah, hopefully. It might be possible to reach out to those groups... > > design, security? They have irc rooms, we could try asking there? > > > > Due to time zone differences and the possibility of some users not seeing > my message on IRC, I created a survey with 3 questions to gather data on > the use of subplanets on Fedora Planet. I have sent the survey to the > devel, design, and desktop mailing lists. I did this because some mailing > lists that would represent subplanet groups don't exist or don't have > subscribers. Might be worth sending it to devel-announce, or maybe even announce? They should be low(er) traffic and high(er) attention. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: planet
On Wed, Apr 12, 2023 at 07:44:13PM -, Pedro Moura wrote: > > On Thu, Apr 06, 2023 at 12:22:59PM -0400, Ben Cotton wrote: > > > > One thing to keep in mind is that from time to time people are having > > multiple > > blogs in their .planet.ini. We could check on fedorapeople how often this > > happens, and from there see if we need to keep that feature. > > > > > > Pierre > > Not very often. There are currently 789 users who have added their blogs to > the Fedora Planet directory. However, the last updates to the .planet were as > follows: > > - 12 made last year (mostly in the beginning of the year) > - 20 made in 2021 > - 25 made in 2020 > > The rest were updated prior to 2020, and there have been no updates made by > any user this year. > It's worth noting that some users have more than one blog listed in that file. This is what I was pointing out, sorry if I wasn't clear :) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: planet
On Thu, Apr 06, 2023 at 12:22:59PM -0400, Ben Cotton wrote: > On Wed, Apr 5, 2023 at 6:05 PM Pedro Moura wrote: > > > > Instead of users having to SSH and create a .planet file to add their > > blogs, the idea would be simply add their blogs to Fedora Accounts. The > > fields in Fedora Accounts should be available in FasJSON, and we are using > > this API to create the files for each planet so Pluto can build them. > > That seems like a nice improvement in usability. One thing to keep in mind is that from time to time people are having multiple blogs in their .planet.ini. We could check on fedorapeople how often this happens, and from there see if we need to keep that feature. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rethinking fedora websites deployment
On Thu, Nov 24, 2022 at 07:25:03PM +0100, darknao wrote: > > > On 2022-11-24 18:58, Jan K wrote: > > What is likelyhood of Openshift going down? A would be best > > solution if stable enough. > > > > copperi > > > > Openshift is quite stable. But everything around it may not. Having a > network outage, internal VPN issue, datacenter incident, or just an > openshift migration that goes wrong can still happen. The other aspect is that you would then suddenly have all the worldwide traffic goes to our static website converge onto our openshift cluster instead of hitting the geo-distributed proxies. That will have an impact on the user side: suddenly the websites take longer to reach (openshift is in the US instead of me hitting the nearby proxy) as well as on the bandwidth usage for the openshift cluster itself. So I would not recommend serving these websites from our openshift cluster directly. There is real value in the proxies in the loop. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RHEL9 migration
On Wed, Sep 28, 2022 at 11:35:09AM -0700, Kevin Fenzi wrote: > On Tue, Sep 27, 2022 at 04:04:41PM +0200, Neal Gompa wrote: > > On Tue, Sep 27, 2022 at 3:20 PM Neal Gompa wrote: > > > > > > On Tue, Sep 27, 2022 at 3:01 PM Stephen Smoogen > > > wrote: > > > > > > > > > > > > > > > > On Mon, 26 Sept 2022 at 17:56, Kevin Fenzi wrote: > > > >> > > > >> Here's my thoughts on rhel9 upgrades. > > > >> > > > >> We have 188 RHEL7 or RHEL8 instances (counting both vm's and bare > > > >> hardware). > > > >> > > > >> > > > >> Some will just not move anytime soon: > > > >> > > > > > > > > Is it possible to look at these as 'why does this need fedmsg?' 'what > > > > happens if it doesn't have fedmsg', and 'do we need it?' > > Sure, we can. > > But at this point I think we have already gotten rid of most of the > things we really don't need. So, someone will need to make a compelling > argument for dropping things (at least to me). > > > > > mailman01 is one where maybe not having it on fedmsg wouldn't be earth > > > > shattering > > > > but it also has the bigger problem of all its libraries being FTBFS in > > > > Fedora and > > > > being retired from there. At which point we go with 'do we need to run > > > > mailing lists?' > > Well, until we figure out how to otherwise handle the use cases that > mailing lists handle now? > > For example: all the -sig groups in pagure have mailing lists that get > all the bugs send to it. We would need to find another way to get bug > content to those groups (and still keep it private). > scm-commits is still important IMHO, because its a external record of > changes. If someone messed with git history, that might be the only > record of real changes. > devel/test/a few other lists are still active. They would have to move > to discourse or otherwise have something. > > So, needs a concrete plan. I am not at all in favor of 'turn it off' > without moving all the needs. I took it more as a: do we need to *run* mailing list? More than a: Do we need mailing list? Ie: should we look to host our lists for us? That's a fair question and I can see pros and cons to it, but I'm definitely in the camp of "we need mailing lists" :) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Debugging Datanommer performance issues
On Mon, Aug 15, 2022 at 10:49:50AM -0700, Kevin Fenzi wrote: > On Thu, Aug 11, 2022 at 09:51:06AM +0200, Aurelien Bompard wrote: > > Hey folks! > > > > There's been a report of queries long enough to cause a timeout in > > datagrepper: > > https://github.com/fedora-infra/datagrepper/issues/467 > > I don't think those queries should take so much time, and I'd like to debug > > this performance issue, possibly try a couple new indexes on the tables, > > etc. However, I can't reproduce the issue on staging, probably because the > > datanommer database there is much smaller. > > So I was wondering what is the best course of action. I see the following > > options: > > > > 1. Sync the prod DB to staging. This looks like an obvious first choice, > > but the messages in the staging DB actually come from the staging > > environment and are used by other contributors to check that their service > > is behaving properly on staging. Also, the topic prefix of the messages is > > different on staging and on prod, so syncing the DB with prod messages and > > then adding staging ones may cause a mess. > > I think it might work, but not sure we have anyplace off hand with > enough disk space. We might. I can look more if this is the way we want > to go. > > > 2. Having a second datanommer DB in prod, and syncing them. The problem > > here is of course the disk space required. I don't know if that's even > > possible with the hardware we have. > > It might be possible, but it's not a good way to go I don't think. > > > 3. Something else? > > Perhaps a aws instance? Just restore the db snapshot from prod and then > spin up a small datagrepper instance to talk to it? In the past we've imported the prod DB instance into an aws instance when we needed to play around with it (that's also how ARC investigated the db changes when it looked at datanommer/datagrepper). Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: congrats to our new sysadmin-mainers
On Wed, Aug 03, 2022 at 07:56:29AM -0700, Kevin Fenzi wrote: > I'm happy to announce that We have approved several folks into the > sysadmin-main group: > > nphilipp - Nils Philippsen > zlopez - Michal Konečný > ryanlerch - Ryan Lerch > > This is the core group of trusted folks that high level access to most > everything in fedora infrastructure. > > Nils is a long time contributor who has worked on a bunch of things, > including our ipa sudo/ssh permissions setup. > > Michal has worked on many of our applications and is also serving to > help keep us on plan for planned work over the quarters. > > Ryan has been around for a long time working on many things, including > our revamped status application, FMN, gitlab permissions and more. > > They have both proved their dedication, trustworthiness, and ability. > > Congrats to them all! > > Use your powers for good! :) Congratulations folks! Note: we don't get badges for the parking nor parking places near the entrance, but still pretty cool to have you there! ;-) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Email replies to src.fpo notifications
On Thu, Jul 14, 2022 at 10:53:30AM -0700, Kevin Fenzi wrote: > On Wed, Jul 13, 2022 at 08:13:23PM -, Frank R Dana Jr. wrote: > > Recently, after receiving an email notification regarding a pull request at > > src.fedoraproject.org, I attempted[1] to update the discussion via email > > reply to the notification email. > > > > That attempt was not successful. Moreover, I was only made AWARE that the > > attempt was unsuccessful 24 hours later, when Google's MTA responded with > > an undeliverable notification saying that it couldn't contact the recipient > > email, pag...@pkgs.fedoraproject.org. > > > > If email reply to src.fpo notifications is supposed to be working, it's > > not. If it's INTENDED not to be working, then perhaps the reply address > > for notifications could be set to something that bounces immediately > > (donotre...@fedoraproject.org or similar, perhaps?), rather than an address > > at a non-responsive hostname that's subject to lengthy timeouts before the > > status of the attempted reply is updated? > > So, I am not sure what was intended long ago, but to my understanding > it's never worked, nor was it setup to work. While we have it working for pagure.io it does not work (and never has) for src.fedoraproject.org (the notification does not invite you to reply unlike on pagure.io). I'm +1 on keeping it not working Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Software Bill of Materials for Fedora
On Mon, Jul 11, 2022 at 12:53:57PM +1000, Jason Shepherd wrote: > Hello Fedora Infrastructure team, > > Red Hat Product Security are building an application called Component > Registry to meet the requirements set out in the recent Executive Order > 14028 [1], "Improving the Nation's Cybersecurity". The executive order > requires that software producers and suppliers should take steps to report > and validate a listing of all components included in or used by their > software products, aka a Software Bill of Materials. We'd like to build our > application in the open by providing the source code to the > opensource community. > > Since all the Red Hat build infrastructure is internal to Red Hat, we'd > like also provide this service to Fedora so that our open source project > can have a life outside of Red Hat's corporate firewall. I suspect we are > close to being able to provide an example of the Software Bill of Materials > (SBOM) for Fedora, since it is built in a very similar way to Red Hat > Enterprise Linux. The reason for reaching out is to find out if you are > interested in hosting an SBOM for Fedora or not. We could build it inside > the Red Hat firewall, and provide a static file for each target release of > Fedora, undated periodically. Alternatively we could run the application > somewhere on your infrastructure in order to make the data available via an > API on demand. In which case we'd probably need to help to maintain that > infrastructure. This sounds really interesting, thanks for reaching out! Do you know what kind of requirements your application has currently? Can it easily be run on openshift? Which approach would you prefer? Is there an interest in hosting a "live" instance in the Fedora Infrastructure, beside having an API instead of static files? (Are the static files JSON files or HTML btw?) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openshift 3->4 moves status and info needed
On Fri, Jun 17, 2022 at 12:25:08PM +0200, Vít Ondruch wrote: > > Dne 15. 06. 22 v 1:49 Kevin Fenzi napsal(a): > > Greetings everyone. > > > > I finally had a quiet afternoon to really dig into the ocp3->4 > > migration. > > > > We have a total of 64 unique applications/projects over the 4 clusters > > (ocp3 prod/stg and ocp4 prod/stg). > > > > Of those 20 have been moved to ocp4 (either stg or prod or both). > > > > There's 4 that are sort of in the midst of moving to ocp4 prod, but need > > some more tweaking (flatpak-indexer, release-monitoring, > > discourse2fedmsg, transtats). > > > > I'd like to propose removing the following 9 entirely: > > REMOVE: simple-koji-ci.yml > >( This was retired a long time ago) > > > Does it mean that simple-koji-ci will be decommissioned soon? That is sad > news. It has not been running for quite a while now. There is an equivalent service provided by the fedora-ci folks, so you shouldn't have seen it in any PR for a long time. Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: on rpms
On Tue, May 24, 2022 at 06:24:10PM +0200, Aurelien Bompard wrote: > > Something like: > >> > >> Applications in Fedora Infrastructure may be deployed via non rpm > >> methods (as long as they obey licensing guidelines ( > >> https://fedoraproject.org/wiki/Infrastructure_Licensing )). For those > >> applications, creating and maintaining an rpm is optional. > >> > >> > > How about: > > > > Applications in Fedora Infrastructure need to be deployed in an auditable > > and repeatable way. These methods need to allow someone to determine which > > software was installed, when it was installed, and what it was meant to be > > done (example: rpms or podman build scripts for containers). The goal is to > > be kind to our future selves at 2 am who need to figure out why a critical > > application is broken and how to rebuild and redeploy as needed. > > > > Yeah that seems sensible (although I'm not sure of the wording of "what it > was meant to be done", but I think I get it). > This would satisfy apps built with s2i as long as they are pinning their > dependencies with something like poetry or pipenv. We are currently > standardizing on poetry but any would do as long as deps are pinned). > > For s2i based apps, I see two ways of ensuring repeatability, one being > stricter but more transparent than the other: > 1. have the buildconfig track a production branch upstream, and rely on the > build log to know which exact commit was built > 2. have the buildconfig specify the commit hash, and change the buildconfig > each time we want to deploy a new prod version A third option which we've used in a few of our apps is to have a specific branch (or branches) for our deployment. That branch can then have commits dedicated to our deployment, such as support for s2i which aren't needed in the 'main' branch. We could do things like the version pining in that branch as well, making it easy/easier for people to package the application while still helping us ensure the reproducibility we want in openshift. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FBR: update mirror ip addresses for kernel.org
On Tue, Mar 22, 2022 at 02:34:57PM +, Mark O'Brien wrote: > Hi All, > > We have had a request from the people at mirrors.kernel.org to update their > IP address: https://pagure.io/fedora-infrastructure/issue/10598 > > This PR should take care of it > https://pagure.io/fedora-infra/ansible/pull-request/1010 > > I would also need to run the download playbook to apply the change. > > Let the +1/-1's flow please. +1 for me as well Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Freeze Break Request
On Mon, Mar 14, 2022 at 02:18:09PM +, Mark O'Brien wrote: > Hi All, > > There are a few of our proxies in AWS that are giving us errors which I > believe are related to low memory. I would like to reinstall a few of > these. I would do one at a time so disruption should be minimal. There is a > few benefits. > > 1. Increase server resources to allow for a bigger load > 2. Stop using instances with ephemeral storage to avoid a need for a > reinstall in future > 3. Assign Elastic IPs to allow for zero downtime replacement in future > > Let me know what you think and add +1/-1 as you see fit. +1 for me as well Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Sysadmin - main group
On Mon, Nov 29, 2021 at 12:36:15PM +, Mark O'Brien wrote: > I'm happy to announce that We have added a new member to the > sysadmin-main group: > > Saffronique - David Kirwan > > This is the core group of trusted folks that have high level access to > almost everything in fedora infrastructure. > > David has been working on Fedora infra for about a year now and > has been involved in some fairly big pieces of work including adding > an aarch64 cluster to osbs as well as bringing up the new ocp4 > cluster in Fedora. > > He has proved trustworthiness, and ability and I'd like to be the first > to wish him congratulations Congratulations David! We'll let you the secret hand check later on ;-) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: sourcegraph and src.fedoraproject.org
On Wed, Nov 24, 2021 at 07:10:31PM -0500, Matthew Miller wrote: > Sourcegraph is planning to, very shortly, start cloning all non fork repos > from src.fedoraproject.org as well as asking the Pagure API for the metadata > of those repos. Their user agent for API requests is `Sourcegraph-Bot` and > for git protocol stuff `git/Sourcegraph-Bot`. > > If there's a problem, let me know and I'll let them know. :) Maybe they could pre-seed their script with: https://src.fedoraproject.org/lookaside/git-seed-latest.tar.xz That way instead of pulling all the data for all the git repos, they will just pull the changes since the last run of the cron (which runs daily). Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [FBR] Update pagure to 5.13.3
On Mon, Nov 01, 2021 at 11:07:26AM -0400, Neal Gompa wrote: > On Mon, Nov 1, 2021 at 11:06 AM Pierre-Yves Chibon > wrote: > > > > Good Morning Everyone, > > > > This morning, I have cut a new release of pagure: 5.13.3 with the following > > changelog: > > - Warn users when a PR contains some characters > > - srcfpo theme: Change "Packages" link to new packages website (Brendan > > Early) > > - srcfpo theme: left-align the lines in description (Zbigniew > > Jędrzejewski-Szmek) > > - fas user url updated for new accounts system (Mark O Brien) > > - Change fas link from admin.fp.o to accounts.fp.o (Lenka Segura) > > - Remove message about 60 day key length (Ken Dreyer) > > - Escape $ to fix Jenkins interpolation warning (#5178) (Anatoli Babenia) > > - Fix another invalid width/height attribute (Anatoli Babenia) > > - Fix missing space before src in
[FBR] Update pagure to 5.13.3
Good Morning Everyone, This morning, I have cut a new release of pagure: 5.13.3 with the following changelog: - Warn users when a PR contains some characters - srcfpo theme: Change "Packages" link to new packages website (Brendan Early) - srcfpo theme: left-align the lines in description (Zbigniew Jędrzejewski-Szmek) - fas user url updated for new accounts system (Mark O Brien) - Change fas link from admin.fp.o to accounts.fp.o (Lenka Segura) - Remove message about 60 day key length (Ken Dreyer) - Escape $ to fix Jenkins interpolation warning (#5178) (Anatoli Babenia) - Fix another invalid width/height attribute (Anatoli Babenia) - Fix missing space before src in
Re: FBR: run batcave playbook for rbac
On Tue, Sep 21, 2021 at 03:08:12PM +0100, Mark O'Brien wrote: > Hi All, > > I am requesting permissions to run the batcave > playbook to update rbac permissions to allow the > sysadmin-analysis group run the logserver playbook > as requested in this ticket: > > https://pagure.io/fedora-infrastructure/issue/10231 > > As always comments/+1's welcome +1 for me Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Freeze Break Request: Blockerbugs Hotfix to Deal With RHBZ Change
On Wed, Sep 15, 2021 at 01:12:07PM -, Kamil Páral wrote: > > For now, I've kept the limit to 20 because I was having trouble getting > > more than 20 > > to work for me. > > For anyone interested - we found out that only logged-in users can receive > more than 20 responses per query. For anonymous queries, the max limit is 20. > I had a bugzilla token configured, that's why I had no troubles raising the > limit to 100, while it didn't work for Tim because he didn't have any token. Fun one! Thanks for the info, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Freeze Break Request: Blockerbugs Hotfix to Deal With RHBZ Change
On Mon, Sep 13, 2021 at 12:49:21PM -0600, Tim Flink wrote:
> It turns out that the configuration for rhbz was changed without an
> announcement and now the max number of bugs returned for any query is 20.
> Some of the queries that we use in blockerbugs return more than 20 bugs so I
> have a hotfix to deal with the new pagination requirements. I've attached the
> patch to this email.
>
> I'd like to apply this patch to production. Unfortunately, we're in the
> middle of a non-trivial rewrite that's currently on stg so testing the patch
> isn't really an option and that code isn't ready for production use right now.
>
> Thanks,
>
> Tim
> diff --git a/blockerbugs/util/bz_interface.py
> b/blockerbugs/util/bz_interface.py
> index 471140f..a9f90d7 100644
> --- a/blockerbugs/util/bz_interface.py
> +++ b/blockerbugs/util/bz_interface.py
> @@ -29,11 +29,14 @@ from xmlrpc.client import Fault
>
> from blockerbugs import app
>
> +# rhbz has been updated to have a max of 20 results returned
> +BUGZILLA_QUERY_LIMIT = 20
If I understood correctly, you can request more than 20 results, but if you
don't specify how many you want, you'll only get 20.
I believe if you set it to 0 you may get everything, but this needs to be
confirmed empirically.
Anyway, I would check first if you can't retrieve 100 or 200 results in one go
instead of doing iterations of 20 ;-)
> base_query = {'o1': 'anywords',
>'f1': 'blocked',
>'query_format': 'advanced',
> - 'extra_fields': ['flags']}
> -
> + 'extra_fields': ['flags'],
> + 'limit': BUGZILLA_QUERY_LIMIT}
>
> class BZInterfaceError(Exception):
> """A custom wrapper for XMLRPC errors from Bugzilla"""
> @@ -77,7 +80,8 @@ class BlockerBugs():
> #
> https://bugzilla.stage.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED
> #
> _status=POST_status=MODIFIED=Fedora=anaconda=component
> #
> =changedafter=Fedora_format=advanced=2013-03-21%2012%3A25=19
> -def get_bz_query(self, tracker: int, last_update: datetime.datetime =
> None) -> dict[str, Any]:
> +def get_bz_query(self, tracker: int, last_update: datetime.datetime =
> None, offset: int = 0
> + ) -> dict[str, Any]:
If you can set the limit to 0 to retrieve everything, you may want to default to
None rather than 0.
> """Build a Bugzilla query to retrieve all necessary info about all
> bugs which block the
> `tracker` bug.
>
> @@ -129,6 +133,9 @@ class BlockerBugs():
> 'f10': 'CP'
> })
>
> +if offset > 0:
And if you default to None, this will need to be tweaked.
> +query.update({'offset': offset})
> +
> return query
>
> def query_tracker(self, tracker: int, last_update:
> Optional[datetime.datetime] = None
> @@ -139,8 +146,21 @@ class BlockerBugs():
> :param last_update: If provided, the query is modified to ask only
> about bugs which have
> recent modifications; otherwise asks about all
> bugs.
> """
> -query = self.get_bz_query(tracker, last_update)
> -buglist = self.bz.query(query)
> +
> +buglist = []
> +last_query_len = BUGZILLA_QUERY_LIMIT
> +
> +
> +# this is a hotfix hack to work around the sudden config change in
> rhbz where the max
> +# number of bugs returned for a query is 20
> +# it seems to be working for now but may need more work going forward
> +while last_query_len == BUGZILLA_QUERY_LIMIT:
> +
> +new_query = self.get_bz_query(tracker, last_update,
> offset=len(buglist))
> +new_buglist = self.bz.query(new_query)
> +buglist.extend(new_buglist)
> +last_query_len = len(new_buglist)
> +
Looks alright to me otherwise.
Pierre
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Freeze Break Request: more ipsilon/sssd debugging
On Mon, Sep 13, 2021 at 01:44:45PM -0400, Stephen John Smoogen wrote: > On Mon, 13 Sept 2021 at 13:34, Kevin Fenzi wrote: > > > > So, it turns out the additional debugging we setup in that sssd package > > on the ipsilon servers isn't sufficent to show what the problem is. ;( > > > > sssd developers would like us to crank up debugging to try and get logs > > of whats happening. Unfortunately, this will use a ton of disk space, > > which these vm's do not have much of. ;( > > > > I was going to ask to grow the disk on ipsilon02, but I think perhaps > > cleaner would be to create a NFS volume and mount it on /var/log/sssd/ > > on ipsilon02. This way we don't need to actually take the machine down > > and it's really easy to back out. > > > > Yeah either do an NFS or a seperate vmdisk to mount as that and then > blow away when done. > > > So, can I get +1s to: > > > > * make a NFS volume and mount it on /var/log/sssd on ipsilon02 > > * adjust ipsilon02's sssd to enable crazy levels of debug. > > * restart sssd and wait for the next failure. > > * profit! > > > > I would try this and if NFS fails then go with a seperate disk for this. +1 on either. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Freeze Break Request: OSBS docker
On Tue, Sep 07, 2021 at 03:06:45PM -0700, Kevin Fenzi wrote: > Some of you may be aware of: > https://pagure.io/fedora-infrastructure/issue/10145 > > TLDR: some new syscalls in f35+ make docker in our OSBS cluster fail > some new syscalls. This means we have had no new f35/rawhide based OSBS > containers built. > > Note that the base and minimal base are built a different way in > rawhide/branched composes, so we have those, we just don't have any OSBS > builds. Also it's not affecting flatpak's (yet) because those are built > against f34 currently. > > Internally, Red Hat has a docker package that disables seccomp for > docker build. Docker has no option for this without patching. > OpenShift 3.11 (and also thus OSBS) default to seccomp off, but they > can't do that at build time currently. > > So, I would like to: > > * Make sure it's ok for us to use that internal docker build. > (If it's not I guess we get to hack up that seccomp disable patch > ourselves). > * Apply it on our OSBS nodes. > > Our aarch64 nodes are fedora 33, and I don't think they are affected by > this, but I am not sure (if someone seeing this could make sure one way > or another that would be great, I will also ask in the bug). > > Anyhow, can I get +1's to update docker and adjust it's startup unit to > run builds with no seccomp to work around this issue? +1 for me P.Yves signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: IRC nicks in account system, FMN and matrix
On Thu, Jun 24, 2021 at 02:32:05PM +0200, Michal Konecny wrote: > > > On 24. 06. 21 11:51, Aurelien Bompard wrote: > > > > > * Do we want to get noggin to be able to verify nicks first? > > How will the verification works? > > > > > > We don't know yet. I was thinking of having and IRC bot that would get > > an HTTP request from Noggin to verify a user, and would send a link with > > a JWT token as a private message that the user would click on, pretty > > much like what we do for email (except it requires an IRC bot). Of > > course, if we want to support Matrix, we'll need a Matrix bot too to > > verify the nicknames as well. > > That's a pretty decent chunk of work and I don't think it can be done by > > next week. Hopefully sometime in the north hemispherian summer. So if we > > make it a requirement it's going to delay things quite a bit. > I thought we will just validate that the username exists. If we want to > validate it's really the user it will be more difficult. It's basically what FMN does and it works the way Aurélien has described it. I wonder if we could re-use parts of the code there? Or maybe even share the IRC bot? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: account system group deletions
On Mon, Apr 19, 2021 at 11:29:41AM -0700, Kevin Fenzi wrote: > Greetings. > > I thought I would bring up for dicussion here something thats come up > after the new account system has been put in place. > > Namely, how do we handle group deletions. > In the FAS2 world, we never deleted anything. I think this was partly > due to an over abundence of caution (there could be files owned by the > group left over on various machines) and partly just because it was > easier. > > We now have 5 requests to remove various no longer used groups. > > I've enabled audit logging on our ipa01 instance, so we have audit logs > (and I intend to back them up and keep them forever). So we can tell > when a group was deleted by whom. We also have a db dump from fas2 > before the switchover where we can look at who was in what group or what > created it. > > So, I would like to propose: > > * we will remove groups on request/ticket from a group manager. > * we will not seek out groups to remove, as them being there doesn't > really hurt anything. > > Thoughts? +1 for me on groups. This does raise the question about user accounts no? We could have a group that is created with the same name as a group that was deleted, and suddenly our auditing trail needs to take into account a time component as group X at time A may be different than group X at time B. I've the feeling that user accounts are a tad more sensitive and thus we may want to keep our current policies, I'm raising the question here nonetheless :) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Redirecting and testing the new fedocal in openshift
On Wed, Apr 07, 2021 at 10:30:25AM +0200, Arnaud wrote: > All of them give me the error. > > I checked in tor browser, and it doesn't do it there. > It must be my firefox configuration (but it is the one I use all the time). > > As it does it only for me it seems (and the ones that use a configuration > close to me), > I give you the error log I get in firefox as information. So we've debugged this on IRC and found out that this was related to the french locale that basically fails to load. I've turned off localization in fedocal for now until someone can figure out how to make it work properly in a container (starting with compiling the .po files so they are usable). We tested in staging and once we found the fix we pushed it in production as well, so things are now working for Arnaud as well as darknao who could also reproduce this. Thanks for your help folks! Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Redirecting and testing the new fedocal in openshift
On Wed, Apr 07, 2021 at 10:09:00AM +0200, Arnaud wrote: > Hello, > > Maybe it is just me, but I am getting: Internal Server Error > if I click on a calendar for: https://calendar.fedoraproject.org/ Could you give a link? All of these work for me: https://calendar.fedoraproject.org/design-FAD/ https://calendar.fedoraproject.org/Elections/ https://calendar.fedoraproject.org/infrastructure/ Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[PATCH] proxies: redirect apps.fp.o/calendar to calendar.fp.o in openshift
Signed-off-by: Pierre-Yves Chibon --- playbooks/include/proxies-redirects.yml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/playbooks/include/proxies-redirects.yml b/playbooks/include/proxies-redirects.yml index 17a536149..49f2bb418 100644 --- a/playbooks/include/proxies-redirects.yml +++ b/playbooks/include/proxies-redirects.yml @@ -111,6 +111,12 @@ regex: /voting target: https://elections.fedoraproject.org/ + - role: httpd/redirectmatch +shortname: calendar +website: apps.fedoraproject.org +regex: /calendar +target: https://calendar.fedoraproject.org/ + - role: httpd/redirectmatch shortname: mailman website: admin.fedoraproject.org -- 2.30.2 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[PATCH] proxies: redirect apps.fp.o/calendar to calendar.fp.o in openshift
Signed-off-by: Pierre-Yves Chibon --- playbooks/include/proxies-redirects.yml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/playbooks/include/proxies-redirects.yml b/playbooks/include/proxies-redirects.yml index 17a536149..4d5223ad5 100644 --- a/playbooks/include/proxies-redirects.yml +++ b/playbooks/include/proxies-redirects.yml @@ -111,6 +111,12 @@ regex: /voting target: https://elections.fedoraproject.org/ + - role: httpd/redirectmatch +shortname: calendar +website: admin.fedoraproject.org +regex: /calendar +target: https://calendar.fedoraproject.org/ + - role: httpd/redirectmatch shortname: mailman website: admin.fedoraproject.org -- 2.30.2 ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Redirecting and testing the new fedocal in openshift
This is both a call for more testing as well as the first FBR of this new freeze. I have deployed fedocal in openshift, using OIDC and fedora-messaging, running on python 3 at: https://calendar.fedoraproject.org I have done some testing and for what I looked at and for everything seems to work (including the sending of the reminder email). If you have a little time, please have a look at it. Do note that this instances uses the prod database so be reasonable, if you want to do more testing feel free to poke at the staging instance at: https://calendar.stg.fedoraproject.org. Unless I hear otherwise, I would like to redirect the current (VM-based) fedocal over to its new location (openshift) using the attached patch. +1? Thanks, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Congrats to Nick Bebout
On Mon, Apr 05, 2021 at 08:47:54AM -0700, Kevin Fenzi wrote: > Greetings. > > I'm happy to announce that Nick Bebout(fas: nb, irc: nb) > has been added to our sysadmin-main group. > > This is the core group of trusted folks that high level access to most > everything in fedora infrastructure. > > Nick has been doing infrastructure tasks for various groups for many > years in sysadmin-noc, sysadmin-web, and too many other groups to list. > > He's proved his dedication, trustworthiness, and ability. > > Congrats! Congrats and welcome aboard ;-) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 34 Beta Freeze is now over
With the successful release of Fedora 34 beta yesterday we are now out of freeze. Our next planned freeze is 2021-04-06 for Fedora 34 final. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planned Outage - Fedora Account System Replacement - 2021-03-25 10:30 UTC
On Mon, Mar 22, 2021 at 01:56:46PM +0100, Pavel Raiskup wrote: > In Copr We use OpenID API in FAS to allow users to log-in, and to gather some > basic info about the user (FAS groups and timezone afair). Will this API work > after the transition? For OpenID, saml or OIDC we rely on ipsilon which is not being directly impacted by this change. It will need to be reconfigured to check LDAP instead of FAS in the backend, but the beauty of these this auth protocol is that the auth applications should not be impacted by this change. Feel free to point at id.stg.fedoraproject.org if you would like to test this. Pierre > On Friday, March 19, 2021 3:23:16 PM CET Mark O'Brien wrote: > > All, > > > > Fedora infrastructure is getting a new accounts system! To put this in > > place we will need an outage to our services. > > > > There will be an outage starting at 2021-03-25 10:30UTC, > > which will last approximately *TWO* days. > > > > To convert UTC to your local time, take a look at > > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > > or run: > > > > date -d '2021-03-25 10:30UTC' > > > > *Affected Services:* > > > > All Fedora Services > > > > > >- As this is the authentication system there may be issues logging in to > >some services. > >- Users may not be able to access people.fedoraproject.org or > >secondary.fedoraproject.org during the outage > >- Maintainer test instances are a special case and as such will be in a > >"frozen" state for access after the outage. This means that no updates > > will > >be made to users or ssh keys on these machines. > > > > > > Ticket: > > > > https://pagure.io/fedora-infrastructure/issue/9747 > > > > If you have any questions or concerns please use any of the following > > methods of communication. > > > >- Comment on the ticket > >- IRC on #fedora-admin or #fedora-noc > >- Reply to this mail > > > > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Congrats to Tomáš Hrčka
On Tue, Mar 16, 2021 at 02:06:16PM -0700, Kevin Fenzi wrote: > Greetings. > > I'm happy to announce that Tomáš Hrčka (fas: humaton, irc: jednorozec) > has been added to our sysadmin-main group. > > This is the core group of trusted folks that high level access to most > everything in fedora infrastructure. > > Tomáš has been doing a great job working on releng tasks as well as > releng apps and scripting and the like. > > He's proved his dedication, trustworthiness, and ability. > > Congrats! > > Use your powers for good! :) Congrats Tomáš! And remember: "with great powers come great electricity bills". Hm, I'm suddenly wondering if this is the right quote... Anyway, congrats again! Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: ssh git access to src.fedoraproject.org feedback
On Wed, Mar 03, 2021 at 07:35:00PM -0500, Neal Gompa wrote: > On Wed, Mar 3, 2021 at 6:12 PM Kevin Fenzi wrote: > > > > On Wed, Mar 03, 2021 at 05:26:46PM -0500, Neal Gompa wrote: > > > On Wed, Mar 3, 2021, 5:13 PM Matthew Miller > > > wrote: > > > > > > > On Wed, Mar 03, 2021 at 01:53:28PM -0800, Kevin Fenzi wrote: > > > > > 4) We could add some kind of GSSAPI/Kerberos support to pagure, so > > > > > people could use https and a kerberos ticket. > > > > > > > > What's amount of effort required for this option? Because other than "it > > > > might be a lot of work", it seems ideal, and would resolve a lot of > > > > other > > > > cases where it's an extra step to have to configure an access token for > > > > pagure. But "it might be a lot of work" is a pretty big con. > > > > > > > > If the answer is "yeah, it's a lot", I vote for whichever other option > > > > makes > > > > this a logical next step when there is time to do such work. > > > > > > > > > > I don't think it would be that hard anymore. Recently, Pagure changed to > > > proxy and handle Git via HTTPS, meaning that we can do whatever we want to > > > authenticate pulls and pushes. > > > > Except this doesn't work currently for src.fedoraproject.org pagure, as > > the OIDC tokens take over. :( > > > > Yeah, we need to fix this somehow. But it shouldn't be too hard, I > think? We already have this setup for pagure.io... No pagure.io doesn't have mod_oidc allowing to push over https using an OIDC token. Moving to mod_gssapi may be the way to do this, however I'm no sure how eaasy/hard it will be to get it to support full pagure user account. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Introducing the ARC sub-team in CPE - and first research topic
On Mon, Jan 18, 2021 at 04:25:09PM +0100, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > While planning work, the CPE team has realized that a number of our > initiatives > actually start with a research phase to find the most appropriate technical > solution. > This leads to some issues with planning as without knowing the technical > solution we want to take, it's hard to evaluate the amount of work needed and > thus the time it'll take to do it. > > In order to help with this, we're creating a small sub-team in CPE, called the > ARC team for Advance Reconaissance Crew*. > The goal of this team will be to investigate what we believe to be the > possible > technical solutions for initiatives and advise the team on what they believe > would be the appropriate solution. > To this end, we will reach out when we start looking for ideas as you may have > ideas that we did not think about. > > The first investigation, led by Will Woods, Mark O'Brien and I, will be around > datanommer and datagrepper. > > datanommer is an application listening to fedmsg and filling a (postgresql) > database with all the messages passing on the bus. > datagrepper is a web application exposing these messages and offering a way to > filter or search them. > available at: https://apps.fedoraproject.org/datagrepper/ > > Currently our ideas are: > - for datanommer: > - port it to fedora-messaging > - adjust it to whichever solution we chose to replace datagrepper > > - for datagrepper: > - keep it as is > - Replace by > - postgres https://postgrest.org/ > - prest https://github.com/prest/prest > - kinto https://docs.kinto-storage.org/en/stable/ > - Swagger/OpenAPI https://swagger.io/ > - Add support for Graphql > > - for the postgresql server > - Split messages per year in different table > - Unite them using a postgresql view > - Kick out the old messages per year > - Keep the current year + n-1 in the current DB > - Kick the other to another DB? > - Kick the other to a tarball somewhere? > - Output the database daily dump to file / year > - TimescaleDB a postgresql plugin for time-series data > - > https://alibaba-cloud.medium.com/postgresql-time-series-database-plug-in-timescaledb-deployment-practices-6a07e246eb0d > - https://dev.t-matix.com/blog/postgresql-as-a-time-series-database/ > - https://docs.timescale.com/latest/introduction > - Make the msg field in the message table be a JSON field > > Would you have any other ideas of things we could look at? Just as a follow up to this thread, our findings can be found at: https://fedora-arc.readthedocs.io/en/latest/datanommer_datagrepper/index.html and I've also presented them in a blog post at: http://blog.pingoured.fr/index.php?post/2021/02/26/datanommer/datagrepper-investigations Hoping this helps, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Introducing the ARC sub-team in CPE - and first research topic
On Mon, Jan 18, 2021 at 05:41:35PM -0800, Kevin Fenzi wrote: > On Mon, Jan 18, 2021 at 04:25:09PM +0100, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > ...snip... > > > Currently our ideas are: > > - for datanommer: > > - port it to fedora-messaging > > - adjust it to whichever solution we chose to replace datagrepper > > > > - for datagrepper: > > - keep it as is > > - Replace by > > - postgres https://postgrest.org/ > > - prest https://github.com/prest/prest > > - kinto https://docs.kinto-storage.org/en/stable/ > > - Swagger/OpenAPI https://swagger.io/ > > Doing any of those means existing queries no longer work right? > Thats kind of a pain. ;( Yes, that will need to be taken into account when a decision is made on which of these solutions to pick. > > - Add support for Graphql > > > > - for the postgresql server > > - Split messages per year in different table > > - Unite them using a postgresql view > > I've long wanted to do this. ;) > > It might be worth making it non default to query more than the most > recent year. Most queries won't need anything that old... > > > - Kick out the old messages per year > > - Keep the current year + n-1 in the current DB > > - Kick the other to another DB? > > - Kick the other to a tarball somewhere? > > I would prefer to keep it queryable... there's some things that may want > to query the entire backhistory. Fair. Again, the idea was to list every ideas here and then we can weight them again each other. > > - Output the database daily dump to file / year > > - TimescaleDB a postgresql plugin for time-series data > > - > > https://alibaba-cloud.medium.com/postgresql-time-series-database-plug-in-timescaledb-deployment-practices-6a07e246eb0d > > - https://dev.t-matix.com/blog/postgresql-as-a-time-series-database/ > > - https://docs.timescale.com/latest/introduction > > - Make the msg field in the message table be a JSON field > > If you do this would you convert all the old messages? Yes > > Would you have any other ideas of things we could look at? > > I'm not sure if there's any compression we could use here, but it would > be nice if the data took up less room. :) Worth looking into as well. > Thanks for looking into this! Hopefully it'll be productive and successful! Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Introducing the ARC sub-team in CPE - and first research topic
On Mon, Jan 18, 2021 at 10:38:42AM -0500, Matthew Miller wrote: > On Mon, Jan 18, 2021 at 04:25:09PM +0100, Pierre-Yves Chibon wrote: > > Would you have any other ideas of things we could look at? > > Perhaps this? https://pagure.io/fedora-infrastructure/issue/9580 That's not an answer I was expecting :D The question was on: are there other ideas of things we could look at for replacing/upgrading/improving datanommer and datagrepper? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Introducing the ARC sub-team in CPE - and first research topic
Good Morning Everyone, While planning work, the CPE team has realized that a number of our initiatives actually start with a research phase to find the most appropriate technical solution. This leads to some issues with planning as without knowing the technical solution we want to take, it's hard to evaluate the amount of work needed and thus the time it'll take to do it. In order to help with this, we're creating a small sub-team in CPE, called the ARC team for Advance Reconaissance Crew*. The goal of this team will be to investigate what we believe to be the possible technical solutions for initiatives and advise the team on what they believe would be the appropriate solution. To this end, we will reach out when we start looking for ideas as you may have ideas that we did not think about. The first investigation, led by Will Woods, Mark O'Brien and I, will be around datanommer and datagrepper. datanommer is an application listening to fedmsg and filling a (postgresql) database with all the messages passing on the bus. datagrepper is a web application exposing these messages and offering a way to filter or search them. available at: https://apps.fedoraproject.org/datagrepper/ Currently our ideas are: - for datanommer: - port it to fedora-messaging - adjust it to whichever solution we chose to replace datagrepper - for datagrepper: - keep it as is - Replace by - postgres https://postgrest.org/ - prest https://github.com/prest/prest - kinto https://docs.kinto-storage.org/en/stable/ - Swagger/OpenAPI https://swagger.io/ - Add support for Graphql - for the postgresql server - Split messages per year in different table - Unite them using a postgresql view - Kick out the old messages per year - Keep the current year + n-1 in the current DB - Kick the other to another DB? - Kick the other to a tarball somewhere? - Output the database daily dump to file / year - TimescaleDB a postgresql plugin for time-series data - https://alibaba-cloud.medium.com/postgresql-time-series-database-plug-in-timescaledb-deployment-practices-6a07e246eb0d - https://dev.t-matix.com/blog/postgresql-as-a-time-series-database/ - https://docs.timescale.com/latest/introduction - Make the msg field in the message table be a JSON field Would you have any other ideas of things we could look at? Looking forward for your input, Thanks, Pierre, Will and Mark * Our notes and documentation are hosted at: https://fedora-arc.readthedocs.io/en/latest/index.html ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Resources for a hosting an alternative Fedora buildroot
On Thu, Jan 14, 2021 at 05:44:56PM -0800, Tom Stellard wrote: > Hi, > > I am considering making a proposal for an alternative buildroot (similar to > ELN) in Fedora, The resource question has already been addressed elsewhere in this thread. What makes me the most curious though is the question: why? What do you have in mind? What would you like to use these resources (that we don't really have) for? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Projects under github.com/fedora-infra
On Thu, Jan 14, 2021 at 01:40:05PM +0100, Pierre-Yves Chibon wrote: > On Wed, Jan 06, 2021 at 01:17:35PM -0800, Kevin Fenzi wrote: > > On Tue, Jan 05, 2021 at 05:09:27PM +0100, Pierre-Yves Chibon wrote: > > > - 85 are "source" repo. > > > > > > Of these I would like to propose that we archive the following 24: > > > - tbs > > > - fpdc > > > - fedora-packages > > > - fedora-search > > > - stickynotes2modernpaste > > > - people2 > > > - pkgwat.api > > > - pkgwat.cli > > > - noggin-old > > > - cpsreport > > > - taiga-contrib-oidc-auth > > > - zanata2fedmsg > > > - rdbsync > > > - fedmsg-notify > > > - fedmsg-health > > > - pkgdb2 > > > - fedmsg-genacls > > > - fedora-stats-tools > > > - fedmsg-java > > > - pagure-hook-receiver > > > - JSAutoLogin > > > - fedmsg-wp > > > - askbot-fedmsg > > > - busmon > > > > +1 > > Considering the feedback, I'm going to go ahead and archive these projects. Here are a few more that I've archived as well: taiga-contrib-fas-openid-auth jenkins-fedmsg-emit (not changed since 2017 and was used when we ran our own jenkins instance) fpdc-client (since we archived pdc) pdc-updater (merged into toddlers) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Projects under github.com/fedora-infra
On Wed, Jan 06, 2021 at 01:17:35PM -0800, Kevin Fenzi wrote: > On Tue, Jan 05, 2021 at 05:09:27PM +0100, Pierre-Yves Chibon wrote: > > - 85 are "source" repo. > > > > Of these I would like to propose that we archive the following 24: > > - tbs > > - fpdc > > - fedora-packages > > - fedora-search > > - stickynotes2modernpaste > > - people2 > > - pkgwat.api > > - pkgwat.cli > > - noggin-old > > - cpsreport > > - taiga-contrib-oidc-auth > > - zanata2fedmsg > > - rdbsync > > - fedmsg-notify > > - fedmsg-health > > - pkgdb2 > > - fedmsg-genacls > > - fedora-stats-tools > > - fedmsg-java > > - pagure-hook-receiver > > - JSAutoLogin > > - fedmsg-wp > > - askbot-fedmsg > > - busmon > > +1 Considering the feedback, I'm going to go ahead and archive these projects. Thanks everyone! Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: New default branch for the ansible repo
On Wed, Jan 13, 2021 at 10:27:36AM +, Mark O'Brien wrote: > > Good Morning Everyone, > > > > Just a quick email to announce that the ansible repo and all the projects > > under > > fedora-infra on pagure.io have changed their default branch from "master" > > to > > "main". > > > > > Is main now set as the default name for all new repos on pagure.io Not at the moment. It is in our backlog/todo with a question mark. Should we do it? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
New default branch for the ansible repo
Good Morning Everyone, Just a quick email to announce that the ansible repo and all the projects under fedora-infra on pagure.io have changed their default branch from "master" to "main". So if you have a local copy, you may want to do something like: git fetch git checkout main git pull --rebase Then things should just work as usual. Happy hacking! Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Projects under github.com/fedora-infra
On Sat, Jan 09, 2021 at 08:26:02PM -0600, Nick Bebout wrote: > I forked ssh-gpg-smartcard-config a while back before I got access to > herlo's repo so I could update it. Now I have commit access to herlo's > repo, so it may be unnecessary to have our fork (although I don't see what > it hurts). I would like to look and see if the fedora-infra repo is linked > to anywhere before we delete it. Thanks, the goal is simply to have a better overview of what we currently maintain. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Projects under github.com/fedora-infra
On Thu, Jan 07, 2021 at 09:29:04AM +0100, Pierre-Yves Chibon wrote: > On Wed, Jan 06, 2021 at 01:17:35PM -0800, Kevin Fenzi wrote: > > On Tue, Jan 05, 2021 at 05:09:27PM +0100, Pierre-Yves Chibon wrote: > > > We have 134 projects there: > > > - 45 of them are archived > > > - 1 is a mirror > > > - people2 > > > - 4 are forks: https://github.com/fedora-infra?type=fork > > > - ssh-gpg-smartcard-config > > > - Last commit on November 2020 > > > - Seems up to date with its parent project > > > > I think someone forked this to add some yubikey info? > > But in any case I don't think we need it now. > > > > > - pyramid_fas_openid > > >- master branch > > > - last commits October 2020 (previous ones 2017) > > > - 40 commits ahead of master in its parent project > > >- develop branch > > > - last commits 2015 > > > - 26 commits ahead of master in its parent project > > > > Alas, we still use this for bodhi I am pretty sure. > > At least bodhi-backend01 has: > > python3-pyramid-fas-openid-0.4.0-1.fc32.noarch > > installed. > > Do we know if the package's sources come from our fork? dnf info shows our fork as URL so I guess that answers it :) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Projects under github.com/fedora-infra
On Wed, Jan 06, 2021 at 01:17:35PM -0800, Kevin Fenzi wrote: > On Tue, Jan 05, 2021 at 05:09:27PM +0100, Pierre-Yves Chibon wrote: > > We have 134 projects there: > > - 45 of them are archived > > - 1 is a mirror > > - people2 > > - 4 are forks: https://github.com/fedora-infra?type=fork > > - ssh-gpg-smartcard-config > > - Last commit on November 2020 > > - Seems up to date with its parent project > > I think someone forked this to add some yubikey info? > But in any case I don't think we need it now. > > > - pyramid_fas_openid > >- master branch > > - last commits October 2020 (previous ones 2017) > > - 40 commits ahead of master in its parent project > >- develop branch > > - last commits 2015 > > - 26 commits ahead of master in its parent project > > Alas, we still use this for bodhi I am pretty sure. > At least bodhi-backend01 has: > python3-pyramid-fas-openid-0.4.0-1.fc32.noarch > installed. Do we know if the package's sources come from our fork? > > Then we have a these four that we run but do not maintain and that may want > > to > > find a better place: > > - asknot-ng > > - fedbages > > - tahrir > > - tahrir-api > > Yep. Lets see is OSPO wants them somewhere... > > > This would reduce the number of projects down to 57 projects most of which > > are > > run and maintained by Fedora Infrastructure. > > Still a lot. ;) yup, though the split of the message schemas to different repo kind of "artificially" increases that number (ie: maintaining 1 code-base, results in two projects on github). Let's see how are things once we've cleaned them up a little more :) > > Then, I am also wondering if we should move the archived projects to another > > organisation just to keep the list of projects somewhat manageable. > > We could. Github does filter the archived ones out some, so I don't know > if it's worth the trouble, but if you think it's worth it we can. Agreed, however archived projects are shown by default, if we find a way to hide archived project by default I think that would be sufficient. Basically, I'm looking for a way that it shows 57 or so projects by default rather than 134. Hoping it makes sense :) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Projects under github.com/fedora-infra
Good Morning Everyone, I've been looking at all the projects we have under the fedora-infra org on github.com. We have 134 projects there: - 45 of them are archived - 1 is a mirror - people2 - 4 are forks: https://github.com/fedora-infra?type=fork - ssh-gpg-smartcard-config - Last commit on November 2020 - Seems up to date with its parent project - pyramid_fas_openid - master branch - last commits October 2020 (previous ones 2017) - 40 commits ahead of master in its parent project - develop branch - last commits 2015 - 26 commits ahead of master in its parent project - badgr-server - last commit March 2020 - 415 commits behind its parent project - fedora-college - Last commit August 2014 - 22 commits behind its parent project Questions: Are they being used/developed? Do we need them? If not, can we simply delete them? - 85 are "source" repo. Of these I would like to propose that we archive the following 24: - tbs - fpdc - fedora-packages - fedora-search - stickynotes2modernpaste - people2 - pkgwat.api - pkgwat.cli - noggin-old - cpsreport - taiga-contrib-oidc-auth - zanata2fedmsg - rdbsync - fedmsg-notify - fedmsg-health - pkgdb2 - fedmsg-genacls - fedora-stats-tools - fedmsg-java - pagure-hook-receiver - JSAutoLogin - fedmsg-wp - askbot-fedmsg - busmon Then we have a these four that we run but do not maintain and that may want to find a better place: - asknot-ng - fedbages - tahrir - tahrir-api This would reduce the number of projects down to 57 projects most of which are run and maintained by Fedora Infrastructure. Then, I am also wondering if we should move the archived projects to another organisation just to keep the list of projects somewhat manageable. What do you think? Thanks, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Request for Feedback/Resources for Packager Dashboard/Oraculum
On Thu, Nov 12, 2020 at 06:03:01PM +0100, Frantisek Zatloukal wrote: > On Thu, Nov 12, 2020 at 10:03 AM Pierre-Yves Chibon > wrote: > > > Redis is at its heart a caching system that can be tweaked to behave like a > > queueing system. If you're using celery, it may be worth checking if you > > can > > migrate to amqp (and thus rabbitmq) which should be supported by celery > > just > > fine. > > That would give you the possibility to use the rabbitmq cluster we already > > have > > for fedora-messaging. > > > > Now, since you're saying in your reply about the caching issue that you're > > using > > a custom counter in redis, I don't know if that change would be as trivial > > as > > just changing the URL in the celery configuration. > > > > Hmm, we've looked at it a bit with jskladan. The change > is definitely doable but not trivial. We're making use of our redis counter > being thread-safe and atomic. > > The compromise might be switching celery backend to rabbitmq and leaving > the counter to be stored in redis and trying to change it after the > deployment? But that'd still mean we'll have to run Redis somewhere :( . Arf , I was hoping we could get ride of redis there to simplify the deployment, so it's not really helping :( Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Request for Feedback/Resources for Packager Dashboard/Oraculum
On Tue, Nov 10, 2020 at 04:57:20PM +0100, Frantisek Zatloukal wrote: > Hello, > > many of you already heard about Fedora Packager Dashboard [0]. In short, > for those who have not, it's a web application and backend aiming to make > the life of Fedora packagers easier. It combines data from multiple sources > (Pagure, Bugzilla, Bodhi, Koschei,...) relevant to the maintainers of > Fedora packages. > > Tracking all these sites can be time consuming, especially if you maintain > dozens of different packages, so the Dashboard provides everything a > packager might need (or at least what we've thought of) - condensed, > cached, searchable and filterable on one page. > > You can check it out/play with it even if you don't maintain any Fedora > packages, there is no authentication needed, just enter any packager’s > username. Feature-wise, it's pretty robust already, and there are more > things to come (like allowing users to authenticate and see private bugs > and more), but the original planned feature set is complete. > > Currently, it's processing only publicly available data. When we'll start > implementing the ability to authenticate and process any private data, > we'll work closely with the Infra team to make sure there are no open holes. > > Since the announcement of the testing phase, it has been running on a > temporary server which is barely keeping up, so I'd like to open up a > conversation about migration to the Infra OpenShift cluster. > > Here is a brief overview of it's internals (I can elaborate more if anybody > needs me to): > > Backend is a Flask/Python application leveraging Celery for planning and > executing the cache refreshes. The API is striving to be as non-blocking as > possible, using asynchronous-inspired behaviour. The client is given the > data currently available in cache, and advised about the completeness > (complete/partial cache misses) via HTTP status code. > > The parameters for cache refreshes can be customized, depending on the > resources we have/can get. Currently, it's retrieving data for most of the > items every 2 hours (with exceptions like package versions which run daily > and are terribly slow). Backend is caching data for PRs, bugs, and > pre-calculated updates/overrides data for users visiting the app at least > once in two weeks. The main storage is a PostgreSQL database, and > optionally, if RAM is not an issue, we have a local memory-cached layer > that can be enabled (we find it not necessary ATM). > > Apart from storing the pre-crunched information from public sources, we > keep timestamps of the last visit for each user. > > Frontend is a React app fetching and displaying data from the backend > (really nothing to add here :) ). > > Based on the OpenShift testing, I've come to the following schema of pods: > >- > > Redis pod (Celery backend) Redis is at its heart a caching system that can be tweaked to behave like a queueing system. If you're using celery, it may be worth checking if you can migrate to amqp (and thus rabbitmq) which should be supported by celery just fine. That would give you the possibility to use the rabbitmq cluster we already have for fedora-messaging. Now, since you're saying in your reply about the caching issue that you're using a custom counter in redis, I don't know if that change would be as trivial as just changing the URL in the celery configuration. >PostgreSQL pod (cache and watchdog data storage) Kevin has already covered this one and I won't comment any further ;-) Thanks for working on this! Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Possible outdated Jenkins jobs
On Wed, Nov 04, 2020 at 12:33:49PM -0300, Leonardo Rossetti wrote: > I would like some feedback on those jobs as well, they have a considerable > number of builds but some haven't been used for a long time while others > have been failing a lot (some don't even have one successful build): > > https://jenkins-fedora-infra.apps.ci.centos.org/job/fegistry/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-infra-reports/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/gimp-help-2/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-kickstarts/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-comps/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-module-defaults-sgallagh/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/elections/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedocal/ These two should be kept but potentially fixed > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-hubs/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-rube/ These two can be dropped, the corresponding projects have been archived. > https://jenkins-fedora-infra.apps.ci.centos.org/job/nuancier/ This one should be kept and fixed > https://jenkins-fedora-infra.apps.ci.centos.org/job/PackageDB2/ This one can be dropped, the project has been archived > https://jenkins-fedora-infra.apps.ci.centos.org/job/FedoraReview_py2.7/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/FedoraReview_EL6_py2.6/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/javapackages-tools/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/java-packaging-howto/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/xmvn/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/blockerbugs/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-metadata-service/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-dnf-plugin/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-trello-taiga-sync/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-modulemd-resolver/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/pungi-modularity/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/tunir/ I think this one has been archived, I'm not 100% anymore right now though. > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-modulemd/ We may need to reach to the devel list for more exposure and answers on the remaining. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Possible outdated Jenkins jobs
On Mon, Nov 02, 2020 at 11:30:36AM -0300, Leonardo Rossetti wrote: > Hello all, > > We would like to "migrate" the current jenkins instance to a new centos-ci > infrastructure but there are several jobs that will need to be migrated as > well - the process would be to provision a new openshift cluster + a > Jenkins instance and migrate those jobs from the current instance to the > new one. > > Some jobs were never used while others had a few runs but haven't been used > since 2018, so I would like to get some feedback on how many of those could > be skipped/ignored. Impressive list, nice work :) > *Jobs that were never used/triggered:* > > https://jenkins-fedora-infra.apps.ci.centos.org/job/autocloudreporter-pagure-pr/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/Fedora%20Docs%20Builder%202.0%20POC/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-bootstrap/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedrepo_req/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-orchestrator/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/gotun/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/ipsilon/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/kgt/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/koschei/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/koschei-it/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/koschei-rpm/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/lib389/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/modularity-testing-framework/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/modularity-tools/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/NetworkManager/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/OpenShift%20Sample/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/pagure/ This one can definitely be removed. pagure runs its tests at: https://ci.centos.org/job/pagure-pr/ and https://ci.centos.org/job/pagure-pagure > https://jenkins-fedora-infra.apps.ci.centos.org/job/relvalconsumer-pagure-pr/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/resultsdb_conventions/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/ruby-chkbuild/ > > *Jobs that were triggered once or twice (last run was in 2018):* > > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-dnf-plugin/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-metadata-service/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-modulemd/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-modulemd-resolver/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fm-trello-taiga-sync/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/mpi4py/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/pungi-modularity/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/tunir/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/blockerbugs/ > > *Jobs that had more than 2 runs but the last run was back in 2018:* > > https://jenkins-fedora-infra.apps.ci.centos.org/job/xmvn/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/javapackages-tools/ > https://jenkins-fedora-infra.apps.ci.centos.org/job/fedora-tagger/ Fedora-tagger was discontinued/archived a while back now, so that one can probably be removed. > *Jobs that had their last run in 2019:* > > https://jenkins-fedora-infra.apps.ci.centos.org/job/nuancier/ The last commit on nuancier: https://pagure.io/nuancier is July 2019, so that makes sense and if the job still run, I'd vote for keeping it. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: [FBR] Bump the IoT stable keys to fedora-33
On Wed, Oct 28, 2020 at 11:56:11AM +0100, Patrick Uiterwijk wrote:
> Hi,
>
> Can I get acks for the following patch to move the stable IoT composes
> to the Fedora 33 key?
> (Note: there's a single "empty" line change as well, that was a line
> with purely whitespace, which my IDE automatically cleans up.)
+1 for me as well
Pierre
> commit 3ee8dd3f9e883414c7846d115d2926f73ec9ea99 (HEAD -> master)
> Author: Patrick Uiterwijk
> Date: Wed Oct 28 11:26:44 2020 +0100
>
> Bump the IoT stable keys to fedora-33
>
> Signed-off-by: Patrick Uiterwijk
>
> diff --git a/roles/robosignatory/templates/robosignatory.toml.j2
> b/roles/robosignatory/templates/robosignatory.toml.j2
> index 6a933bda9..70fde0d55 100644
> --- a/roles/robosignatory/templates/robosignatory.toml.j2
> +++ b/roles/robosignatory/templates/robosignatory.toml.j2
> @@ -380,7 +380,7 @@ handlers = ["console"]
> key = "{{ (env == 'production')|ternary('fedora-34', 'testkey')
> }}"
> keyid = "{{ (env == 'production')|ternary('45719a39',
> 'd300e724') }}"
> type = "modular"
> -
> +
> # ELN Mass Rebuild
>
> [[consumer_config.koji_instances.primary.tags]]
> @@ -445,13 +445,13 @@ handlers = ["console"]
>
> [consumer_config.ostree_refs."fedora/stable/x86_64/iot"]
> directory = "/mnt/fedora_koji/koji/compose/iot/repo/"
> -key = "{{ (env == 'production')|ternary('fedora-32', 'testkey') }}"
> +key = "{{ (env == 'production')|ternary('fedora-33', 'testkey') }}"
> [consumer_config.ostree_refs."fedora/stable/aarch64/iot"]
> directory = "/mnt/fedora_koji/koji/compose/iot/repo/"
> -key = "{{ (env == 'production')|ternary('fedora-32', 'testkey') }}"
> +key = "{{ (env == 'production')|ternary('fedora-33', 'testkey') }}"
> [consumer_config.ostree_refs."fedora/stable/armhfp/iot"]
> directory = "/mnt/fedora_koji/koji/compose/iot/repo/"
> -key = "{{ (env == 'production')|ternary('fedora-32', 'testkey') }}"
> +key = "{{ (env == 'production')|ternary('fedora-33', 'testkey') }}"
>
> [consumer_config.ostree_refs."fedora/29/x86_64/atomic-host"]
> directory = "/mnt/fedora_koji/koji/compose/ostree/repo/"
> ___
> infrastructure mailing list -- infrastructure@lists.fedoraproject.org
> To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
signature.asc
Description: PGP signature
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Auth test apps in staging
On Mon, Oct 19, 2020 at 10:34:23AM +0200, Aurelien Bompard wrote: > > Sure, but if you could clean them up afterward that would be good. > > Will do, thanks. > > > +1 for me, though I'm not sure I follow the advantage of them over say > > fedocal, > > elections or the wiki. > > I could check the features I'm testing independently, such as group > membership, agreement signing, user attributes, etc. While apps have a > very diverse use of those features, for example with elections I can > check my user attributes but the app will only check if I signed the > required agreement when I try to vote in a currently active election. > If I just install the apps and check that I can log in, I'm afraid > I'll miss some of the testing I want to do just because I'm not > hitting the right code path. Fair, thanks for the explanation! Would it be worth keeping this app somewhere to check/debug potential auth issues later then? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Auth test apps in staging
On Thu, Oct 15, 2020 at 10:32:07AM +0200, Aurelien Bompard wrote: > Hey folks, > > To test authentication with the new AAA system I'd like to deploy a couple > very basic apps that do nothing but auth in staging's openshift. It > shouldn't touch any configuration besides the reverse proxies and the new > project in openshift. And it's staging only. > Is it OK? > Thanks. +1 for me, though I'm not sure I follow the advantage of them over say fedoral, elections or the wiki. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Mote - Issue Review, Management and Code Of Conduct
On Fri, Oct 09, 2020 at 10:49:47AM -0400, Justin W. Flory (he/him) wrote: > On 10/9/20 10:19 AM, Pierre-Yves Chibon wrote: > > Done on both :) > > Thanks Pingou! Could you also please bump my privileges from > "Maintainer" to "Admin"? I need this to on-board other developers for > sharing commit access once we build up some regular contributors. (Also > to help find people to help with issue triage.) > > I do not plan to give away commit access willy-nilly, but it will help > me scale my participation to bring on new faces and people. :) Done, you know what they say: "with great power comes great responsibility", so stay away from spiders ;-) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Mote - Issue Review, Management and Code Of Conduct
On Fri, Oct 09, 2020 at 09:36:35AM -0400, Justin W. Flory (he/him) wrote: > On 10/8/20 12:47 PM, Kevin Fenzi wrote: > > On Wed, Oct 07, 2020 at 12:22:09PM -0400, Justin W. Flory (he/him) wrote: > >> Hi, > >> > >> On 10/7/20 3:51 AM, Pierre-Yves Chibon wrote: > >>> I do not think that anyone in the CPE team is up to date on the mote code, > >>> leading its development in anyway or very much interested in it and it is > >>> not in > >>> the list of application we maintain [1]. > >>> I've recently given back commit access to cydrobolt who has been the main > >>> developer of the project. I am happy to give commit access to Justin or > >>> someone > >>> interested in maintaining mote in the long term. > >> > >> > >> I am happy to help with commit access to Møte, but I do not know how it > >> is currently deployed or managed in Fedora Infrastructure. > >> > >> Are there any deployment docs or any notes anywhere about how Møte is > >> deployed? Is CPE required to deploy new versions? > > > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/mote.html > > has some information. > > > > Currently its deployed via ansible to value01 and value01.stg > > > > There is a sysadmin-mote group that has access to those hosts to update > > things and can run the playbook to deploy them. We could add new people > > there as needed/desired. > > > > Thanks Kevin, this is useful! > > I volunteer for commit access to Møte and I can also act as a sponsor > for sysadmin-mote to bring new people in (once we review the backlog and > improve some developer docs). > > Could someone please grant me commit access on GitHub and invite/promote > me as a sponsor for sysadmin-mote? Done on both :) Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: [FBR] upgrade mediawiki-skin-fedora to 0.09 on wiki0{1,2}
On Thu, Oct 08, 2020 at 09:43:35AM -0700, Kevin Fenzi wrote: > On Thu, Oct 08, 2020 at 05:05:06PM +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > I have just tagged and release the version 0.09 of the mediawiki-skin-fedora > > package. > > It contains two changes: > > - a fix to the CoC link in the footer > > - adding the last edit date near the top of the pages > > (fixes https://pagure.io/fedora-infrastructure/issue/8636 ) > > > > The changes can be reviewed at: > > https://pagure.io/fedora-mediawikitheme/commits/ > > > > The RPM has been built and is in the f32-infra-stg tag already: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=53004452 > > > > I'd like to move that rpm to the f32-infra tag, update that package on both > > wiki01 and wiki02 and reload apache afterward. > > > > > > Thoughts? > > +1, but it would sure be nice to test in staging first. ;) Got staging to work and upgraded the theme there: https://stg.fedoraproject.org/wiki/Fedora_Project_Wiki (see just above "History", "View Source", "View" at the top right of the page). How does it look? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
[FBR] upgrade mediawiki-skin-fedora to 0.09 on wiki0{1,2}
Good Morning Everyone, I have just tagged and release the version 0.09 of the mediawiki-skin-fedora package. It contains two changes: - a fix to the CoC link in the footer - adding the last edit date near the top of the pages (fixes https://pagure.io/fedora-infrastructure/issue/8636 ) The changes can be reviewed at: https://pagure.io/fedora-mediawikitheme/commits/ The RPM has been built and is in the f32-infra-stg tag already: https://koji.fedoraproject.org/koji/taskinfo?taskID=53004452 I'd like to move that rpm to the f32-infra tag, update that package on both wiki01 and wiki02 and reload apache afterward. Thoughts? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Mote - Issue Review, Management and Code Of Conduct
On Wed, Oct 07, 2020 at 05:19:37AM -, Akashdeep Dhar wrote: > Hi folks, > > Mote (https://github.com/fedora-infra/mote/) was written in Flask so it can > garner good advancements during the period of Hacktoberfest 2020 - should we > have good issues and CODE_OF_CONDUCT.md and CONTRIBUTING.md which has gone > through the attention of CPE. There are certain issues that I have made, > which Justin has (thankfully) reviewed - we could use your help there. > 1. Add CONTRIBUTING.md (https://github.com/fedora-infra/mote/issues/126) > 2. Add CODE_OF_CONDUCT.md (https://github.com/fedora-infra/mote/issues/127) > 3. Persist copyright footer information in mobile view > (https://github.com/fedora-infra/mote/issues/128) > 4. [Subjective] Redundant links on the top bar > (https://github.com/fedora-infra/mote/issues/129) > 5. [User experience] Underutilized top menu bar > (https://github.com/fedora-infra/mote/issues/131) > > I would be QAing the site and figuring out issues but an assistance to judge > if at all the issue is worth solving would be appreciated. Also, if anyone > has the admin rights on the repo and figures that the issue can be solved by > person from outside the community - feel free to tag them with hacktoberfest > label and set the topic of the repo as hacktoberfest. I do not think that anyone in the CPE team is up to date on the mote code, leading its development in anyway or very much interested in it and it is not in the list of application we maintain [1]. I've recently given back commit access to cydrobolt who has been the main developer of the project. I am happy to give commit access to Justin or someone interested in maintaining mote in the long term. Pierre [1] https://pingou.fedorapeople.org/fedora_tech_debt_matrix/Applications.html mote is actually missing from there right now, I'm going to add it in the last section "eco-system applications". ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Freeze break request: pagure.fedoraproject.org
On Thu, Sep 24, 2020 at 12:10:01PM -0700, Kevin Fenzi wrote: > Greetings. > > We have been wanting to upgrade pagure01 from rhel7 to rhel8 for a > while. Additionally, the disk we have defined for it is getting too > small, so we would need to add space. > > To deal with both issues, I have created a pagure02 rhel8 instance with > a larger disk on the same virthost. > > I'd like to modify the sshd_config on pagure01 (temporarily) to allow > agent forwarding. This will allow us to use the ansible agent on > batcave01 to rsync data over ssh from pagure01 to pagure02. I intend to > only have this active while copying. > > I plan to then copy: > > /srv > /var/lib/pgsql > /var/www/ > > over and then pingou will take over and get things setup and running. > We can then test things until beta freeze is over and then schedule a > outage late next week to do the cut over. > > Can I get +1s for the sshd change and plan in general? +1 as well. I'll ensure the ansible tweaks I'll have to do only affect pagure02 so we're clear with pagure01 until it goes away. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: FBR
On Thu, Sep 24, 2020 at 10:28:56AM -0400, Stephen John Smoogen wrote: > On Thu, 24 Sep 2020 at 10:24, Pierre-Yves Chibon > wrote: > > > On Thu, Sep 24, 2020 at 10:11:11AM -0400, Stephen John Smoogen wrote: > > > Need to fix opendkim on bastion > > > > > > I merged a fix in https://pagure.io/fedora-infrastructure/issue/9250 but > > > have not run the playbook for bastion to push this out yet. I would like > > to > > > get a +1 or -1 on this before doing that. [I can remove the merge also if > > > that is better.] > > > > Would you have a link to the commit(s) with the fix? > > > > > Durh > > https://pagure.io/fedora-infra/ansible/pull-request/260 Thanks! Seems to be only copr related, right? +1 for me Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: FBR
On Thu, Sep 24, 2020 at 10:11:11AM -0400, Stephen John Smoogen wrote: > Need to fix opendkim on bastion > > I merged a fix in https://pagure.io/fedora-infrastructure/issue/9250 but > have not run the playbook for bastion to push this out yet. I would like to > get a +1 or -1 on this before doing that. [I can remove the merge also if > that is better.] Would you have a link to the commit(s) with the fix? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: What is our technical debt?
On Thu, Jun 25, 2020 at 09:27:24PM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > Just like every team we have technical debt in our work. > I would like your help to try to define what it is for us. Good Morning Everyone, I've been quite late at sending this email and you have my apologies for that. Basically, following on our discussions I've looked at all the applications we maintain or/and run and built a matrix of our technical debt. A brief overview: - 56 apps are listed in the matrix - 42 apps support python3 (or not concerned by python) - 39 apps support fedora-messaging - 26 apps have fedora-messaging schemas - 18 apps are clear documentation identified - 31 apps have clear unit-tests identified - 20 apps are clearly using pytest for their tests (the other could be either unknown or using the deprecated nosetests) - 45 apps have support for OIDC (does not mean they are all currently using it though!) - 43 apps have a clear primary point of contact - 16 apps have a clear secondary point of contact So as you can see, there is not a single criteria by which we are ok for all our apps. It is also worth noting that we lack a primary point of contact for 6 of our applications that are considered "critical path" (ie: required to build Fedora and ship it to our users). The overall matrix is available at: https://pingou.fedorapeople.org/fedora_tech_debt_matrix/Applications.html We have also identified a few infrastructure technical debts that we have recorded in a second sheet: https://pingou.fedorapeople.org/fedora_tech_debt_matrix/Infrastructure.html Some of these have already been submitted as initiative briefs so likely won't but still need to be addressed at some point. As you can see, we do not lack items in our backlog... Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Glossary and day to day work in Fedora doc update
Good Morning Everyone, I've spent a little time on the CPE docs related to the day to day work in Fedora and defining the terms we use during our triage process. The outcome can be seen at: https://pagure.io/cpe/docs/pull-request/12 and so see how it will look built, at: http://ambre.pingoured.fr/cpe-docs/cpe/ Reviews, comments and suggestions most welcome! Thanks, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Tags on pull-requests
Good Morning Everyone, To make it easier to find out the important pull-requests during freeze, I have added two tags to our ansible repo: - freeze-break-request - post-freeze So if you want to flag a pull-request as FBR or open the PR but note that this can wait for after the freeze feel free to use these tags. Hoping this helps, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Freeze break request: update koji to 1.22.1
On Wed, Sep 09, 2020 at 11:46:58AM -0700, Kevin Fenzi wrote: > koji 1.22.1 just was released. It's a small bugfix only release: > https://lists.fedorahosted.org/archives/list/koji-de...@lists.fedorahosted.org/thread/YU5CXXID6VMWMV6EBCFYIHPI5LMHTVHH/ > > https://docs.pagure.org/koji/release_notes/release_notes_1.22.1/ > > We already had a patched rpm with the btrfs subvolume and > extra-boot-opts fixes. I want to update to this version to get > the fix for time formatting for timezone values. This is the bug that > prevents us from loading information about container builds (either on > the web interface or via the cli). A number of people have noticed this > bug. :( > > There's no schema update so we can downgrade if something happens. > > +1s? +1 for me (fingers crossed!) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
IPAM/DCIM for Fedora Infrastructure
ignatenkobrain wanted to share this with us as something potentially interesting to look at. He opened a ticket but agreed that an email thread would be better suited to discuss this, so here it is and here below is Igor's original comment: Hi folks, This is not really request to do anything but rather heads-up from work I've been doing in GoodData for some time. We've been searching for something that helps us to have list of devices, their IPs and generally some kind of IP management in one place. So we started to use netbox (I think it is originating from DigitalOcean). I've finally managed to package it https://src.fedoraproject.org/rpms/netbox in Fedora. It supports LDAP and I guess can be somehow paired with Kerberos. I did not check if it is possible to pair it with OIDC, but since it is Django should be not very hard. So in case you were looking for something like this - feel free to try it out and let me know if you have any issues. Original ticket: https://pagure.io/fedora-infrastructure/issue/9279 Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Planned Outage - Blockerbugs - 2020-08-18 17:00 UTC
There will be an outage starting at 2020-08-18 17:00UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2020-08-18 17:00UTC' Reason for outage: Blockerbugs host VM upgrade from EL7 to FC32. Affected Services: https://qa.fedoraproject.org/blockerbugs/ Ticket Link: https://pagure.io/fedora-infrastructure/issue/9244 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Hosting Options for QA Projects
On Sat, Aug 15, 2020 at 01:22:43PM +0200, Frantisek Zatloukal wrote: >On Sat, Aug 15, 2020 at 11:26 AM Pierre-Yves Chibon ><[1]pin...@pingoured.fr> wrote: > > Out of curiosity, do either of them store personal information? > I suspect not for the second (the dashboard) but I don't know for the > first one. > >Testdays store just username afaik, I'll verify this (I am just 90% sure >right now). >Packager Dashboard/Oraculum stores username and a date of the last load of >that user page (which could be done by anybody cause we're not >authenticating users there). What about email addresses? I figure they are needed for the bugzilla integration, no? (which raises a question: how do you handle the bugzilla email overrides we currently have in place? ie: people who do not use the same email address in FAS and in bugzilla, for example to be able to use their @fedoraproject.org alias in bugzilla). Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Hosting Options for QA Projects
On Thu, Aug 13, 2020 at 03:04:51PM -0600, Tim Flink wrote: > From what I understand, communishift as it was originally planned is > not likely to be a thing going forward. We had been planning to use > communishift to host a number of QA projects and we're looking for new > options going forward. Those projects are: > > > Testdays [1] is an app that we use to help run test days. It used to > live on the old cloud and is currently hosted outside Fedora's infra on > a machine we have access to; the plan was to move it to communishift > once that was available. > > The packager dashboard [2] was recently announced for testing on devel@. > It and its backend service, oraculum, live on the same external machine > as the testdays app. Out of curiosity, do either of them store personal information? I suspect not for the second (the dashboard) but I don't know for the first one. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Congrats to our new sysadmin-mainers
On Sun, Aug 09, 2020 at 09:40:54AM -0700, Kevin Fenzi wrote: > I'm happy to announce that We have approved several folks into the > sysadmin-main group: > > mobrien - Mark O'Brien > abompard - Aurelien Bompard > > This is the core group of trusted folks that high level access to most > everything in fedora infrastructure. > > Mark has been deploying proxies to aws and working through all the > associated issues successfully. Aurelien has been around for many years > and intends to deploy our new account system interface noggin, which > this access to help with. > > They have both proved their dedication, trustworthiness, and ability. > > Congrats to them both! > > Use your powers for good! :) Congrats folks! And remember what sudo says: With great power comes great oncall hours! :) Ugh? It's not the original saying? I'm confused then. Well, anyway, congrats again! Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: The state of the planet (the app)
On Mon, Jul 20, 2020 at 06:18:48AM -0400, Neal Gompa wrote: > On Mon, Jul 20, 2020 at 4:36 AM Pierre-Yves Chibon > wrote: > > > > Good Morning Everyone, > > > > Running a personal planet and having upgraded the box running it to a > > recent OS > > (Fedora in this case), I have found out that the underlying application > > does not > > support python3. > > > > To be precise, the main script says: > > Requires Python 2.1, recommends 2.3. > > > > Needless to say, this doesn't work anymore with python3. > > > > So I went looking a bit around to see what is available. > > There is Venus which we run, which has this problem ^ and hasn't been > > touched in > > 9 years: > > https://github.com/rubys/venus > > > > There are a few java-based, php-based, or ruby-based, with different level > > of > > activity (though to be fair, RSS and planets have been there for a while > > now, so > > a working application likely does not need much maintenance anymore). > > However, nothing jumped at me as a clear successor for our setup. > > > > Do people have some experience with planet? Would you recommend us > > something? > > > > > > At this stage, it is very unclear to me if the best approach is to switch > > application (new stack, new UI to do, new configuration file to > > do/adjust...) or > > port venus to python3 (potentially a 1 time effort but what about the long > > term > > maintenance?). > > > > I believe Stasiek (CC'd to this email) recently implemented a planet > replacement. I am unsure if he used Venus or something else, though. > > Perhaps he can reply with information... I ran into it while looking for info. If I understood correctly, the new planet is at: https://github.com/openSUSE/planet-o-o which seems to involve ruby and jekyll. The old planet was at: https://github.com/openSUSE/planet.opensuse.org and apparently was also relying on old code (py 2.6 looking at the libs folder in there). Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
The state of the planet (the app)
Good Morning Everyone, Running a personal planet and having upgraded the box running it to a recent OS (Fedora in this case), I have found out that the underlying application does not support python3. To be precise, the main script says: Requires Python 2.1, recommends 2.3. Needless to say, this doesn't work anymore with python3. So I went looking a bit around to see what is available. There is Venus which we run, which has this problem ^ and hasn't been touched in 9 years: https://github.com/rubys/venus There are a few java-based, php-based, or ruby-based, with different level of activity (though to be fair, RSS and planets have been there for a while now, so a working application likely does not need much maintenance anymore). However, nothing jumped at me as a clear successor for our setup. Do people have some experience with planet? Would you recommend us something? At this stage, it is very unclear to me if the best approach is to switch application (new stack, new UI to do, new configuration file to do/adjust...) or port venus to python3 (potentially a 1 time effort but what about the long term maintenance?). Looking forward to hear your thoughts, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Testing new implementation of OIDC when updating app
On Wed, Jul 08, 2020 at 04:09:44PM -, Jonathan Trossbach wrote: > Thanks for the quick response Pierre. I will follow these resources you > recommended. > > As for looking into the fedocal README: if you mean for me to fix the README > and then make a PR for it on github, I should be able to do that. If you have > something else in mind, you might want to make a ticket for it. I meant fixing the README then PR on github/pagure :) Thanks! Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Testing new implementation of OIDC when updating app
On Tue, Jul 07, 2020 at 10:19:43PM -, Jonathan Trossbach wrote: > Hi all, > > I am working on updating nuancier to work with the OIDC authentication > library. I believe I have made all the necessary changes but am not sure > about the best way to go about testing the changes I have made, which can be > found here: https://github.com/jontrossbach/nuancier/tree/update-to-oidc > > Other applications like fedora elections have already been updated to OIDC, > can someone tell me how they tested the new authentication process in their > development environments for those applications and tell me how I can best > test the changes for the OIDC in nuancier? I know at least one other person > is wondering the same thing. Elections has the information in its readme: https://pagure.io/elections Basically, you can create a client_secrets.json by calling iddev.fedorainfracloud.org and use this for testing locally. Looks like fedocal didn't get the update to the README :( Is that something you could look into? Otherwise I'll make a ticket of it so it's not lost. Thanks, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Another Rust MirrorManager experiment
On Fri, Jul 03, 2020 at 08:03:16AM +0200, Adrian Reber wrote: > On Thu, Jul 02, 2020 at 09:44:10AM +0200, Pierre-Yves Chibon wrote: > > On Wed, Jul 01, 2020 at 06:25:47PM +0200, Adrian Reber wrote: > > > On Wed, Jul 01, 2020 at 09:16:05AM -0700, Kevin Fenzi wrote: > > > > On Tue, Jun 30, 2020 at 02:17:30PM +0200, Adrian Reber wrote: > > > > > On Mon, Jun 15, 2020 at 03:36:23PM -0700, Kevin Fenzi wrote: > > > > > > On Wed, Jun 10, 2020 at 11:09:49AM +0200, Adrian Reber wrote: > > > > > > > > > > > > > > Then I just have to wait a bit. No problem. > > > > > > > > > > > > > > > > Having the possibility to generate the mirrorlist input data > > > > > > > > > in about a > > > > > > > > > minute would significantly reduce the load on the database > > > > > > > > > server and > > > > > > > > > enable us to react much faster if broken protobuf data has > > > > > > > > > been synced > > > > > > > > > to the mirrorlist servers on the proxies. > > > > > > > > > > > > > > > > Yeah, and I wonder if it would let us revisit the entire > > > > > > > > sequence from > > > > > > > > 'update push finished' to updated mirrorlist server. > > > > > > > > > > > > This would help us with the case of: > > > > > > - updates push/rawhide finishes, master mirror is updated. > > > > > > - openqa/other internal thing tries to get images or updates in that > > > > > > change and gets a metalink with the old checksum so it can't get > > > > > > the > > > > > > new stuff. > > > > > > - mm-backend01 generates and pushes out a new protobuf. > > > > > > > > > > > > > > Probably. As the new code will not run on the current RHEL 7 based > > > > > > > mm-backend01 would it make sense to run a short running service > > > > > > > like > > > > > > > this on Fedora's OpenShift? We could also create a new read-only > > > > > > > (SELECT > > > > > > > only) database account for this. > > > > > > > > > > > > We could, or as smooge suggests make a mm-backend02? > > > > > > > > > > > > But I guess now mm-backend02 just generates new proobuf files and > > > > > > copies > > > > > > them to mirrorlists? If thats all it's doing, perhaps we could > > > > > > indeed > > > > > > replace it with an openshift project. > > > > > > > > > > We need a system to run the tool and copy the data to all proxies. > > > > > > > > > > I would like to see a new MirrorManager database user who can only do > > > > > selects as that is all we need. > > > > > > > > > > Currently we copy the files via SSH to the proxies, if we continue > > > > > doing > > > > > it that way, then we would also need the existing SSH key to copy the > > > > > data to the proxies. > > > > > > > > > > Easiest would probably be a small Fedora 32 based VM with 2GB of > > > > > memory. > > > > > > > > I'm not sure f32 will work with 2gb memory anymore. I dont think it > > > > installs at any rate. > > > > > > > > I do like the idea of just making it an openshift pod. Perhaps this > > > > could even fit with pingous 'toddlers' setup. ie: > > > > > > > > * listen for message saying a repo has updated > > > > * update the db > > > > * create the protobuf > > > > * push out to proxies > > > > > > > > The only weird part of putting it in openshift is that we would need to > > > > have fedora_ftp (ro) there available as a volume, but that is doable... > > > > > > No, this part only needs to talk read-only to the database. This is not > > > touching anything on the disk besides writing the output. I guess you > > > were thinking about the umdl (update-master-directory-listing) part. > > > That would need ro access to the file-system. > > > > > > The part I am talking about just reads the database and creates a > >
Re: Another Rust MirrorManager experiment
On Wed, Jul 01, 2020 at 06:25:47PM +0200, Adrian Reber wrote: > On Wed, Jul 01, 2020 at 09:16:05AM -0700, Kevin Fenzi wrote: > > On Tue, Jun 30, 2020 at 02:17:30PM +0200, Adrian Reber wrote: > > > On Mon, Jun 15, 2020 at 03:36:23PM -0700, Kevin Fenzi wrote: > > > > On Wed, Jun 10, 2020 at 11:09:49AM +0200, Adrian Reber wrote: > > > > > > > > > > Then I just have to wait a bit. No problem. > > > > > > > > > > > > Having the possibility to generate the mirrorlist input data in > > > > > > > about a > > > > > > > minute would significantly reduce the load on the database server > > > > > > > and > > > > > > > enable us to react much faster if broken protobuf data has been > > > > > > > synced > > > > > > > to the mirrorlist servers on the proxies. > > > > > > > > > > > > Yeah, and I wonder if it would let us revisit the entire sequence > > > > > > from > > > > > > 'update push finished' to updated mirrorlist server. > > > > > > > > This would help us with the case of: > > > > - updates push/rawhide finishes, master mirror is updated. > > > > - openqa/other internal thing tries to get images or updates in that > > > > change and gets a metalink with the old checksum so it can't get the > > > > new stuff. > > > > - mm-backend01 generates and pushes out a new protobuf. > > > > > > > > > > Probably. As the new code will not run on the current RHEL 7 based > > > > > mm-backend01 would it make sense to run a short running service like > > > > > this on Fedora's OpenShift? We could also create a new read-only > > > > > (SELECT > > > > > only) database account for this. > > > > > > > > We could, or as smooge suggests make a mm-backend02? > > > > > > > > But I guess now mm-backend02 just generates new proobuf files and copies > > > > them to mirrorlists? If thats all it's doing, perhaps we could indeed > > > > replace it with an openshift project. > > > > > > We need a system to run the tool and copy the data to all proxies. > > > > > > I would like to see a new MirrorManager database user who can only do > > > selects as that is all we need. > > > > > > Currently we copy the files via SSH to the proxies, if we continue doing > > > it that way, then we would also need the existing SSH key to copy the > > > data to the proxies. > > > > > > Easiest would probably be a small Fedora 32 based VM with 2GB of memory. > > > > I'm not sure f32 will work with 2gb memory anymore. I dont think it > > installs at any rate. > > > > I do like the idea of just making it an openshift pod. Perhaps this > > could even fit with pingous 'toddlers' setup. ie: > > > > * listen for message saying a repo has updated > > * update the db > > * create the protobuf > > * push out to proxies > > > > The only weird part of putting it in openshift is that we would need to > > have fedora_ftp (ro) there available as a volume, but that is doable... > > No, this part only needs to talk read-only to the database. This is not > touching anything on the disk besides writing the output. I guess you > were thinking about the umdl (update-master-directory-listing) part. > That would need ro access to the file-system. > > The part I am talking about just reads the database and creates a > protobuf snapshot of the database which is then used by the mirrorlist > servers on the proxies. > > Currently it runs once every hour. Which works pretty good so far. > Triggering it on a message makes only limited sense as it depends on the > results of the crawler. We could run it twice an hour to have newer > database snapshots on the proxies. > > How can I prepare it for running in openshift. Can I use the > configuration for toddlers? Where can I find that? Toddlers has recently gained the possibility to trigger at certain time. Well we're actually sort of abusing it, we've added a script (playtime) that will send a fedora-messaging message and that should be called from a cron job. That message should then trigger the corresponding toddler. This (playtime) is not yet deployed in production so I can't point you to an example, but the project itself is at: https://pagure.io/fedora-infra/toddlers and the openshift config is at: https://pagure.io/fedora-infra/ansible/blob/master/f/playbooks/openshift-apps/toddlers.yml Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: What is our technical debt?
On Mon, Jun 29, 2020 at 11:43:53PM +0200, Miroslav Suchý wrote: > Dne 25. 06. 20 v 21:27 Pierre-Yves Chibon napsal(a): > > What else would we want in there? > > Automate branching. > Or to be more general - automate new release. The whole process include way > too many manual steps. What are you talking about here? The Fedora release process? The mass-branching in dist-git? Or do you mean our individual apps? > Allow people to create groups in FAS without the need to create infra issue. I don't know how much self-service we want to be for groups, there are multiple groups and it's already confusing to some people, I fear that if we open this up we may endup in a weird situation. We're also using the FPCA+1 as a way to distinguish "active" contributors, so if creating groups become self-service, we may end up opening the doors to spam account creating their own group to become FPCA+1 giving them access to @fedoraproject.org email alias as well as edit to the wiki (which they have messed with a few times already in the past). Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: What is our technical debt?
On Thu, Jun 25, 2020 at 04:03:35PM -0700, Adam Williamson wrote: > On Thu, 2020-06-25 at 21:59 +0200, Pierre-Yves Chibon wrote: > > On Thu, Jun 25, 2020 at 03:51:42PM -0400, Neal Gompa wrote: > > > On Thu, Jun 25, 2020 at 3:27 PM Pierre-Yves Chibon > > > wrote: > > > > > > > > Good Morning Everyone, > > > > > > > > Just like every team we have technical debt in our work. > > > > I would like your help to try to define what it is for us. > > > > > > > > So far, I've come up with the following: > > > > - python3 support/migration > > > > - fedora-messaging > > > > - fedora-messaging schema > > > > - documentation > > > > - (unit-)tests > > > > - OpenID Connect > > > > > > > > What else would we want in there? > > > > > > > > > > These are all good things, especially the documentation one. I'd like > > > to zero in on a particular aspect of documentation, though: getting to > > > hack on it. A lot of our projects are surprisingly difficult to get up > > > and running for someone to play with and hack on, and this is > > > increasingly true as we adopt OpenShift-style deployments. One way we > > > solved this in Pagure is by providing some quick start processes in > > > the documentation and a fully working Vagrant based process to boot up > > > and have a working environment to hack on the code. > > > > > > I'm not necessarily going to specify it needs to be Vagrant for > > > everything, but I think this is something we should have for all of > > > our projects, so that people *can* easily get going to use and > > > contribute. > > > > I've recently had quite some pain with vagrant (just today, I've tried > > several > > time to start my bodhi vagrant box and lost my morning w/o success). > > > > I guess it may be nice to see if there is something else out there that we > > could > > leverage. > > If we could adopt one and try to get have it on most of our apps this may > > be a > > nice goal for us to work towards. > > The thing is, even if vagrant *itself* is shonky as hell (I agree), if > you vagrant-ify a project, there is at least a recipe I can relatively > easily follow in a manually setup VM or mock root or whatever I like. > The fact that the recipe is designed for vagrant is almost incidental, > the key thing is that there's an 'official' "here's how to set up a dev > env from scratch" recipe. Agreed, the basic ansible attached to the project is helpful to get an idea on how to get it to work (with some caveats such as the vagrant box is more likely configured for dev than for prod (ie: running from the git checkout mounted within the vm than running via wsgi/gunicorn from an app properly installed)). I wonder if https://github.com/karmab/kcli maybe a suitable replacement to vagrant. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: What is our technical debt?
On Thu, Jun 25, 2020 at 03:51:42PM -0400, Neal Gompa wrote: > On Thu, Jun 25, 2020 at 3:27 PM Pierre-Yves Chibon > wrote: > > > > Good Morning Everyone, > > > > Just like every team we have technical debt in our work. > > I would like your help to try to define what it is for us. > > > > So far, I've come up with the following: > > - python3 support/migration > > - fedora-messaging > > - fedora-messaging schema > > - documentation > > - (unit-)tests > > - OpenID Connect > > > > What else would we want in there? > > > > These are all good things, especially the documentation one. I'd like > to zero in on a particular aspect of documentation, though: getting to > hack on it. A lot of our projects are surprisingly difficult to get up > and running for someone to play with and hack on, and this is > increasingly true as we adopt OpenShift-style deployments. One way we > solved this in Pagure is by providing some quick start processes in > the documentation and a fully working Vagrant based process to boot up > and have a working environment to hack on the code. > > I'm not necessarily going to specify it needs to be Vagrant for > everything, but I think this is something we should have for all of > our projects, so that people *can* easily get going to use and > contribute. I've recently had quite some pain with vagrant (just today, I've tried several time to start my bodhi vagrant box and lost my morning w/o success). I guess it may be nice to see if there is something else out there that we could leverage. If we could adopt one and try to get have it on most of our apps this may be a nice goal for us to work towards. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
What is our technical debt?
Good Morning Everyone, Just like every team we have technical debt in our work. I would like your help to try to define what it is for us. So far, I've come up with the following: - python3 support/migration - fedora-messaging - fedora-messaging schema - documentation - (unit-)tests - OpenID Connect What else would we want in there? Looking forward to your thoughts, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: The future of loopabull
On Thu, May 28, 2020 at 02:18:38PM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > I know this question has already been raised a few times, but I think we > should > raise it once more: what do we see as future for loopabull? > > It is currently triggered on 4 topics (3 from prod and 1 from stg) to do > basically > three actions: > - Flag commit successfully built in koji, in other words it adds these flags > to dist-git: > > https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce > - Flag when the Fedora CI start testing a PR > - Flag when the Fedora CI finished testing a PR (and thus reports Pass/Fail) > > Upstream released yesterday a 0.0.7 release which brings supports for > fedora-messaging (contributed by your servitor). > Looking at the code, it should be python3 compatible, but it doesn't say > specifically in the setup.py and I honestly don't remember if I've tested that > or not. > The package has been orphaned in Fedora for over 10 months and has thus been > retired. > > I've had a chat with upstream yesterday and they are still interested in the > project but more as a pet project and their time is just like the rest of us, > limited for pet projects these days. > That being said the code base is really quite small and involves technologies > we're already using in other places (python-pika, celery, rabbitmq, > ansible...) > so there isn't really anything new there. > > One of its limitation currently is with secrets, how to pass/specify them. > This is something we could circumvent via ansible-vault or so, but it needs a > little investigation. > > I basically see three ways forward with this: > - We continue with loopabull and we need to check its python3 support, how to > deal with secrets, if we can get it to run in openshift & so on. > - We look for something else, similar. The requirements being: > - Run a task when seeing a message in our message bus > - Handle secrets > - Scalable up/down > - Runnable in openshift is a bonus > - Preferably in a language we can debug (python++, potentially rust) > - We write something that fits our needs and requirements > > > Would you know something that fits our requirements and that we could just > run? > If not, do you have a preferred way between options #1 and #3? So I took a few hours and started poking at this. I've ended up with: https://pagure.io/fedora-infra/toddlers (a bunch of small programs running around: toddlers :)) It's basically, one fedora-messaging consumer and plugins. Some of its advantages: - We can run it in openshift easily and we should be able to scale it up/down as needed - Managing secrets is just like managing secrets for all our apps in openshift. - Relies on our main rabbitmq server and thus has monitoring (while loopabull ran its own, which granted we could monitor but that's something we've not done while we have this in place for our main cluster and easily configurable via ansible). I would still like to add some unit-tests for this but from empirical testing (ie: running it locally) it is doing what it should be doing and the two/three tasks loopabull have already been ported. Let me know what you think of it! :) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: batcave moved to iad2
On Thu, Jun 04, 2020 at 06:59:59PM -0700, Kevin Fenzi wrote: > Eariler today we moved things over to batcave01.iad2.fedoraproject.org > > batcave01.phx2.fedoraproject.org is still up, but all it's services are > disabled and it has a /etc/nologin to keep anyone from using it. > > If you need to run playbooks or anything else you normally did on > batcave01.phx2.fedoraproject.org, please do that not on > batcave01.iad2.fedoraproject.org. ;) > > If something is broken, please file a ticket and we will look into it as > soon as we are able. There are few changes you may have to do to access the new batcave. The long and short of it is that the access using the book shelves on the yellow room has been decommissioned in favor of the fireplace access. The ssh doc is up to date at: https://docs.pagure.org/infra-docs/sysadmin-guide/sops/sshaccess.html You can see the diffs that updated this doc at: - https://pagure.io/infra-docs/pull-request/182#request_diff and - https://pagure.io/infra-docs/pull-request/184#request_diff Thanks to Mark for working on this! Pierre pgpiDxWQKEGNm.pgp Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: The future of loopabull
On Fri, May 29, 2020 at 03:18:58PM +0200, Clement Verna wrote: >On Thu, 28 May 2020 at 14:27, Pierre-Yves Chibon <[1]pin...@pingoured.fr> >wrote: > > Good Morning Everyone, > > I know this question has already been raised a few times, but I think we > should > raise it once more: what do we see as future for loopabull? > > It is currently triggered on 4 topics (3 from prod and 1 from stg) to do > basically > three actions: > - Flag commit successfully built in koji, in other words it adds these > flags > to dist-git: > > > [2]https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce > - Flag when the Fedora CI start testing a PR > - Flag when the Fedora CI finished testing a PR (and thus reports > Pass/Fail) > > Upstream released yesterday a 0.0.7 release which brings supports for > fedora-messaging (contributed by your servitor). > Looking at the code, it should be python3 compatible, but it doesn't say > specifically in the setup.py and I honestly don't remember if I've > tested that > or not. > The package has been orphaned in Fedora for over 10 months and has thus > been > retired. > > I've had a chat with upstream yesterday and they are still interested in > the > project but more as a pet project and their time is just like the rest > of us, > limited for pet projects these days. > That being said the code base is really quite small and involves > technologies > we're already using in other places (python-pika, celery, rabbitmq, > ansible...) > so there isn't really anything new there. > > One of its limitation currently is with secrets, how to pass/specify > them. > This is something we could circumvent via ansible-vault or so, but it > needs a > little investigation. > > I basically see three ways forward with this: > - We continue with loopabull and we need to check its python3 support, > how to > deal with secrets, if we can get it to run in openshift & so on. > - We look for something else, similar. The requirements being: > - Run a task when seeing a message in our message bus > - Handle secrets > - Scalable up/down > - Runnable in openshift is a bonus > - Preferably in a language we can debug (python++, potentially rust) > - We write something that fits our needs and requirements > >There is a PR[0] in fedora-messaging to add a 'run' callback that would >let you execute any command, I think that might be a nice solution and I >think it would meet most of the requirements. > >[0] - [3]https://github.com/fedora-infra/fedora-messaging/pull/163 Isn't that the equivalent of having us write a custom fedora-messaging consumer for each task we want to automate? In a way I like this, it's simple(r), really straight forward, constraint and self-contained. There is no risk that a previous task prevents a following one to be executed. On the other hand it also means that if we move to, say fed-messaging, in the future, we will have to convert more consumers. If that's a trade off we're willing to live with, then I'm ok with it as well. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: The future of loopabull
On Thu, May 28, 2020 at 08:30:02AM -0400, Neal Gompa wrote: > On Thu, May 28, 2020 at 8:19 AM Pierre-Yves Chibon > wrote: > > > > Good Morning Everyone, > > > > I know this question has already been raised a few times, but I think we > > should > > raise it once more: what do we see as future for loopabull? > > > > It is currently triggered on 4 topics (3 from prod and 1 from stg) to do > > basically > > three actions: > > - Flag commit successfully built in koji, in other words it adds these flags > > to dist-git: > > > > https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce > > - Flag when the Fedora CI start testing a PR > > - Flag when the Fedora CI finished testing a PR (and thus reports Pass/Fail) > > > > Wait, wait, wait, what?! These aren't things natively supported by the > software we use (Koji and Zuul)? It seems like the place to start here > would be to move this functionality to the right places. A koji plugin > and an extension for the Zuul pagure driver to do those things would > make a ton more sense here... Loopabull executes any playbook on a message, the fact that we're using it only for that is a mere accident, it's meant to be much more than that. We could in fact use it to do some of the releng tasks (that was one of the original idea for it), we just haven't got around to do that. Zuul may be an option here, though wouldn't it have the same issue as loopabull wrt secrets? Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
The future of loopabull
Good Morning Everyone, I know this question has already been raised a few times, but I think we should raise it once more: what do we see as future for loopabull? It is currently triggered on 4 topics (3 from prod and 1 from stg) to do basically three actions: - Flag commit successfully built in koji, in other words it adds these flags to dist-git: https://src.fedoraproject.org/rpms/mingw-filesystem/c/717f2a929bd25b62a0427e8e5c3792a0939dbfce - Flag when the Fedora CI start testing a PR - Flag when the Fedora CI finished testing a PR (and thus reports Pass/Fail) Upstream released yesterday a 0.0.7 release which brings supports for fedora-messaging (contributed by your servitor). Looking at the code, it should be python3 compatible, but it doesn't say specifically in the setup.py and I honestly don't remember if I've tested that or not. The package has been orphaned in Fedora for over 10 months and has thus been retired. I've had a chat with upstream yesterday and they are still interested in the project but more as a pet project and their time is just like the rest of us, limited for pet projects these days. That being said the code base is really quite small and involves technologies we're already using in other places (python-pika, celery, rabbitmq, ansible...) so there isn't really anything new there. One of its limitation currently is with secrets, how to pass/specify them. This is something we could circumvent via ansible-vault or so, but it needs a little investigation. I basically see three ways forward with this: - We continue with loopabull and we need to check its python3 support, how to deal with secrets, if we can get it to run in openshift & so on. - We look for something else, similar. The requirements being: - Run a task when seeing a message in our message bus - Handle secrets - Scalable up/down - Runnable in openshift is a bonus - Preferably in a language we can debug (python++, potentially rust) - We write something that fits our needs and requirements Would you know something that fits our requirements and that we could just run? If not, do you have a preferred way between options #1 and #3? Thanks for your thoughts, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: IAD2 datacenter testing/application validation
On Wed, May 27, 2020 at 10:29:20AM +0200, Clement Verna wrote: >On Wed, 27 May 2020 at 09:42, Michal Konecny <[1]mkone...@redhat.com> >wrote: > > I don't see the-new-hotness anywhere. Will it be deployed together with > Anitya? > >I think these 2 apps were in the Minimal Viable Fedora infra so they will >be deployed but in the second phase when all the hardware is available in >IAD2. Were or were not (in the Minimal Viable Fedora)? :) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Backlog prioritization
On Fri, Apr 17, 2020 at 11:53:34AM +0200, Pierre-Yves Chibon wrote: > On Thu, Apr 16, 2020 at 03:01:35PM +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > I have a few items in my backlog that I'd like to discuss priorities with > > you, > > so here is the unsorted list, let me know how you would sort it :) > > > > * Finish bringing bugzilla overrides to dist-git > > means: > > - Deploy pagure 5.9.x to src.fp.o > > - Migrate the data from the scm-requests repo to dist-git > > - Adjust the README of the scm-requests repo > > - Close off the scm-requests repo to pull-requests > > - Announce & profit/watch the world burn > > Blocked by the current freeze, unless a FBR is acceptable to upgrade > > pagure > > to 5.9.x (knowing that 5.9.x does not bring any DB changes). > > > > * Reworkd the packager sync from FAS to bugzilla > > Currently, there is a cron job that adds bugzilla privileges to people > > that > > are added to the packager group. That cron relies on a DB in FAS that > > tracks > > people being added or removed from this group. This isn't quite the 2020 > > way > > of doing things and this will not be portable to noggin (the next gen > > FAS). > > Python-bugzilla also recently (it's merged but not released) gained > > support > > for groups, so we can finally do something like: ask FAS for all the > > packagers > > and their email, list all the people in the corresponding group in > > bugzilla, > > do a diff and add/remove accordingly. > > fixes https://pagure.io/fedora-infrastructure/issue/8628 > > > > * Finish retiring in bugzilla packages that are retired in Fedora (ie: close > > these components to new bugs in bugzilla). > > This was blocked on a change in bugzilla which has been deployed in the > > last > > release. So we should be able to proceed and adjust our > > bugzilla<->dist-git > > sync script to do this. > > fixes https://pagure.io/fedora-infrastructure/issue/7639 > > > > * Mirror the ansible git repo on pagure.io > > I'd like to set up a mirror on pagure.io that would pull from batcave01. > > It > > would mean that PR can't really be merged in this mirror (unless we're > > fast > > enough to pull from the mirror and push to the main repo right after the > > merge, > > but there is a risk of a race-condition where the commit(s) just merged > > are > > overridden by a push to the main repo). > > It would expose a more up to date ansible repo to the public and we > > should be > > able to wget the patch of the PRs, git am to apply them and git push to > > the > > main repo. > > > > * Migrate stg.pagure.io and src.stg.fedoraproject.org to RHEL8. > > While we're in freeze, I figure this is a good time to do this. We could > > do > > pagure.io post-freeze and wait to do src.fp.o when it gets reinstalled in > > the > > new data-center. > > So this is the order I deduced from the responses: > > Clément Ben Kevin Total* > BZ overrides on dist-git21 47 > stg.pagure to RHEL8 14 27 > Packager sync to BZ 32 16 > Retire packages in BZ 45 5 14 > Mirror ansible to pagure43 3 10 > > *to sort in ascending order A small update of where things are: > Packager sync to BZ - I've migrated the current script away from FAS and in doing so learned that the issue may not be coming from that script but from a bug in bugzilla itself. So when bugzilla is fixed, well the old script may start working again :) The new script can be ported to nogging when we move to it. > stg.pagure to RHEL8 Done, we should look at src.stg now. > BZ overrides on dist-git (since it needs to wait for after freeze) Freeze being now over, I'm thinking to tackle this this week > Retire packages in BZ Done > Mirror ansible to pagure Done as of this week-end, thanks Kevin! Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Mirror the ansible repo from pagure in the batcave
On Thu, Apr 30, 2020 at 02:06:15PM +0200, Pavel Raiskup wrote: > On Friday, April 24, 2020 5:47:22 PM CEST Kevin Fenzi wrote: > > On Fri, Apr 24, 2020 at 02:21:14PM +0200, Pierre-Yves Chibon wrote: > > > > ...snip... > > > > > I was going for: https://pagure.io/Fedora-Infra/ansible/ which is marked > > > as > > > being the future location of our ansible repo and already has a copy of > > > it. > > > > Yeah, I am not even sure who made that. It was not me. ;) > > > > > I had not realized we have content in > > > https://pagure.io/fedora-infrastructure/ 's > > > git. > > > > Yes, mostly stuff that doesn't matter too much anymore, but it used to > > have 'public' things we needed to share out from puppet repo. > > > > > If we really want to have the ansible repo in that repo, the easiest may > > > be to > > > rebase these commits on the top of ansible and force push to that repo (so > > > current ansible clone would pull fine once they've updated their urls=). > > > > well, I guess it depends on what way you want to preserve things: > > > > 1. Rebase the fedora-infrastructure.git on top of ansible.git and force > > push that. That would mean everyone with a existing > > fedora-infrastructure repo would have to scrap it and repull. > > But everyone with fedora-infra/ansible.git could just pull. > > > > 2. Push ansible.git on top of fedora-infrastructure. Then the opposite. > > People who have an existing fedora-infrastructure repo could just pull, > > people with fedora-infra/ansible would need to recheckout. > > > > 3. Just scrap the fedora-infrastructure repo entirely and replace it > > with ansible.git. This would mean both groups would have to reclone. > > > > I don't think there's really enough people with checkouts that couldn't > > just reclone, so I think we could do anything here and I don't much > > care. I think we should probibly move the old fedora-infrastructre files > > under some directory to keep them cluttering the ansible repo tho. > > > > Most if not all the fedora-infrastructure.git is old stuff we could do > > without too. > > Use the force Luke, no! Never force push :-) did this really happen? It did not, you're all good. We're still figuring this out and haven't started on merging the two repos yet. > It means that all the links from outside world pointing to specific > ansible.git hashes are just pointing to nowhere now... > > If anything, the repositories should be merged together with > --allow-unrelated histories or something (so all the objects stay > available). I never seen that in practice, but I never seen force push in > such important git repo so far, either. :-( This sounds like an interesting idea, I'll look into it Thanks! Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: Mirror the ansible repo from pagure in the batcave
On Thu, Apr 23, 2020 at 01:36:48PM -0700, Kevin Fenzi wrote: > On Thu, Apr 23, 2020 at 11:46:25AM +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > Kevin and I had a discussion on IRC the other day about mirroring the > > ansible > > repo. > > The options we considered are: > ...snip... > > > > For a first step I went with a third approach: a small python service that > > runs every 3 minutes (configurable): git fetch && git fsck (to ensure the > > git > > is in a correct state). It actually doesn't run every 3 minutes, it calls > > git, > > then wait for 3 minutes then calls git again and so on. So if git was > > ever to > > takes 4 minutes to run, there is no risk of the program stepping on its > > own > > toes. > > ok. > > I'm wondering if that might be overkill. > > Really if pagure.io blows up, we want to be able to look at the repo we > have on batcave01 and be able to still operate while we recover > pagure.io. If someone pushed or merged some commits in between the last > time we synced and blowup, someone should have them in their local repo > right? so we could just push them to the repo on batcave and be back > completly in sync, no? Someone will have the commits sure, but since it's a PR, you could be merging a couple of commits from me while I am asleep. If pagure goes down right after the merge, you will not have the commits on your fork and batcave may not have synced them, leading to these commits not being accessible. This isn't a situation we couldn't recover from, but one of the two repos will need to get a force-push once they are both available again. > but I guess it doesn't hurt to do every 3minutes, just some BW. I think the fedora-messaging client would reduce the BW usage, and I think I have it ready, so we may be able to go with it from the start. > Another option I mentioned the other day when we were talking, but I > didnt really explain well was that we could wrap ansible-playbook into a > wrapper that runs a git pull then ansible-playbook... so it would always > be in sync at first you run it. That could be messy tho if there's > another process doing pulls, etc. So I guess scrap that idea. > > > I would like to propose that install and configure this for a test. > > I propose that we keep /git/ansible.git as is and just have a > > /git/mirrors/ansible.git which will be the mirror from pagure. > > We can migrate the hook from /git/ansible.git to /git/mirrors/ansible.git so > > /srv/web/infra/ansible (ie: the exploded tree) is coming from the mirror. > > I think that could be confusing. If we switch we should switch and make > all the old checkouts no longer work for pushing, or we are going to > cause a lot of confusion. I'd say move the old one to some .back name > and chmod 000 it. Works for me, I was thinking to keep it as some sort of backup that would be updated hourly or so and thus would give us a little breathing room in case of disaster (quickly diagnosed). I'm ok with your approach that the breathing room gained may be overkilled there (the chances that we diagnose an issue and think about stopping the service while we're trying to debug the issue and that the service hasn't synced in the mean time seems... low). > Also, there is the question about the existing git repo for > fedora-infrastructure on pagure. It has stuff in it now. Do we > completely replace it with the current ansible repo? Or do we stream all > the ansible commits on top of it so current checkouts would just be able > to pull? Or do we put it on another project. I'd really prefer to have > it on the same project our tickets are to avoid confusion. I kinda think > it might be nice to stream it on top of the existing repo so it's not > broken, but not sure how long or messy that would be. I was going for: https://pagure.io/Fedora-Infra/ansible/ which is marked as being the future location of our ansible repo and already has a copy of it. I had not realized we have content in https://pagure.io/fedora-infrastructure/ 's git. If we really want to have the ansible repo in that repo, the easiest may be to rebase these commits on the top of ansible and force push to that repo (so current ansible clone would pull fine once they've updated their urls=). > > I guess the lag time to get /git/mirrors updated will quickly be annoying > > (up to > > 3 minutes between when the PR is merged and when the playbook is updated), > > so > > if we like the workflow we will likely want to switch pretty quickly to a > > message-based service and then we could keep the current cron-like service > > to > > run hourly and update /git/ansible.git which would then become some kind of &
Re: Mirror the ansible repo from pagure in the batcave
On Thu, Apr 23, 2020 at 11:18:15AM -0400, Todd Zullinger wrote: > Hi, > > Pierre-Yves Chibon wrote: > > For a first step I went with a third approach: a small python service that > > runs every 3 minutes (configurable): git fetch && git fsck (to ensure the > > git > > is in a correct state). > > You could likely set transfer.fsckObjects¹ and skip the > secondary git fsck call. > > The transfer.fsckObjects option will check objects as they > are pulled in via fetch (or git-receive-pack). The option > is available with git-1.8.3.1 in RHEL 7 that is currently > installed on batcave. > > That could be set in the repo config or via git -c for just > the invocation in your script. > > Here's the docs from the current git release: > > > https://git-scm.com/docs/git-config#Documentation/git-config.txt-transferfsckObjects > > I don't know whether all of the later improvements to catch > malicious objects are backported to the RHEL 7 version or > not. Some aren't relevant due to the features which allow > for the malicious behaviors not being available in that > version of git. But the core of the check is still present > and should handle the "fsck on fetch" portion. Details are > in git-config(1). > > ¹ or fetch.transferObjects Nice! Thanks, I'll look into this. Pierre signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: OIDC testing
On Thu, Apr 23, 2020 at 05:59:10PM +0300, Benson Muite wrote: > Hi, > > Does one need to request anything other than client secrets through an > infrastructure Pagure issue to be able to test application authentication with > > https://iddev.fedorainfracloud.org/ For this instance you can self-register yourself, it is not even needed to request a client secret. Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
[FBR] fix openshift
Good Morning Everyone, This morning as I was trying to build a new distgit-bugzilla-sync build in staging, I ran into the issue that the build never started. It seems it was related to openshift not being able to resolve correctly: registry.redhat.io. Once Clément pointed me to the right direction, I adjusted staging as follow: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=e371f8b0ceef30639facb7ac7a70c27beb3e689c and I was able to do a new build. I would like to apply the same fix to production (ie: roles/hosts/files/os-hosts). Thoughts? Thanks, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Mirror the ansible repo from pagure in the batcave
Good Morning Everyone, Kevin and I had a discussion on IRC the other day about mirroring the ansible repo. The options we considered are: - mirroring to pagure - mirroring from pagure - using pagure's mirroring feature - using a different approach - Mirroring to pagure This meant, the canonical place for ansible remains in the batcave and pagure only periodically pulls from there to update itself (or a hook updates pagure on push). This would work, but it basically make the pull-request workflow for reviewers a little more complex, as you would have to download the patch of the PR, apply it (potentially adding the: Merging so it marks the PR as merged) and then push to the batcave. If you merged via the UI in pagure, you would then have to pull from pagure and then push to the batcave, with the risk of a race condition if someone or something updates pagure right after your merge and suddenly the commit(s) of the PR disapear (since the content in pagure would be overriden by what is coming from the batcave). So, not an ideal workflow. - Mirroring from pagure This means, the canonical place for ansible is in pagure.io. However, we need to still be able to run ansible when pagure.io goes down (keeping in mind batcave and pagure.io are in two different data-center). So we want to keep a mirror of the ansible repo in the batcave for emergencies and that repo should be as up to date as possible. With this approach, all the work happens on pagure.io, the PR workflow is the usual, straight forward one and we have a mirror in the batcave that is mostly up to date. - Using pagure's mirroring feature Pagure can mirror in and out, out is done right after a push, however, batcave is not accessible from pagure.io, so we just can't use this. - Using a different approach We have two ways we could do this: a simple cron job, a message-based service. For a first step I went with a third approach: a small python service that runs every 3 minutes (configurable): git fetch && git fsck (to ensure the git is in a correct state). It actually doesn't run every 3 minutes, it calls git, then wait for 3 minutes then calls git again and so on. So if git was ever to takes 4 minutes to run, there is no risk of the program stepping on its own toes. I would like to propose that install and configure this for a test. I propose that we keep /git/ansible.git as is and just have a /git/mirrors/ansible.git which will be the mirror from pagure. We can migrate the hook from /git/ansible.git to /git/mirrors/ansible.git so /srv/web/infra/ansible (ie: the exploded tree) is coming from the mirror. I guess the lag time to get /git/mirrors updated will quickly be annoying (up to 3 minutes between when the PR is merged and when the playbook is updated), so if we like the workflow we will likely want to switch pretty quickly to a message-based service and then we could keep the current cron-like service to run hourly and update /git/ansible.git which would then become some kind of backup. What do you think? FBR worthy? (ie: if F32 goes out next week, I think we can wait, if it doesn't do we want to try this sooner?) If we like the idea, I'll start looking into the fedora-messaging based consumer, using the approach from the current service, it should be pretty straight forward (I'll re-use the same project for it). Oh, and if you want to see the code of the current service: https://pagure.io/Fedora-Infra/mirror_from_pagure Thanks, Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: [FBR] Retire in bugzilla package retired in Fedora
On Wed, Apr 22, 2020 at 11:38:46AM -0700, Adam Williamson wrote: > On Wed, 2020-04-22 at 20:14 +0200, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > > > I believe this is not frozen but in doubt I'm still asking it :) > > > > I would like to deploy a new build of distgit-bugzilla-sync (running in > > openshift) to include this pull-request: > > https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/48 > > which basically blocks in bugzilla packages that are retired in Fedora. > > > > This fixes https://pagure.io/fedora-infrastructure/issue/7639 > > > > Thoughts? > > Does it account for branches? i.e. it should only retire things in > Bugzilla if they're retired on *all* current branches, it shouldn't > e.g. retire a package that's not retired on F30. I have just double checked and yes, it checks if the package is active/retired on all branches stored in PDC. So if it's retired in master and active on F30, it will consider the package active. Thanks for checking on this :) Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
Re: [PATCH] docs-translation-update: change cron to run at 22 instead of 2. Fixes ticket 8847.
On Wed, Apr 22, 2020 at 10:08:40PM +, Kevin Fenzi wrote: > Per ticket 8847, moving this cron job to 10pm will let it run and finish > before the larger > and longer cron script runs to update the docs site. This will prevent > overlap and get > updates out a day sooner in some cases. > > Signed-off-by: Kevin Fenzi > --- > roles/fedora-docs/translation/files/cron-docs-translation-update | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/roles/fedora-docs/translation/files/cron-docs-translation-update > b/roles/fedora-docs/translation/files/cron-docs-translation-update > index bf91755..5a0627b 100644 > --- a/roles/fedora-docs/translation/files/cron-docs-translation-update > +++ b/roles/fedora-docs/translation/files/cron-docs-translation-update > @@ -1,2 +1,2 @@ > MAILTO=jibecfed > -0 2 * * * _update_docs_trans /usr/local/bin/lock-wrapper > cron-docs-translation-update "/usr/local/bin/docs-translation-update" > +0 22 * * * _update_docs_trans /usr/local/bin/lock-wrapper > cron-docs-translation-update "/usr/local/bin/docs-translation-update" +1 Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@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/infrastructure@lists.fedoraproject.org
