August 2015 - infrastructure - Fedora mailing-lists

bodhi2 plans
by Kevin Fenzi 10 Aug '15

10 Aug '15

Greetings. So, in the releng meeting last week we discussed about landing bodhi2 before the alpha freeze started, however there were just too many things still up in the air to do that, so we held off. However, I'd like to propose a concrete date to enable it and try and make sure we have everything we need lined up for making that work. :) My understanding of the current status: (Luke: please correct me if anything is wrong or unclear here) * We have bodhi2 web frontend up and running fine in staging: https://admin.stg.fedoraproject.org/updates/ (well, right now it's down as Luke is working on a update id bug there and is repopulating the db, but it was and will be up again soon). * We have a bodhi2 backend up in staging and it's successfully mashed updates pushes. * bodhi2 isn't yet packaged in Fedora (it and it's deps are in a copr): http://copr.fedoraproject.org/coprs/lmacken/bodhi2/ So, to get that last bit we need: * API users. I thought we had a list somewhere, but I cannot seem to find it. At least fedora-easy-karma and fedora-gooey-karma use it. Are all of these using python-fedora for the api? Do we need to update that and bodhi-client? * We need bodhi2 in fedora/epel. Were we going to do it as a seperate package, or just an update to the existing 'bodhi' package. I assume maintainers would need the new client to do 'fedpkg update' ? * Do we need any fedpkg changes? Or anything else? How do we want to handle the switchover? * Is taskotron all ready to go with bodhi2? or more changes there? * We will need an outage to switch over. I assume the bodhi1->bodhi2 db conversion shouldn't take too long? But once we convert and make live we are commmited. * Anything else I missed? I'd like to propose we schedule the switchover/outage for 2015-08-19. (Provided alpha doesn't slip). This will allow us a few days to recover from flock and get anything lined up we need to. Thoughts? additions? kevin

3 3

Freeze Break Request - fedmsg authz policy
by Ralph Bean 07 Aug '15

07 Aug '15

I found a bug! The impact of it is that the releng primary arch 'compose' fedmsg messages were being considered invalid by our consuming services (ircbot, etc..) but the s390 compose messages were being let through. First -- here's the patch, then the explanation: diff --git a/inventory/host_vars/branched-composer.phx2.fedoraproject.org b/inventory/host_vars/branched-composer.phx2.fedoraproject.org index bfe9b94..a5d3514 100644 --- a/inventory/host_vars/branched-composer.phx2.fedoraproject.org +++ b/inventory/host_vars/branched-composer.phx2.fedoraproject.org @@ -7,12 +7,3 @@ volgroup: /dev/vg_bvirthost08 kojipkgs_url: kojipkgs.fedoraproject.org kojihub_url: koji.fedoraproject.org/kojihub kojihub_scheme: https - -# These are consumed by a task in roles/fedmsg/base/main.yml -fedmsg_certs: -- service: shell - owner: root - group: root -- service: bodhi - owner: root - group: masher diff --git a/inventory/host_vars/rawhide-composer.phx2.fedoraproject.org b/inventory/host_vars/rawhide-composer.phx2.fedoraproject.org index a0d17a6..9cb3409 100644 --- a/inventory/host_vars/rawhide-composer.phx2.fedoraproject.org +++ b/inventory/host_vars/rawhide-composer.phx2.fedoraproject.org @@ -6,12 +6,3 @@ volgroup: /dev/vg_bvirthost06 kojipkgs_url: kojipkgs.fedoraproject.org kojihub_url: koji.fedoraproject.org/kojihub kojihub_scheme: https - -# These are consumed by a task in roles/fedmsg/base/main.yml -fedmsg_certs: -- service: shell - owner: root - group: root -- service: bodhi - owner: root - group: masher It is just *removing* lines from the host_vars files for rawhide-composer and branched-composer. But why? First, those fedmsg_certs vars are already defined at the group_vars level here: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/inventory/gr… That more fully-defined and correct statement at the group level was being overwritten by the less fully defined statements at the host level (see ansible var precedence rules). Everything appeared to be working normally while this was the case because, since no hosts declared that they could send those fedmsg topics there was no explicit check for who could send them. It didn't matter until we added the s390 koji hub a week or so ago which is allowed to broadcast those same topics. It had its fedmsg_certs correctly defined, and since it declared that it could send those topics -- and no other hosts made the same declarations -- the primary compose messages suddenly started being considered invalid (unauthorized). By removing these old crufty definitions at the host level and letting the correct definition at the group level prevail -- all those hosts should show up correctly in the fedmsg authz policy and things should start working again. This will require a master playbook run on just the fedmsgdconfig tag to push out making this a "high touch" change to do during freeze, but I'm quite certain it is correct. Can I get two +1s? -Ralph

