infrastructure November 2019

infrastructure@lists.fedoraproject.org

34 participants
43 discussions

About JS framework
by Pierre-Yves Chibon 14 Sep '22

14 Sep '22

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

15 19

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

24 Apr '20

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

9 31

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

25 Mar '20

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

3 7

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

17 Mar '20

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

2 3

Infrastructure docs & apps.fp.o
by Timothée Floure 05 Feb '20

05 Feb '20

Hi, I wrote [1] to devel some time ago regarding the deprecation of the apps.fp.o index and plan to move its content to the main docs. Kevin mentionned that it could end up in the infrastructure docs and that the whole should be moved to docs.fp.o at some point. I will take a look at both since I have wanted to play with the new documentation pipeline for a while. I am not the best guy to meddle with the infrastructure doc but I might as well do something useful while playing with antora. Tell me if it's not or if I missed something. I might have something to show you at Flock if I have troubles sleeping in the train. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… See you in Budapest, -- Timothée

5 12

F29 and older instances
by Kevin Fenzi 10 Dec '19

10 Dec '19

Greetings everyone. On 2019-11-26 fedora 29 will go end of life and no longer supported. We still have a number of things that are f29 (or older for various reasons). I'd like everyone to look this over and see if you can't move things to f31 (or at least f30) before the f29 eol. builders: I am working on this, builders right now are mostly f29, but should be all moved before the eol date I hope. openshift apps: modernpaste: fedora-27. :) But I don't think it was ever moved to openshift, so we should delete this. joystick: we should fix this up, I think jdoss was going to take it over? the-new-hotness: can we move to f31? qa-stg01.qa.fedoraproject.org: f24? can we retire? autocloud*: f27, but should die when f29 goes eol (it's only used to test atomic-host). mdadpi: f27, but it moved to openshift, can we clean up the non openshift instances and files please? modernpaste: f27. It goes eol soon, so I guess we just wait notifs-backend: f27. I don't know what to do here. We need a replacement, which we don't have. I'm afraid that upgrading will blow it up, but I guess we could try and rollback? qa-prod01: f27. can we retire? ci-cc-rdu01: f28. Can we retire soon? copr-frontend01/02.stg: f28 and I don't think we need them anymore, can I nuke them? db-qa03: f28. Can we upgrade please? osbs: f28, but I think cverna was moving it to newer? any status? f29's: aarch64-test01/02 - can be redone as f31 anytime composer.stg - should be moved to f31 db-koji01.stg - should be moved to f31 and a prod->stg sync kojipkgs01/02 - I should do these soon to f31, adding to my list. os-proxy01 - I should do this one, on my list packages03/04 - No idea here. Can we upgrade? proxy* - we need to start working on this asap. relepel01 - do we need this one anymore? resultsdb/taskotron - can qa folks upgrade these? old cloud instances: glittergallery-dev: f23, should be nuked fedora-bootstrap: f25, should be nuked waiverdb-dev: f25, still needed? commops: f27, still needed? telegram-irc: ? still needed? copr*stg: f28, can copr folks upgrade? developer: f28, still needed? libravatar: f28, should ask them to move to communishift simple-koji-ci: f29. Can we upgrade to 31? or move it to communishift? I think thats all of them. kevin

5 7

Re: Deprecating Autocloud
by Sinny Kumari 05 Dec '19

05 Dec '19

