April 2019 - infrastructure - Fedora Mailing-Lists

by Pierre-Yves Chibon

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

4 days, 21 hours

11
14
3 / 0

Re: Deprecating Autocloud

by Sinny Kumari

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/

1 year, 4 months

5
11
0 / 0

Deployment of plume in Fedora Infrastructure

by Sayan Chowdhury

Hi all, Over the last few months, I was working on integrating Fedora as a sub-system to plume. This is to migrate from fedimg to plume, and finally deprecating plume. The work on plume has been completed and over the next few days, I prepare for the deployment of plume. I've prepared a spec document for the same[1]. I plan to move this to Fedora wiki in some time but if someone wants to do a review can have a look at it and post comments. [1] https://hackmd.io/fpDWrtuJT7-jt8jy2yJC1Q?view -- Sayan Chowdhury <https://words.yudocaa.in/> GPG Fingerprint : 0F16 E841 E517 225C 7D13 AB3C B023 9931 9CD0 5C8B

1 year, 11 months

3
4
0 / 0

Fedora 30 Final Freeze now in effect!

by Kevin Fenzi

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

1 year, 11 months

1
1
0 / 0

[[FBR] Freeze Break Request: ] dns: add 2 rh nameservers that make a lot of legit queries against our dns.

by kevin＠scrye.com

From: Kevin Fenzi <kevin(a)scrye.com> Signed-off-by: Kevin Fenzi <kevin(a)scrye.com> --- roles/dns/files/named.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/roles/dns/files/named.conf b/roles/dns/files/named.conf index df539bf..c13d65e 100644 --- a/roles/dns/files/named.conf +++ b/roles/dns/files/named.conf @@ -20,7 +20,7 @@ acl "everyone-v4" { 0.0.0.0/0; }; acl "everyone-v6" { ::0/0; }; acl "everyone" { 0.0.0.0/0; ::0/0; }; // -acl "ns_redhat" { 66.187.233.210; 209.132.183.2; 66.187.229.10; }; +acl "ns_redhat" { 66.187.233.210; 209.132.183.22; 209.132.183.30; 209.132.183.2; 66.187.229.10; }; // acl "phx2net" { 10.4.124.128/25; 10.5.78.0/24; 10.5.79.0/24; 10.5.125.0/24; 10.5.126.0/24; 10.5.127.0/24; 10.5.128.0/24; 10.5.129.0/24; 10.5.130.0/24; 10.16.0.0/24; }; acl "rdu2net" { 172.31.1.0/24; 172.31.2.0/24; }; -- 1.8.3.1

1 year, 11 months

4
3
0 / 0

[[FBR] Freeze Break Request: ] dns: Actually drop the limit on the group we defined in the last commit.

by kevin＠scrye.com

From: Kevin Fenzi <kevin(a)scrye.com> Signed-off-by: Kevin Fenzi <kevin(a)scrye.com> --- roles/dns/files/named.conf | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/roles/dns/files/named.conf b/roles/dns/files/named.conf index c13d65e..e210088 100644 --- a/roles/dns/files/named.conf +++ b/roles/dns/files/named.conf @@ -574,6 +574,10 @@ view "RDU2" { view "NA" { match-clients { US; CA; MX; }; recursion no; + // no rate-limit on internal requests + rate-limit { + exempt-clients { ns_redhat; }; + }; zone "fedoraproject.org" { type master; file "/var/named/master/built/NA/fedoraproject.org.signed"; -- 1.8.3.1

1 year, 11 months

4
3
0 / 0

old taiga instances

by Kevin Fenzi

Greetings. We have 2 old taiga instances: taiga.fedorainfracloud.org and taiga-stg.fedorainfracloud.org. Last week I disabled nginx on them so they aren't serving anything. Next week I would like to retire them both completely. My understanding is that any active users have moved to the new teams instance. If there's something you need from them, let me know in the next week before I retire them. Thanks, kevin

1 year, 11 months

6
14
0 / 0

Backwards incompatible updates to Fedora 29

by Randy Barlow

Hi Pavla, I noticed today that a backwards incompatible update was pushed to Fedora 29 stable for libdnf[0]. This breaks Bodhi[1], which uses hawkey.Repo which was removed in that version. The update notes did not mention a backwards incompatible API, and in general backwards incompatible updates should not be pushed to stable Fedora versions[2]. This causes problems for Fedora users who may be using your library, but it also causes issues in this case for the Fedora Infrastructure team[3]. Please do not push backwards incompatible updates in the future. That said, we now need to take some action to solve the problem. Ideally, we would revert the libdnf in Fedora 29 since that update should not have happened. I also noticed the Fedora 30 does not have this version of libdnf (so, Fedora 29 has the backwards incompatible change, but Fedora 30 does not.) This means that users upgrading from Fedora 28 to Fedora 31 will experience 3 backwards breaking changes, instead of just one (which should happen in Fedora 31 only). Can we revert this change? [0] https://bodhi.fedoraproject.org/updates/FEDORA-2019-2612a121ba [1] https://github.com/fedora-infra/bodhi/issues/3193 [2] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases [3] https://pagure.io/fedora-infrastructure/issue/7748

1 year, 11 months

4
5
0 / 0

Re: Backwards incompatible updates to Fedora 29

by Randy Barlow

On Mon, 2019-04-29 at 21:46 +0200, Daniel Mach wrote: > I'll discuss the issue with my team and we will reach back to > you with a solution soon. Thanks Daniel!

1 year, 11 months

1
0
0 / 0

FBR: update libtaskotron on production taskotron workers

by Tim Flink

It turns out that we've been getting rpmlintrc files from the cgit interface over dist-git which went away earlier this week. As a consequence, package-specific rpmlintrc files are not being used anymore. The fix itself is simple: https://pagure.io/taskotron/libtaskotron/c/0e0c12a5dd6255ad44a123e1ed1287... We've already done a release and made builds in koji. I'd like to upgrade the production workers so that per-package rpmlintrc files start working again. https://koji.fedoraproject.org/koji/buildinfo?buildID=1254705 Tim

1 year, 11 months

3
3
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure April 2019