As previously announced, I plan to held classroom lesson.
Mark your calendar:
11th May 2005
#fedora-classroom on irc.freenode.net
15:00 UTC (that is 17:00 CET, 11:00 EDT)
The lesson is intended primary for Fedora Infrastructure members (or
I will try to cover following topics:
* what is Fedora Cloud (spoiler: our OpenStack instance)
* which machines are used
* where is the documentation
* where are the playbooks and which files are important and where it is
stored in ansible.git
* which services are enabled and why
* how they are installed
* where are the weak parts, where you must be careful
I've been talking to Paul and various other folks about investigating
the use of some of the new tools that are out there these days (atomic,
docker, containers in general, even cloud really) in Fedora
I'd like to schedule a brainstorming session next week sometime for
interested parties to get together and talk about this area and how we
might be able to use some of the new tools in our infrastructure.
In this session we will discuss what absolute requirements we have for
production and non production and nice to haves and such. Also,
hopefully we can decide on something to use as a pilot so we can make
something and see what the actual problems are.
I've created a whenisgood for this:
If you are interested, please fill out your name, timezone and when you
can meet. This meeting will take place on IRC, channel to be announced
when we have a time. :)
I am Esteban, Fedora Ambassador for Paraguay, and contributing to the
translation team L10n (trans_es) and team leader of trans_GN. I would like
to bring to the team, in professional work and 12 years as a Sysadmin linux.
*Esteban A. Ruiz Diaz*
ownCloud Insider / VOIPSA THREAT TAXONOMY / Fedora L10N Project
GPG KeyID = 6EAA05D0
fingerprint = 824B C711 B9F9 D5FA 025A 86F4 00A8 ADE1 6EAA 05D0
So a while back at the bodhi2 fad, Dennis and I setup koji01.stg.
At that time our requirements were:
* Able to test bodhi against it.
* Able to test builds so we could test things like new mock versions,
* Not require constant maint and care, would just mostly keep working.
So, we set things up there to use primary koji repos as 'external
repos'. This means koji01.stg doesn't have all those rpms locally in
it's database or know what versions or tags or anything about them, it
just knows that when it wants to build say a 'f22' package it pulls the
external repo from primary in to build with.
% koji list-external-repos
External repo name URL
This also means it doesn't need to do newrepo tasks all the time, only
when it builds something locally. This also meant it didn't need much
storage, since all it would have is any small number of local builds.
Bodhi test pushes would be small and quick because it would only handle
the locally built packages.
Fast forward to today...
We now would like to add some requirements I think. What are they? :)
Do we need to do rawhide/branched composes? Daily?
Do we need to be able to do run-pungi (RC/TC) test composes?
Lets find out our requirements before we adjust things.
It's my understanding (Dennis please correct if I'm wrong) that the
problem with cloud image creation was due to libvirt iptables rules
being lost when iptables was restarted. This is a fundamental known
issue (see last paragraph of <http://libvirt.org/firewall.html>), and
one of the things firewalld was meant to solve.
Dennis says that there are lot of complicated rules on the builders
making switching to firewalld difficult. One possibility might be to
move those complicated rules from the builders to a network firewall,
and keep the host rules simple and functional. But that's probably a
In the meantime, any time iptables is restarted or reloaded, libvirt
needs a SIGHUP. (I suppose this means: ansible playbooks and also added
to any manual procedures.)
[cc rel-eng, reply-to infrastructure]
Fedora Project Leader
Long story short:
I declare new Fedora Cloud as final.
There is still lot of work, but that will be always the case. Please use it (but hold on production things for few days
in case there will be some problem).
I plan to announce Fedora classroom date for those interrested in setup of that OpenStack.
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
Recently stage koji was having some issues and it turned out the
that local storage had the wrong selinux fcontext since it's not a nfs
mount as it is in production koji. I fixed it by hand for the time
being just to test (with nirik's approval) and wanted to be sure and
submit a patch to make it persistent.
One thing to note is that I haven't tested this sicne I don't
currently have permissions to rbac-playbook and am not in
sysadmin-main, but I have a relative level of confidence that it
Questions, comments, and snide remarks welcome. :)
diff --git a/roles/koji_hub/tasks/main.yml b/roles/koji_hub/tasks/main.yml
index 3839564..0b5642f 100644
@@ -206,6 +206,24 @@
+- name: check selinux default context for /mnt/fedora_koji in staging
+ command: matchpathcon /mnt/fedora_koji
+ register: mnt_fedora_koji_context
+ when: env == "staging"
+ always_run: yes
+ changed_when: "1 != 1"
+ - koji_hub
+ - selinux
+- name: /mnt/fedora_koji selinux file context
+ command: semanage fcontext -a -t httpd_sys_rw_content_t
+ when: env == "staging" and
+ mnt_fedora_koji_context.stdout.find('httpd_sys_rw_content_t') == -1
+ - koji_hub
+ - selinux
- name: set sebooleans so koji can talk to the db
seboolean: name=httpd_can_network_connect_db state=true persistent=true
I'm working on https://github.com/abrt/abrt-ansible for the purpose of
completely managing retrace* machines with ansible.
Ansible scripts for faf deployment are mostly ready and I would like to
use these to provision unused retrace02 machine and when this is done
switch retrace.fedoraproject.org to point to retrace02 instead of retrace01.
Is anyone willing to take a brief look at mentioned recipes and point me
in the right direction? In particular, what can/should be reused from
fedora infra ansible and what should be improved in current recipes.
The infrastructure team will be having it's weekly meeting tomorrow,
2015-04-30 at 18:00 UTC in #fedora-meeting on the freenode network.
This week we are continuing to try something new.
We have a gobby document
(see: https://fedoraproject.org/wiki/Gobby )
fedora-infrastructure-meeting-next is the document.
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 this
morning 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 =
This shared document is for the next fedora infrastructure meeting.
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 (2015-04-30)
#chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch threebean pingou puiterwijk
#topic New folks introductions / Apprentice feedback
= Status / information / Trivia / Announcements =
(We put things here we want others on the team to know, but don't need to discuss)
(Please use #info <the thing> - your name)
#topic announcements and information
#info New fedmsg messages from retrace.fedoraproject.org are on the staging bus. Should go to production early next week. - ralph
#info Slow and steady progress on the fedmenu initiative: https://fedoraproject.org/w/index.php?title=Infrastructure/FY16_frontend - ralph
#info python3 release of python-fedora forthcoming - ralph
#info MailMan3 has been released!! Congrats abompard and all the MailMan team -- pingou
#info new nuancier release, mostly bug fix and fedmenu -- pingou
#info new elections release, mostly bug fix and fedmenu -- pingou
#info new fedocal release, mostly bug fix and fedmenu -- pingou
#info fedmenu integration on: planet, wiki, review status, paste -- :tada: :cake: threebean && pingou :cake: :tada:
#info koschei is now in staging. Need some more setup, but it's there - kevin
#info fas in staging had a blowup. Please re-enroll any totp 2fa tokens - kevin
#info secondary sigul has been reinstalled with rhel7/ansible - kevin
#info Going to be a brainstorming session about using new tools in infra next week - kevin
= 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 or 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)
#topic What are we going to do about meetbot (whither supybot)? - threebean
#topic Mirrormanager2 status roundup, can we deploy soon? - kevin
= 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 improvement,
etc. Whoever would like to do this, just add the info in this section. In the
event we don't find someone to teach about something, we skip this section
and just skip to open floor.)
#topic Learn about: pkgs.fedoraproject.org, our dist-git server - patrick
= Meeting end stuff =
#topic Open Floor