3 2

RE: Move to mailman3
by Sander Hoentjen 07 Aug '15

07 Aug '15

Hey yeah I figured as much, haven't touched my procmailrc for as long as I can remember :) Will go fix it now. -----Original message----- From: Aurelien Bompard <abompard(a)fedoraproject.org> Sent: Friday 7th August 2015 20:18 To: Fedora Infrastructure <infrastructure(a)lists.fedoraproject.org> Subject: Re: Move to mailman3 > And for me things show up in my inbox instead of in a folder, because I > filter on X-BeenThere. This disappeared, not sure if it counts as a > regression though :) If I understand correctly, the X-BeenThere header has been obsoleted some time ago (read: years ;-)), you can now filter on List-Id or List-Post. https://bugs.launchpad.net/mailman/+bug/883158 Sorry for the trouble, that's clearly something to warn people of. Aurélien

1 0

RE: Move to mailman3
by Sander Hoentjen 07 Aug '15

07 Aug '15

And for me things show up in my inbox instead of in a folder, because I filter on X-BeenThere. This disappeared, not sure if it counts as a regression though :) Sander -----Original message----- From: Michael Cronenworth <mike(a)cchtml.com> Sent: Friday 7th August 2015 19:42 To: infrastructure(a)lists.fedoraproject.org Subject: Re: Move to mailman3 On 08/07/2015 12:37 PM, Aurelien Bompard wrote: >> Might be an idea to send one when you start the migration as well :] >> Just that we are not surprised or that we watch if one of our email doesn't land >> on the list. > > Yeah, that would have been a good idea, but it's too late: your > message was processed by Mailman3 already ;-) > https://lists.fedoraproject.org/archives/list/infrastructure%40lists.fedora… > > I'm currently checking for bugs & regressions, feel free to ping me :-) > > Aurélien > Did you use an old subscription list? I have not been subscribed to @infra for about a month and today I start receiving these from you guys. Performing the unsubscribe process again does not send me a confirmation e-mail.

3 2

Time to work on a Plan: Moving VM's
by Stephen John Smoogen 07 Aug '15

07 Aug '15

