infrastructure June 2017

infrastructure@lists.fedoraproject.org

41 participants
56 discussions

Fwd: [ansible] Add sfo-korg-mirror.kernel.org to tier1
by Nick Bebout 28 Jun '17

28 Jun '17

Retroactive FBR please? nirik and smooge know about it on IRC, but I guess I should get +1's for the record. Also we will need to run groups/download.yml ---------- Forwarded message ---------- From: Nick Bebout <nb(a)fedoraproject.org> Date: Wed, Jun 28, 2017 at 3:22 PM Subject: [ansible] Add sfo-korg-mirror.kernel.org to tier1 To: sysadmin-members(a)fedoraproject.org This is the public repository, do not commit sensitive or confidential information here. X-Git-Refname: refs/heads/master X-Git-Oldrev: b61f63fb4e36f4380380b9c4fe68682b6557d383 X-Git-Newrev: 9d1c06bba1ea7d3004689dd4f402b7833d893be6 commit 9d1c06bba1ea7d3004689dd4f402b7833d893be6 Author: Nick Bebout <nb(a)batcave01.phx2.fedoraproject.org> Date: Wed Jun 28 20:21:50 2017 +0000 Add sfo-korg-mirror.kernel.org to tier1 inventory/group_vars/download | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/inventory/group_vars/download b/inventory/group_vars/download index 640a283..713b3cc 100644 --- a/inventory/group_vars/download +++ b/inventory/group_vars/download @@ -50,11 +50,11 @@ dl_tier1: - mirrors.xmission.com # 198.60.22.13 - odysseus.fi.muni.cz # 147.251.48.205 - odysseus.linux.cz # 147.251.48.205 - - pao-korg-mirror.kernel.org # 149.20.4.68 - rhlx01.hs-esslingen.de # 129.143.116.10 - rsyncer.ftp.heanet.ie # 193.1.219.88 - sagres.c3sl.ufpr.br # 200.236.31.1 - scrye.com # 75.148.32.185 + - sfo-korg-mirror.kernel.org # 149.20.37.36 / 2001:4f8:4:6f:0:1994:3:14 - sinclair.wpi.edu # 130.215.32.86 - solar-one.mit.edu # 18.7.29.123 - speculum.rbc.ru # 80.68.250.217

3 2

Code reviews are hard
by Randy Barlow 28 Jun '17

28 Jun '17

