staging openshift upgrade tomorrow, prod later this week
by Kevin Fenzi
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
5 years, 8 months
fedora messaging
by Michal Novotny
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
5 years, 8 months
Meeting Agenda Item: Introduction JD Wilson
by JD Wilson
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
5 years, 8 months
MirrorManager 29 redirects removed
by Adrian Reber
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
5 years, 8 months
Zchunk status update
by Jonathan Dieter
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
5 years, 8 months
[PATCH] bodhi-pungi: prevent NVR conflicts for image builds
by Dusty Mabe
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
5 years, 8 months