We have new hardware in to replace some of our 4+ year old IBM x3650's and need to do so in the next month or so to make sure we have a good list of hardware to go onto extended warranty this fall. I would like to come up with a plan of attack on getting them all moved by September 1st to virthost19->virthost22. Hardware Server Virtual Machine virthost05.phx2.fedoraproject.org bastion02.phx2.fedoraproject.org virthost05.phx2.fedoraproject.org db-fas01.phx2.fedoraproject.org virthost05.phx2.fedoraproject.org proxy01.phx2.fedoraproject.org virthost06.phx2.fedoraproject.org ask01.phx2.fedoraproject.org virthost06.phx2.fedoraproject.org notifs-web02.phx2.fedoraproject.org virthost07.phx2.fedoraproject.org datagrepper02.phx2.fedoraproject.org virthost07.phx2.fedoraproject.org elections01.phx2.fedoraproject.org virthost07.phx2.fedoraproject.org hotness01.phx2.fedoraproject.org virthost07.phx2.fedoraproject.org nuancier01.phx2.fedoraproject.org virthost08.phx2.fedoraproject.org darkserver01.phx2.fedoraproject.org virthost08.phx2.fedoraproject.org ns03.phx2.fedoraproject.org virthost09.phx2.fedoraproject.org busgateway01.phx2.fedoraproject.org virthost09.phx2.fedoraproject.org fedocal01.phx2.fedoraproject.org virthost09.phx2.fedoraproject.org notifs-backend01.phx2.fedoraproject.org virthost09.phx2.fedoraproject.org nuancier02.phx2.fedoraproject.org virthost10.phx2.fedoraproject.org bodhi01.stg.phx2.fedoraproject.org virthost10.phx2.fedoraproject.org bodhi02.stg.phx2.fedoraproject.org virthost10.phx2.fedoraproject.org fas01.stg.phx2.fedoraproject.org virthost10.phx2.fedoraproject.org koji01.stg.phx2.fedoraproject.org virthost10.phx2.fedoraproject.org notifs-web02.stg.phx2.fedoraproject.org virthost10.phx2.fedoraproject.org summershum01.stg.phx2.fedoraproject.org There are a couple of ways we do these transitions. 1) Spin up a new virtual machine with an incremented hostname: Example: a) check to see which ask systems exist. (ask01, ask02) b) create a new virtual machine with an incremented number: ask03 c) ansible the system to be clone of ask01 d) either turn off ask01 and rename ask03 to be ask01 OR d) configure other servers to point to ask03 instead of ask01 e) fix problems as needed f) shutdown and remove ask01. 2) Move virtual machine to another server. a) Schedule a downtime b) Shutdown the server c) network dd the lvm image to other server. d) copy over the /etc/libvirt/qemu/___.xml file over to other server. e) spin up server f) fix problems as needed g) remove files from old server 3) If the image is on an iscsi share versus local disks... a) shutdown the image on server A. b) copy the xml files over to server B. c) get libvirt to see them. d) start the image on server B e) remove the xml files from server A. It looks like none of the servers in question are on the iscsi share so we won't be able to do 3. [Unless there is one or two that are good candidates to be on the iscsi share... then a variant of 2 would be used.] Downtimes except for the fas system will be in the 20 minute range. The fas database might be 1-3 hours due to a 100 GB image to be copied over and the usual 'what we have to reboot that because this was down? WHY?' problems we end up with. Other plans and ideas can be replied to here. -- Stephen J Smoogen.

5 4

[release] pagure: 0.1.22
by Pierre-Yves Chibon 07 Aug '15

07 Aug '15

Hi everyone, I just released a new version of pagure: 0.1.22 Here is its changelog: * Fri Aug 07 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.1.22 - Update to 0.1.22 - Adjust the README to the current state of pagure - Rework how we integrate our custom tags into markdown to avoid the infinite loop we run into once in a while It is currently running in stg and in production, so far no problem :) Thanks, Pierre

1 0

Freeze Break Request - new fedimg release
by Ralph Bean 07 Aug '15

07 Aug '15

We found a bug in fedimg today that is causing all new images to fail to be uploaded to AWS (fedimg is constructing an invalid koji url and so is failing to download the images in the first place). This patch fixes it: https://patch-diff.githubusercontent.com/raw/fedora-infra/fedimg/pull/32.pa… I've cut a new python-fedimg-0.6.2 release and am looking for two +1s to push it out. -Ralph

2 1

Meeting Agenda Item: Introduction Tempanoi
by tempanoi＠openmailbox.org 06 Aug '15

06 Aug '15

Good day: I introduce myself, I've infrastructure projects, I like networks have studied Cisco CCNA, I like the security and my experience in linux is as administrator, little shell programming, Saas cloud service projects with Alcatel Lucent technology. I used linux in mobile telecommunications companies, I made plans for my house: The last one dlna and storage server (fedora server) My interests: Programming, security, and home automation projects (installed on raspberry) and automate homes. My nickname in irc: Tempanoi

1 0

Freeze break request? Pagure update (round 3)
by Pierre-Yves Chibon 06 Aug '15

06 Aug '15

Hi everyone, A few time this week and earlier today, I have received error emails from pagure about markdown going into an infinite loop. Something like: http://fpaste.org/252172/14388640/ Today, it seems to have last for a few minutes since I got 600+ emails for this problem. Restarting apache solved it, until the next hick-up. So I went and rework how we integrate our custom patterns in markdown: https://pagure.io/pagure/pull-request/324 (Note: while I hope this fixes the issue I've seen, since I was never able to replicate it, it's just a hope) That and a change to the README file are the only changes since the last release. With the idea of polishing pagure before flock, I would like to ask your opinion about updating pagure again this week :) Thanks for your time, Pierre

3 2

Plan for tomorrow's Fedora Infrastructure meeting - 2015-08-06
by Kevin Fenzi 05 Aug '15

05 Aug '15