On Mon, Apr 29, 2019 at 4:47 PM Kamil Paral <kparal(a)redhat.com> wrote: > On Mon, Apr 29, 2019 at 11:39 AM Sinny Kumari <ksinny(a)gmail.com> wrote: > >> >> >> On Wed, Apr 24, 2019 at 12:19 AM Kevin Fenzi <kevin(a)scrye.com> wrote: >> >>> Or could we move f29+ all to whatever is replacing it? (taskotron?) >>> >> >> It will be nice but I am not aware of any other system in place which >> would >> replace checks performed by autocloud. >> >> (CC'ed tflink and kparal) >> Does taskotron provides capability to perform tests on Fedora cloud >> Images like booting images and other basic checks? >> > > Theoretically it is possible using nested virt. However, Taskotron is > going away as well. The replacement is Fedora CI: > https://docs.fedoraproject.org/en-US/ci/ > Thanks kamil! yeah, it doesn't make sense to move to Taskotron if it is going to be deprecated as well. > I recommend to ask in the CI list: > https://lists.fedoraproject.org/archives/list/ci%40lists.fedoraproject.org/ > > It should be possible for them to provide the infrastructure you need. > Hmm, I am not very sure if we should spend time investigating and setting up alternative to autocloud unless we have usecases for long run. Fedora Atomic Host Two Week releases ends with F29 EOL. -- http://sinny.io/

5 11

status.fedoraproject.org
by Miroslav Suchý 04 Dec '19

04 Dec '19

Hi. For long time, I plan to do something about https://status.fedoraproject.org/ I think that manual updates of this page does not reflect the capabilities of these century. My question is: do we want to go SasS way? I found https://www.statusdashboard.com/pricing which would cost us $99 per month. Or we want to maintain it in-house? The code of this specific service is open-source https://github.com/tomalessi/statusdashboard thou there are no commits for past few years. And there are some alternatives like: https://github.com/statusdashboard/statusdashboard -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

3 7

[PATCH] aws-iam-policies: fcos-upload-amis: add ability to DescribeRegions
by Dusty Mabe 03 Dec '19

03 Dec '19

Need this since we recently changed to dynamically detect regions to upload to. See https://github.com/coreos/coreos-assembler/commit/ab3cae5 --- files/aws/iam/policies/fcos-upload-amis.json | 1 + 1 file changed, 1 insertion(+) diff --git a/files/aws/iam/policies/fcos-upload-amis.json b/files/aws/iam/policies/fcos-upload-amis.json index 03999c6b0..266074522 100644 --- a/files/aws/iam/policies/fcos-upload-amis.json +++ b/files/aws/iam/policies/fcos-upload-amis.json @@ -22,6 +22,7 @@ "ec2:DescribeImageAttribute", "ec2:DescribeVolumes", "ec2:CreateSnapshot", + "ec2:DescribeRegions", "ec2:DescribeConversionTasks" ], "Resource": "*" -- 2.20.1

3 5

CPE Weekly: 2019-11-29
by Aoife Moloney 30 Nov '19

30 Nov '19

Hi everyone, Welcome to the CPE team weekly project update mail! Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. Note: This document is currently built from individual reports rolled into a google document which we edit and copy into a final document. We are aware that this causes problems with some email readers, and are working on a method to make this less problematic. High Level Project Updates: Fedora: Rawhide Gating: Bodhi was 5.1 released and is deployed in staging Robosignatory is broken in staging preventing testing much there Application Retirements Elections Elections being moved to Communishift really soon! Stay tuned! Fedocal Still no progress on kanban board last four weeks https://teams.fedoraproject.org/project/fedora-calendar/kanban Jlanda is still hitting permission error in communishift https://pagure.io/fedora-infrastructure/issue/8274 Still working on running local instance Nuancier Benson Muite is now working on OIDC authentication A PR will be created on Github to test if we can see the progress New PR from sebwoj - Porting to Fedora messaging is under review Pastebin Still on track for December 1 modernpaste shutdown GDPR and privacy centric conversations with respect to application handovers have resulted in…..more conversations needed - shock :) CentOS: The team have been testing projects migration from repospanner to locally hosted git repositores on git.dev.centos.org and come back with a migration script/plan to unblock RCM CentOS Stream Scoping meetings are still ongoing Misc Bugzilla sync script has been resolved Email inviting to review its change has been sent New changes to src.fedoraproject.org deployed: Ability to set the anitya monitoring status directly in the UI Ability to adopt orphan (and not retired) packages directly in the UI New changes to Pagure on the horizon: New API endpoint to enable/disable git hooks Ability to set dist-git in the default assignee overrides for bugzilla EPEL 8 modularity Updates can now be created in bodhi staging! We are currently testing pushes/composes We are also testing epel8-playground-modules composes Aarch64 is now racked and networked Koji New koji owner script was debugged Koji client was updated Koji was also patched for the --title option fix Configured migrations from Ansible/Jinja template https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/1 https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/3 https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/11 https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/14 https://pagure.io/Fedora-Infra/distgit-bugzilla-sync/pull-request/16 Various Resolved Issues https://pagure.io/mdapi/pull-request/91 https://github.com/fedora-infra/bodhi/pull/3782 Comments? Suggestions? Feedback? Let Us Know! Have a great weekend! Aoife -- Aoife Moloney Feature Driver Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure November 2019