infrastructure August 2018

infrastructure@lists.fedoraproject.org

25 participants
51 discussions

staging openshift upgrade tomorrow, prod later this week
by Kevin Fenzi 21 Aug '18

21 Aug '18

I'm going to look at updating our staging openshift cluster to 1.10. If things don't go nicely, I'll just reinstall it fresh. I'd like to upgrade things in prod later in the week (probably thursday if staging goes ok wed). If anyone has concerns with timing or the like, please let me know... kevin

1 0

fedora messaging
by Michal Novotny 21 Aug '18

21 Aug '18

So I got to know on the flock that fedmsg is going to be replaced? Anyway, it seems that there is an idea to create schemas for the messages and distribute them in packages? And those python packages need to be present on producer as well as consumer? > JSON schemas > Message bodies are JSON objects, that adhere to a schema. Message schemas live in their own Python package, so they can be installed on the producer and on the consumer. Could we instead just send the message schemas together with the message content always? I would like to be able to parse any message I receive without some additional packages installed. If I am about to start listening to a new message type, I don't want to spend time to be looking up what i should install to make it work. It should just work. Requiring to have some packages with schemas installed on consumer and having to maintain them by the producer does not seem that great idea. Mainly because one of the raising requirements for fedmsg was that it should be made a generic messaging framework easily usable outside of Fedora Infrastructure. We should make it easy for anyone outside to be able to listen and understand our messages so that they can react to them. Needing to have some python packages installed (how are they going to be distributed PyPI + fedora ?) seems to be just an unnecessary hassle. So can we send a schema with each message as documentation and validation of the message itself? a) it will make our life easier b) it will allow people outside of Fedora (that e.g. also don't tend to use python) to consume our messages easily c) what if I am doing a ruby app, not python app, do I need then provide ruby schema as well as python schema? What if a consumer is a ruby app? We should only need to write a consumer and producer parts in different languages. The message schemes should not be bound to a particular language, otherwise we are just adding us more work when somebody wants to use the messaging system in another language than python. clime

2 10

[Fedocal] Reminder meeting : Infra Office Hours
by cverna＠fedoraproject.org 20 Aug '18

20 Aug '18

Dear all, You are kindly invited to the meeting: Infra Office Hours on 2018-08-21 from 18:00:00 to 19:00:00 UTC At fedora-admin(a)irc.freenode.net The meeting will be about: Weekly hour dedicated to answer questions or help people with fixing tickets or implementing features. Source: https://apps.fedoraproject.org/calendar/meeting/9255/

1 0

libravatar in Fedora OpenShift
by Michal Novotny 18 Aug '18

18 Aug '18