The infrastructure team will be having it's weekly meeting tomorrow, 2015-08-06 at 18:00 UTC in #fedora-meeting on the freenode network. 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 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. kevin -- = 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-08-06) #meetingname infrastructure #topic aloha #chair smooge relrod nirik abadger1999 lmacken dgilmore mdomsch threebean pingou puiterwijk pbrobinson #topic New folks introductions / Apprentice feedback #topic GSoC student update - kushal = 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 NOTICE: There will be no meeting on 2015-08-13 as many people will be at flock - kevin #info fixed easyfix (had a broken dir from sundries move) - kevin #info moved planet to fedoraplanet.org - kevin/til #info fixed qadevel backups (needed to adjust rdiff-backup ) - kevin #info fixed up rsync on s390 hub - kevin #info = 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 TRAC tickets review - p_klos #topic = 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 move on to open floor.) #topic Learn about: = Meeting end stuff = #topic Open Floor #endmeeting

1 0

Freeze Break Request: add robots.txt to public facing taskotron instances
by Tim Flink 05 Aug '15

05 Aug '15

For some reason, yahoo's bot has been hitting our taskotron instance really hard all of a sudden - slowing it down enough to trigger nagios alerts twice this week. There is a robots.txt served by the buildmaster instance but since that isn't at the webroot in our setup, bots may not read it. I'd like to add a robots.txt to the public facing taskotron instances so that we can avoid this in the future. Rendered content of the robots.txt is at the end of this email. I've already deployed the file to taskotron-dev which can be seen at: http://taskotron-dev.fedoraproject.org/robots.txt Proposed content would be at: http://taskotron.stg.fedoraproject.org/robots.txt http://taskotron.fedoraproject.org/robots.txt Tim User-agent: * Disallow: /taskmaster/waterfall Disallow: /taskmaster/builders Disallow: /taskmaster/changes Disallow: /taskmaster/buildslaves Disallow: /taskmaster/schedulers Disallow: /taskmaster/one_line_per_build Disallow: /taskmaster/grid Disallow: /taskmaster/tgrid Disallow: /taskmaster/json

3 3

[FBR] Pagure configuration update
by Pierre-Yves Chibon 05 Aug '15

05 Aug '15

Hi, I have made the change for stg but since this one touches prod I'd like to have a couple of +1: --- roles/pagure/frontend/templates/pagure.cfg | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/roles/pagure/frontend/templates/pagure.cfg b/roles/pagure/frontend/templates/pagure.cfg index c0c7101..a79d697 100644 --- a/roles/pagure/frontend/templates/pagure.cfg +++ b/roles/pagure/frontend/templates/pagure.cfg @@ -48,8 +48,8 @@ DOC_APP_URL = 'https://docs.pagure.org' GIT_URL_SSH = 'ssh://git@stg.pagure.io/' GIT_URL_GIT = 'https://stg.pagure.io/' {% else %} -GIT_URL_SSH = 'git(a)pagure.io' -GIT_URL_GIT = 'https://pagure.io' +GIT_URL_SSH = 'ssh://git@pagure.io/' +GIT_URL_GIT = 'https://pagure.io/' {% endif %} Thanks, Pierre

3 2

Pruning sponsors list
by Paul W. Frields 05 Aug '15

05 Aug '15

Our website includes a sponsor list, e.g.: <https://getfedora.org/en/sponsors> A little digging plus help from Jared Smith showed that Arrival Telecom and Technomonk are no longer sponsoring Fedora service. They each provided DID service back when we ran Fedora Talk. So unless there are objections, I'll trim them from future builds of the website. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com

1 1

Freeze break: add rsyncd to s390 hub
by Kevin Fenzi 05 Aug '15

05 Aug '15

