The infrastructure team will be having its weekly meeting tomorrow,
2019-04-04 at 15:00 UTC in #fedora-meeting-1 on the freenode network.
We have a gobby document at
which can be edited for the agenda (see: https://fedoraproject.org/wiki/Gobby )
Please try and review and edit that document before the meeting and we
will use it to have our agenda of things to discuss. A copy as of today
is included in this email.
If you have something to discuss, add the topic to the discussion area
with your name. If you would like to teach other folks about some
application or setup in our infrastructure, please add that topic and
your name to the learn about section.
= Introduction =
We will use it over the week before the meeting to gather status and info and
discussion items and so forth, then use it in the irc meeting to transfer
information to the meetbot logs.
= Meeting start stuff =
#startmeeting Infrastructure (2019-04-04)
#chair nirik pingou puiterwijk relrod smooge tflink cverna mizdebsk
mkonecny abompard bowlofeggs
= Let new people say hello =
#topic New folks introductions
#info This is a place where people who are interested in Fedora
Infrastructure can introduce themselves
#info Getting Started Guide:
= Status / Information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need
(Please use #info <the thing> - your name)
#topic announcements and information
#info Beta Freeze Is Finished.
#info Final Freeze Starts on 2019-04-16
= Things we should discuss =
We use this section to bring up discussion topics. Things we want to talk about
as a group and come up with some consensus /suor decision or just brainstorm a
problem or issue. If there are none of these we skip this section.
(Use #topic your discussion topic - your username)
#info smooge is on call from 2019-04-04 -> 2019-04-11
#info ????? is on call from 2019-04-11 -> 2019-04-18
#info ????? is on call from 2019-04-18 -> 2019-04-25
#info Summary of last week: (from relrod )
#topic Monitoring discussion
#info Go over existing out items and fix
#topic Tickets discussion
Go thru each ticket one by one
#topic Priorities for next week?
#info please put tickets needing to be focused on here
Put all topics for discussion under here
= Apprentice office hours =
#topic Apprentice Open office minutes
#info A time where apprentices may ask for help or look at problems.
Here we will discuss any apprentice questions, try and match up people looking
for things to do with things to do, progress, testing anything like that.
= Learn about some application or setup in infrastructure =
(This section, each week we get 1 person to talk about an application or setup
that we have. Just going over what it is, how to contribute, ideas for
etc. Whoever would like to do this, just add the i/nfo in this section. In the
event we don't find someone to teach about something, we skip this section
and just move on to open floor.)
= Meeting end stuff =
#topic Open Floor
Stephen J Smoogen.
we are now in the infrastructure freeze leading up to the Fedora 30
Beta release. This is a pre release freeze.
We do this to ensure that our infrastructure is stable and ready to
release the Fedora 30 Beta 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:
ansible/scripts/freezelist -i inventory
Any hosts listed as freezes is frozen until 2019-03-26 (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.
it is my pleasure to announce that Pavel Raiskup (praiskup) joined the Copr team. Pavel has been contributing to Copr
for long time in his free time. He has been maintaining Red Hat internal Copr instance for long time. Now, he is joining
Copr team as his full time job. Pavel replaced Michal Novotny (clime) who left Red Hat and as result you may see Clime
less on IRC during working hours.
FEDORA-CONTAINER-2019-3e42a55b54 references a container that has
been deleted from the candidate registry. As a result, the compose has
failed. Since the update is locked, it cannot be edited to replace it
with a build that exists. To fix this, I propose to unlock the update
$ sudo -u apache bodhi-shell
2019-04-02 15:24:43,617 INFO [bodhi.server][MainThread] Bodhi ready and at your service!
Python 3.7.2 (default, Mar 21 2019, 10:09:12)
[GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux
Type "help" for more information.
app The WSGI application.
registry Active Pyramid registry.
request Active request object.
root Root of the default resource tree.
root_factory Default root factory used to create `root`.
>>> u = m.Update.query.filter_by(alias='FEDORA-CONTAINER-2019-3e42a55b54').one()
>>> u.locked = False
After this, I will use the Bodhi web UI to swap the build for fedora-
I dont know if this FBR is needed or not, but now that we have a GOLD
compose for F30 Beta and all the requested f30 builds pushed stable and I
cloned f30-Beta tag from f30, now we can start pushing updates to F30
stable as well along with the others.
diff --git a/vars/all/RelEngFrozen.yaml b/vars/all/RelEngFrozen.yaml
index bd7553f..72af779 100644
@@ -1 +1 @@
fedora-packages  code base is showing its age. The code base and
the technology stack (Turbogears2  web framework and the Moksha
 middleware) is currently not ready for Python3 and I am not
planning to do the work required to make it Python3 compatible, so the
application will stop working when Fedora 29 is EOL.
In order to keep the service running, I have started a Proof Of
Concept (fedora-search ) to replace the backend of the application.
Fedora-search would be a REST API service offering full test search
API. Such a service would then be available for other application to
use, fedora-packages would then become a frontend only application
using the service provided by fedora-search.
While the POC shows that this is a viable solution, I don't think that
we should be proceeding that way, for the simple reason that this add
yet another code base to maintain, I think we should use this
opportunity to consider using Elasticsearch instead of maintaining our
own "search engine".
I think that Elasticsearch offers quite a few advantages :
- Powerful Query language
- Python bindings
- Can be deployed in our infrastructure or used as a service
- Can be useful for other applications ( docs.fp.o, pagure, ??)
So what is the general feeling about using Elasticsearch in our
infrastructure ? Should we look at deploying a cluster in our infra /
Should we approach the Council to see if we can get founding to have
this service hosted by Elastic ?
 - https://apps.fedoraproject.org/packages/
 - http://www.turbogears.org/
 - https://mokshaproject.github.io/mokshaproject.net/
 - https://github.com/fedora-infra/fedora-search