Hello fellow Fedorans! As you are probably aware, we have a rule (unspoken? Not sure if it's formally documented or not) that pull requests in the infrastructure group should be reviewed by another infra member before they are merged. This is a sound policy in my mind, but I've been thinking about a problem that I've observed that I don't have a solution to. When I review pull requests that other people write against Bodhi, I am able to give much higher quality feedback than I am when I review pull requests on our other projects, simply because I spend a lot of time in the Bodhi code and am aware of how a lot of it works. For example, I might suggest "hey, there's a function over in bodhi.server.util that does what you are doing here - why not use that instead?". However, when I review code in other projects I am much more limited since I don't know the code for all of our projects very deeply. Mostly, I can only make generic comments, or maybe offer some Python hints here and there. I don't actually have any proposal of what should change here. I think reviewing code is good, and I think we should keep doing it. I just wanted to share an observation I've made when I review code. If anyone has any ideas on how we could improve this I'd love to hear. Maybe it's a problem without a solution, but it can't hurt to think about it together a bit just in case there are some good ideas out there ☺

3 5

Requesting Feedback: Logging solution for loopabull
by Adam Miller 27 Jun '17

27 Jun '17

Hello all, I am in need of a publicly accessible location to have logs hosted (or mirrored) from loopabull[0] in order to provide public-facing feedback on what's actually going on with the automated tasks. For background/context, there are docs what loopabull is[0] and how Fedora RelEng is currently aiming to use it[1][2]. If it's acceptable, I would like to use OpenStack's Project ARA[3] for this but that is "yet another service" and if there's something readily available from the Fedora Infrastructure then I'd certainly like to go that route. I'm also completely open to alternative solutions, whatever the Fedora Infrastructure Team thinks it best. Thank you, -AdamM [0] - https://github.com/maxamillion/loopabull [1] - https://pagure.io/releng-automation [2] - https://pagure.io/releng/pull-request/6804#request_diff [3] - https://github.com/openstack/ara

3 10

the-new-hotness-0.9.1
by Jeremy Cline 26 Jun '17

26 Jun '17

Hey all, the-new-hotness v0.9.1 has been released and is now running in production. 0.9.0 had bugs so it never made it to production. The changelogs for both 0.9.0 and 0.9.1 are included below: 0.9.1 ----- Bugfixes ^^^^^^^^ * Errors are actually reported when subprocess commands fail * Fix compatibility with python-bugzilla-2.1+ 0.9.0 ----- Features ^^^^^^^^ - Detect Anitya backend using package name prefix (#172) - pypi.org has been added to the Anitya backend mapping dictionary (#173) - SRPM build failures now report details to the user (#178) Bugfixes ^^^^^^^^ - Fix a grammatical error in an error message (#175) Many thanks to the contributors for this release! -- Jeremy Cline XMPP: jeremy(a)jcline.org IRC: jcline

1 0

Weekly Koji Infra Tag Report
by Nobody 25 Jun '17

25 Jun '17

This is a list of packages in the various infrastructure koji tags Please check and make sure there are not any that can be removed/dropped epel6-infra (no matching packages) epel7-infra Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- pkgdb2 epel7-infra pingou freeipa-ktutils epel7-infra puiterwijk compose-utils epel7-infra ausil fedmsg-beaker-repoupdate epel7-infra tflink anitya epel7-infra jcline the-new-hotness epel7-infra jcline fedocal epel7-infra pingou python-IPy epel7-infra kevin python-robosignatory epel7-infra puiterwijk pdc-updater epel7-infra ralph python-pdc epel7-infra ralph glusterfs epel7-infra kevin kerneltest epel7-infra pingou mirrormanager2 epel7-infra puiterwijk blockerbugs epel7-infra tflink python-django-jsonfield epel7-infra ralph f23-infra Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- libphutil, f23-infra tflink arcanist, f23-infra tflink phabricator f23-infra tflink phabricator-extension-ipsilonauth f23-infra tflink libphutil f23-infra tflink arcanist f23-infra tflink f24-infra Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- mediawiki-openid f24-infra kevin phabricator-extension-oauth f24-infra tflink python-twill f24-infra codeblock stickynotes2modernpaste f24-infra codeblock python-flask-testing f24-infra codeblock modern-paste f24-infra codeblock mediawiki-skin-fedora f24-infra puiterwijk mediawiki-FedoraBadges f24-infra kevin basset f24-infra puiterwijk phabricator f24-infra tflink mediawiki-Lockdown f24-infra kevin libphutil f24-infra tflink arcanist f24-infra tflink mediawiki-RSS f24-infra kevin mirrormanager2 f24-infra puiterwijk f25-infra Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- python-flask-testing f25-infra codeblock modern-paste f25-infra codeblock python-coveralls f25-infra codeblock mdapi f25-infra pingou basset f25-infra puiterwijk mediawiki-FedoraBadges f25-infra kevin mediawiki-Lockdown f25-infra kevin mediawiki-RSS f25-infra kevin mediawiki-openid f25-infra kevin plus-plus-service f25-infra pingou python-pdc f25-infra ralph python-django-cors-headers f25-infra ralph python-django-rest-framework-composed-permissions f25-infra ralph patternfly1 f25-infra ralph piwik f25-infra codeblock fas f25-infra kevin libphutil, f25-infra tflink arcanist, f25-infra tflink phabricator f25-infra tflink phabricator-extension-ipsilonauth f25-infra tflink libphutil f25-infra tflink arcanist f25-infra tflink python-twill f25-infra codeblock stickynotes2modernpaste f25-infra codeblock mediawiki-skin-fedora f25-infra kevin f26-infra Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- piwik f26-infra codeblock f27-infra Package Tag Extra Arches Owner ----------------------- ----------------------- ---------------- --------------- piwik f27-infra codeblock

1 0

The Future of the Fedora Layered Image Build System's OpenShift Deployment
by Adam Miller 24 Jun '17

24 Jun '17

Hello all, I wanted to bring up the topic of the future of Fedora's Layered Image Build System (FLIBS) as it pertains to OpenShift as a backend technology that FLIBS is built on top of. TL;DR - Does anyone care if we move FLIBS to be run on OpenShift Container Platform instead of OpenShift Origin in the future? OpenShift itself comes in two forms. The first is the upstream OpenShift Origin which is very rapidly releasing which has no official support for older releases (no N-1 support), so it would require a fresh roll out every three months. The second is the Red Hat OpenShift Container Platform which is the productized version based on OpenShift Origin, follows a slower release cadence, and offers longer life support per release than Origin. I would like to note for the sake of posterity for the mailing list thread that both of these are Open Source. I outline these points in order to ask if there is any preference from the Fedora Infrastructure Team on which "edition" of OpenShift that FLIBS is built on top of in the future. I ask this because currently FLIBS is built on OpenShift Origin which has already proven difficult to keep up with latest releases since I'm currently the only one working on FLIBS and it's not the only thing I am actively working on at any one point in time and I would like to move to OpenShift Container Platform in the future. Thank you, -AdamM

5 8

Hello world
by martydoc9＠gmail.com 23 Jun '17

23 Jun '17

Hi, new here... Is this a spin on Fedora coin? Tips??

2 1

Outage of Build Systems 2017-06-24 16:00 UTC
by Stephen John Smoogen 23 Jun '17

23 Jun '17

There will be an outage starting at 2017-06-24 16:00UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2017-06-24 16:00 UTC Reason for outage: There have been some performance problems with the backend switches. These need an update from juniper and a reboot and possible debugging. Affected Services: pkgs.fedoraproject.org koji koshei kojipkgs pkgdb bodhi / updates mdapi service Services not listed are not affected by this outage. Contact Information: Ticket Link: https://pagure.io/fedora-infrastructure/issue/6131 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen.

1 0

What hostgroup name should I use to monitor the regsitry CDN?
by Randy Barlow 23 Jun '17

23 Jun '17

Hello! I'm new to Nagios. Will this patch work for monitoring cdn.registry.fedoraproject.org, which lives completely outside our network? I basically just copy/pasted this from the code that appears to monitor our proxies, but I wasn't sure what to put on the hostgroup_name since this isn't really our proxy (so that's probably wrong in the below patch). Thoughts? diff --git a/roles/nagios_server/templates/nagios/services/websites.cfg.j2 b/roles/nagios_server/templates/nagios/services/websites.cfg.j2 index ab137a7..386472b 100644 --- a/roles/nagios_server/templates/nagios/services/websites.cfg.j2 +++ b/roles/nagios_server/templates/nagios/services/websites.cfg.j2 @@ -73,6 +73,14 @@ define service { use websitetemplate } +define service { + hostgroup_name proxies + service_description http-moby-registry-cdn + check_command check_website_ssl!cdn.registry.fedoraproject.org!/v2/!{} + max_check_attempts 8 + use websitetemplate +} + ## ## Individual hosts

2 3

RFC: Enable type annotations and Mypy checks on Python projects in Fedora Infrastructure
by Kushal Das 22 Jun '17

22 Jun '17

Hi everyone, RFC: Enable type annotations and Mypy checks on Python projects in Fedora Infrastructure We have many Python applications under Fedora Infrastructure, and we also on a path to move to the Python3 world. I am proposing the following changes for our Python applications: * Add type annotations in any new code we write. * Add type annotations in code we change * Enable Mypy checks for every pull requests and commits in CI. * During Flock we try to enable type annotations in our favorite Python applications. ## What is Type Annotation This is a feature of Python3, also backported to the Python2 world using the python2-typing module. Type annotations or type hints are purely for external type checking tools, they do not affect the Python interpreter anyway. PEP-484 discusses more on the type hints [1]. ## Example (which works in both Python2 and Python3) def add(a, b): # type: (int, int) -> int "Adds two numbers" return a + b ## What is Mypy? Mypy [2] is an open source type checking tool, most of the developers are in Dropbox. Mypy can be used on a codebase gradually, means we don't have to add all the type information in one go. We can slowly keep improving the type annotations. ## What are benefits of enable type annotations and Mypy? ### Readability of the code Because of the checks, we will always have right data types mentioned, which increases the readability of the code a lot for any future maintainer. ### Finding actual logical bugs There are times when we have functions which generally returns a boolean, but it some corner cases, maybe it returns an empty string or None value. These may cause runtime errors. Using Mypy on your codebase improves the chances of finding any such issue in the development cycle only. ### Refactoring becomes easier As the tool itself checks for all of the API use cases, refactoring larger codebases will be easier with Mypy. ## Which are the few big projects using Mypy? Dropbox has around 700K lines of Python code, and Zulip project has around 100K of Python with type information. They also have an excellent blog post at [3]. [1] https://www.python.org/dev/peps/pep-0484/ [2] http://mypy.readthedocs.io/en/latest/ [3] http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/ Kushal -- Fedora Cloud Engineer CPython Core Developer https://kushaldas.in https://dgplug.org

6 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure June 2017