Hello, I would like to ask if anyone is willing to sponsor running libravatar ( https://git.linux-kernel.at/oliver/ivatar) in Fedora OpenShift per https://docs.pagure.org/infra-docs/sysadmin-guide/sops/requestforresources.…. I think we could use the automatic deployment options that OpenShift offers (Git update -> OpenShift pod update) to our advantage. OpenShift is also the platform where the current development instance runs http://ivatar-ivatar.1d35.starter-us-east-1.openshiftapps.com/. Thank you clime

2 2

Meeting Agenda Item: Introduction JD Wilson
by JD Wilson 18 Aug '18

18 Aug '18

Hello, world! My name is JD Wilson. I am in the USA, Eastern Time Zone. I am a database developer/DBA with prior experience in both desktop and full stack web development. My main focus these days is SQL, though I have worked with PHP, Java, HTML, and JQuery among others. I aim to script and automate everything I can, so I have been working to improve my bash and Powershell skills. I am MCP certified, hoping to get my MCSA in Database Development later this year. While I work in a Microsoft shop, I have previous experience with Sybase and MySQL, and I am always willing to get hands-on experience with a new DBMS. I am also willing to learn Python since it seems to be used extensively in the Fedora ecosystem. I like to get my hands dirty whenever and wherever I can, and I strive to be flexible as far as which specific languages or technologies I'm using. I've wanted to contribute to Linux since I first began using it years ago, I just never knew how. The openness of the Fedora project to volunteers is what made me choose it over Ubuntu years ago. I knew that one day I would be writing an email like this, and to be honest it feels weird that I'm finally here. Time flies! I feel I am useful enough as a professional to make a difference in the Fedora community. I love the idea of open source software and I am ready to "walk the walk", to contribute to the success of Fedora rather than just stand on the shoulders of others. I don't just want to use Fedora, I want to help build it! I would like to contribute to the back end database work for Fedora. A potential first issue I noticed while looking at https://pagure.io/fedora-infrastructure/issues is the sluggish behavior when I click different tags to filter the results. The first tag or two do not make a big difference, but the third+ tags create long wait times. This performance behavior seems isolated to this part of the infrastructure page. My first blind guess is that the query bringing back the issue list is doing a table scan. Maybe an index is too fragmented and is being ignored, maybe it never existed to begin with. Either way, I'm not seeing this performance hit when looking at the other pages like "Commits" or "Files" so I don't believe it to be an issue with pagure.io as a whole, but rather how it is returning the records in the "issues" page. I understand any hesitation to let a stranger gain access to the database, so I'm open to just about anything that can get my foot in the door and let me prove my worth. I've taken a multi-faceted approach to my career path, and I'm comfortable wearing many hats. I'm positive we can find something for me to work on! I can pretty easily contribute 2-4 hours a week to start, and I would be willing to ramp it up as I get more involved with the team. My IRC handle is JD_Wilson. Look forward to meeting you all, JD

1 0

MirrorManager 29 redirects removed
by Adrian Reber 16 Aug '18

16 Aug '18

Now that MirrorManager detected the newly created Fedora 29 repositories, I removed the repository redirects from 29 to rawhide and I added new redirects from 30 to rawhide. Adrian

2 2

[PATCH] twoweek-nightly: Stop building F28 AH twoweek nightly composes
by Sinny Kumari 16 Aug '18

16 Aug '18

We are building Fedora 28 AH nightly artifacts during F28 bodhi-updates run which produces same media name what we get during twoweek nightly [1] compose run. This patch (available in attachment) stops running cron job for twoweek nightly compose for F28. This will also help us to avoid NVR conflict [2] which may occur during image build from twoweek composes and updates run because they both can have same NVR. [1] https://kojipkgs.fedoraproject.org/compose/twoweek/ [2] https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapr… https://pagure.io/dusty/failed-composes/issue/636 -- http://sinny.io/

3 3

Zchunk status update
by Jonathan Dieter 16 Aug '18

16 Aug '18

So, after Flock, I figured it might be time for a zchunk status update. First off, there's no way we're going to have the zchunked metadata feature ready for Fedora 29, so we're pushing the feature back to Fedora 30. The one thing I *would* like to have ready for Fedora 29 is the actual metadata creation, even if we don't have anything ready to consume it quite yet. The idea behind this is that, if the metadata is being generated, people can easily opt in to test the feature. After some discussion on the rpm-ecosystem ML, I've restructured createrepo_c so the zchunk metadata is in separate repomd.xml records (with a -zck suffix) from the normal xml metadata. The latest build in https://copr.fedorainfracloud.org/co prs/jdieter/zchunk/packages/ has all the necessary changes and is built against the official Fedora zchunk libraries (as opposed to a COPR version). Apparently COPR is struggling with Rawhide after branching, so the current createrepo_c build is available in EPEL-7, Fedora 27 and Fedora 28. I've also written a small script, available in the zchunk/contrib directory that will generate an appropriate dictionary given a few input files. I'm going to be experimenting to see what gives us the most efficient dictionaries and then document SOP for generating dictionaries in Fedora. After much discussion at Flock, it seems that the best way to make this work is to have a fedora-repos-dicts package that contains the dictionaries for all active Fedora releases. Currently, the main thing I'm waiting on is for https://github.com/rpm-software-management/createrepo_c/pull/92 to finish being reviewed and then pulled. Jonathan

1 0

Staging Koji sync
by Mikolaj Izdebski 16 Aug '18

16 Aug '18

Tomorrow (Friday August 17) around 16:00 UTC I would like to start sync staging Koji with production to fix issues like [1]. Does anyone have any objections? [1] https://pagure.io/fedora-infrastructure/issue/7136 -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk

1 0

[PATCH] bodhi-pungi: prevent NVR conflicts for image builds
by Dusty Mabe 15 Aug '18

15 Aug '18

Use a different version string for the updates vs updates-testing so that NVRs don't conflict. --- roles/bodhi2/backend/templates/pungi.rpm.conf.j2 | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 index fd1e775a3..4ef0c6115 100644 --- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 +++ b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 @@ -203,7 +203,11 @@ image_build = { 'image-build': { 'format': [('qcow2', 'qcow2'), ('raw-xz', 'raw.xz')], 'name': 'Fedora-AtomicHost', - 'version': '!VERSION_FROM_VERSION' + [% if request.name == 'stable' %] + # Use a different version string for the updates vs updates-testing + # runs so that NVRs don't conflict + 'version': '!VERSION_FROM_VERSION' + [% endif %] 'release': '!RELEASE_FROM_DATE_RESPIN' 'kickstart': 'fedora-atomic.ks', 'distro': 'Fedora-22', @@ -225,7 +229,11 @@ image_build = { 'image-build': { 'format': [('vagrant-libvirt','vagrant-libvirt.box'), ('vagrant-virtualbox','vagrant-virtualbox.box')], 'name': 'Fedora-AtomicHost-Vagrant', - 'version': '!VERSION_FROM_VERSION' + [% if request.name == 'stable' %] + # Use a different version string for the updates vs updates-testing + # runs so that NVRs don't conflict + 'version': '!VERSION_FROM_VERSION' + [% endif %] 'release': '!RELEASE_FROM_DATE_RESPIN' 'kickstart': 'fedora-atomic-vagrant.ks', 'distro': 'Fedora-22', -- 2.14.4

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure August 2018