This is needed so the content can be synced over to secondary01 and made live to end users. +1s? diff --git a/playbooks/groups/koji-hub.yml b/playbooks/groups/koji-hub.yml index aaccbca..be1843c 100644 --- a/playbooks/groups/koji-hub.yml +++ b/playbooks/groups/koji-hub.yml @@ -41,6 +41,7 @@ - apache - fedmsg/base - koji_hub + - { role: rsyncd, when: inventory_hostname.startswith('s390') } - { role: koji_builder, when: env == "staging" or inventory_hostname.startswith('s390') } - { role: nfs/server, when: env == "staging" } - { role: keepalived, when: env == "production" and inventory_hostname.startswith('koji') } and a new roles/rsyncd/files/rsyncd.conf.s390-koji01.qa.fedoraproject.org file: pid file = /var/run/rsyncd.pid syslog facility = daemon dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.bz2 *.iso use chroot = false transfer logging = false exclude = .snapshot/ .~tmp~/ /.private/ /.private/** **/.nfs* # For distributing applications [log] comment = Server Logs path = /var/log uid = root gid = root read only = yes hosts allow = 10.5.126.13 192.168.1.59 [fedora-s390] comment = Fedora s390 content path = /mnt/koji/tree/ uid = root gid = root read only = yes hosts allow = 10.5.126.27

3 5

Freeze break request? Pagure update (round 2)
by Pierre-Yves Chibon 05 Aug '15

05 Aug '15

Hi everyone, So there has been some changes to pagure that I would like to push forward, here is the detail: - Make the SSH protocol explicit for the SSH URLs (Till Maas) - Improve/Fix/Rework pagure's documentation - Rework the doc server to make it display what's in the repo directly (so you can directly put there the output of your sphinx build, or your rst/md/text files) - Install properly the post-receive hook on the tickets and requests hooks (hotfixed in prod) - Give proper attribution to the pagure logo to Micah Deen in the documentation As you see, nothing major for the main application, but the change to the doc server and doc integration into the main app would be helpful. Thoughts on pushing this forward? Thanks, Pierre

4 6

[FBR] Pagure configuration change
by Pierre-Yves Chibon 05 Aug '15

05 Aug '15

Hi everyone, I would like to push this patch and run pagure's playbook. All this do is changing the order of the vhost in the apache configuration file (and adds a couple of comments). This will allow to serve the SSL cert for pagure.io by default to client that do not support SNI. This will also fix the milter (the mechanism used to reply to a ticket via email), which is currently hotfix to not check the SSL cert. +1? Thanks, Pierre

3 3

[release] pagure: 0.1.21
by Pierre-Yves Chibon 05 Aug '15

05 Aug '15

Hi everyone, I just released a new version of pagure: 0.1.21. Here is its changelog: * Wed Aug 05 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.1.21 - Update to 0.1.21 - Make SSH protocol explicit for SSH URLs (Till Maas) - Adjust the documentation (layout and content) - Rework the doc server to allow showing html files directly - Fix installing the pagure hook correctly (tickets and requests) - Give proper attribution to the pagure logo to Micah Deen in the documentation - Increase pull request text field lengths to 80 (Till Maas) - Fix who can open a remote PR and the check that the repo allows PR - If there is no commit and no content, it means we didn't find the file: 404 It's currently running in stg and apparently it's doing fine :) Happy testing! Pierre

1 0

Meeting Agenda Item: Introduction Zach Villers
by Zach Villers 04 Aug '15

04 Aug '15

ehlo Infra team, I'm interested in joining the infra group as an apprentice. I recently passed the RHCSA, am semi-proficient in bash-scripting, and am working on learning Python. I would like to learn more about packaging and managing servers. irc handle: aikidouke (Aikido is a martial art, uke is the person that falls down) github mess: https://github.com/Aikidouke Look forward to talking to you all soon! *in case you have a really good memory, I did join and dropped out right away about six months ago. I was way too busy and a little overwhelmed. I have time now to at least come to the meetings and really want to find a way to contribute and learn.*

1 0

Freeze break request: fix backups for qadevel.qa.fedoraproject.org
by Kevin Fenzi 04 Aug '15

04 Aug '15

