Fwd: [ansible] Add sfo-korg-mirror.kernel.org to tier1
by Nick Bebout
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
6 years, 9 months
Code reviews are hard
by Randy Barlow
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 ☺
6 years, 9 months
the-new-hotness-0.9.1
by Jeremy Cline
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
6 years, 9 months
Weekly Koji Infra Tag Report
by Nobody
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
6 years, 9 months
The Future of the Fedora Layered Image Build System's OpenShift Deployment
by Adam Miller
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
6 years, 9 months
Hello world
by martydoc9@gmail.com
Hi, new here... Is this a spin on Fedora coin? Tips??
6 years, 9 months
What hostgroup name should I use to monitor the regsitry CDN?
by Randy Barlow
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
6 years, 9 months
RFC: Enable type annotations and Mypy checks on Python projects in
Fedora Infrastructure
by Kushal Das
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 years, 9 months