qadevel.qa.fedoraproject.org uses port 222 for ssh shell access. ansible is happy using port 222 just fine, but rdiff-backup isn't. It uses port 22 by default, and fails. The following patch should fix this issue. +1s? I would apply this, run the backup playbook and then watch tomorrow's backups to confirm they work. If not we could revert this. kevin -- diff --git a/playbooks/rdiff-backup.yml b/playbooks/rdiff-backup.yml index 9accda6..fd9dec7 100644 --- a/playbooks/rdiff-backup.yml +++ b/playbooks/rdiff-backup.yml @@ -20,11 +20,11 @@ tasks: - name: run rdiff-backup hitting all the global targets - local_action: "shell rdiff-backup --create-full-path --print-statistics {{ inventory_hostname }}::{{ item }} /fedora_backups/{{ inventory_hostname }}/`basename {{ item }}` | mail -r sysadmin-backup-members(a)fedoraproject.org -s 'rdiff-backup: {{ inventory_hostname }}:{{ item }}' sysadmin-backup-members(a)fedoraproject.org" + local_action: "shell rdiff-backup --remote-schema 'ssh -p {{ ansible_ssh_port }} -C %s rdiff-backup --server' --create-full-path --print-statistics {{ inventory_hostname }}::{{ item }} /fedora_backups/{{ inventory_hostname }}/`basename {{ item }}` | mail -r sysadmin-backup-members(a)fedoraproject.org -s 'rdiff-backup: {{ inventory_hostname }}:{{ item }}' sysadmin-backup-members(a)fedoraproject.org" with_items: global_backup_targets when: global_backup_targets is defined - name: run rdiff-backup hitting all the host targets - local_action: "shell rdiff-backup --exclude='**git-seed*' --exclude='**git_seed' --exclude='**.snapshot' --create-full-path --print-statistics {{ inventory_hostname }}::{{ item }} /fedora_backups/{{ inventory_hostname }}/`basename {{ item }}` | mail -r sysadmin-backup-members(a)fedoraproject.org -s 'rdiff-backup: {{ inventory_hostname }}:{{ item }}' sysadmin-backup-members(a)fedoraproject.org" + local_action: "shell rdiff-backup --remote-schema 'ssh -p {{ ansible_ssh_port }} -C %s rdiff-backup --server' --exclude='**git-seed*' --exclude='**git_seed' --exclude='**.snapshot' --create-full-path --print-statistics {{ inventory_hostname }}::{{ item }} /fedora_backups/{{ inventory_hostname }}/`basename {{ item }}` | mail -r sysadmin-backup-members(a)fedoraproject.org -s 'rdiff-backup: {{ inventory_hostname }}:{{ item }}' sysadmin-backup-members(a)fedoraproject.org" with_items: host_backup_targets when: host_backup_targets is defined

3 3

Freeze Break Request - give compose fedmsg certs to s390-koji01
by Ralph Bean 03 Aug '15

03 Aug '15

The s390 koji hub was rebuilt and ansibilized shortly before freeze set in. It had a fedmsg_certs dictionary defined in the koji ansible group which gave it the certs it needed for koji stuff, but it was missing an extra cert definition for the compose process it carries out. This patch over writes that original var with a setup specific to the s390 node. Can I get two +1s to push this out? diff --git a/inventory/host_vars/s390-koji01.qa.fedoraproject.org b/inventory/host_vars/s390-koji01.qa.fedoraproject.org index 795fa9f..e355230 100644 --- a/inventory/host_vars/s390-koji01.qa.fedoraproject.org +++ b/inventory/host_vars/s390-koji01.qa.fedoraproject.org @@ -34,3 +34,41 @@ koji_server_url: "http://s390.koji.fedoraproject.org/kojihub" koji_weburl: "http://s390.koji.fedoraproject.org/koji" fedmsg_koji_instance: s390 + +# Overload the fedmsg_certs definition from the ansible koji group, since the +# s390 hub *also* does compose stuff, not just koji stuff. +fedmsg_certs: +- service: shell + owner: root + group: sysadmin +- service: koji + owner: root + group: apache + can_send: + - buildsys.build.state.change + - buildsys.package.list.change + - buildsys.repo.done + - buildsys.repo.init + - buildsys.rpm.sign + - buildsys.tag + - buildsys.task.state.change + - buildsys.untag +- service: bodhi + owner: root + group: masher + can_send: + - compose.branched.complete + - compose.branched.mash.complete + - compose.branched.mash.start + - compose.branched.pungify.complete + - compose.branched.pungify.start + - compose.branched.rsync.complete + - compose.branched.rsync.start + - compose.branched.start + - compose.epelbeta.complete + - compose.rawhide.complete + - compose.rawhide.mash.complete + - compose.rawhide.mash.start + - compose.rawhide.rsync.complete + - compose.rawhide.rsync.start + - compose.rawhide.start

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure August 2015