[release] mirrormanager2 0.0.6
by Pierre-Yves Chibon
Hi all,
I have just released and push to the infra repo a new version of mirrormanager:
0.0.6
Here is its changelog:
* Wed Mar 18 2015 Pierre-Yves Chibon <pingou(a)pingoured.fr> - 0.0.6-1
- Update to 0.0.6
- Drop the Locations in the hosts (no longer used)
- Add unit-tests
- To the frontend
- To some of the backend scripts
- Add dependency to python-IPy
- Fix ExecStart instruction for systemd
- Fix apache configuration file for mirrorlist
- Fix host selection logic in the crawler (Adrian Reber)
- Log the rsync command (Adrian Reber)
- Add the possibility to specify the rsync argument via the configuration file
(Adrian Reber)
- Add and install a tempfile.d file for systemd to re-create
/var/run/mirrormanager upon reboot
Hopefully it'll run smoothly, otherwise, you know where to find me :)
Pierre
9 years, 1 month
[Fwd: mirror.root.lu causing consistent hangs?]
by Ankur Sinha
Bad mirror report from -devel?
-------- Forwarded Message --------
From: Richard Z
<snip>
Subject: mirror.root.lu causing consistent hangs?
Date: Wed, 18 Mar 2015 12:52:23 +0100
Hi,
yesterday and today this mirror caused yum to hang for
indefinite periods of time (waited over two minutes),
only c-c helps.
Richard
<snip>
9 years, 1 month
OOM killer on bapp02 again
by Adrian Reber
I know that MirrorManager2 will be coming but I just saw that there were
multiple crawler process killed on bapp02.
I also see in (at least) one of the crawler logs (1995-stderr.log-20150312.gz):
File "/usr/lib/python2.6/site-packages/sqlobject/postgres/pgconnection.py", line 115, in makeConnection
raise self.module.OperationalError("%s; used connection string %r" % (e, self.dsn))
psycopg2.OperationalError: FATAL: the database system is shutting down
; used connection string 'dbname=mirrormanager user=mirroradmin password=password host=db-mirrormanager port=5432'
It also seems that the DB password is in the log file in cleartext.
Currently there is also crawler which takes 1.2 GB instead of the normal 200MB.
This might also be a reason for the OOMs:
441 20633 5.2 8.0 1296468 1285924 ? S 13:00 3:37 /usr/bin/python /usr/share/mirrormanager/server/crawler_perhost -c /etc/mirrormanager/prod.cfg --hostid 1508 --logfile /var/log/mirrormanager/crawler/1508.log
Adrian
9 years, 1 month
Routing between tenants networks
by Miroslav Suchý
Quick note for those interested in new OpenStack instance:
Routing between two tenants is apparently not possible. Or to be precise
I did not discovered how to do that (and even Larsks did not know).
However ... we can mark same network as "shared". This means that those
networks are visible for all tenants and tenants can assign IP from this
network to their VMs. So you can route two VM of two different tenants,
but they must be with the same network.
So I had two option hows to set up Copr network:
1) put copr-be in copr-net network, but copr-be will be owned by
infrastructure tenant or
2) we can give copr-be two NICs. One with IP from infrastructure network
(with floatingIP mapped to this IP) and second NIC with IP from copr
network. This way copr-be will be able to route builders using private
IP. And we keep others VM (e.g. signer) quite isolated.
The option 2 seems much better to me, therefore I'm going this way.
I already tested it and it really works.
So conclusion is that "copr-net" and "coprdev-net" will be visible to
all tenants. And while you technically can put machines in that network,
you should not do that as those networks are reserved for production and
staging instances of Copr builders.
Mirek
--
,,,
(o o)
=================================oOO==(_)==OOo===========
) mailto:miroslav@suchy.cz tel:+420-603-775737
( One picture is worth 128K words.
)________________________________________Oooo.____________
.oooO ( )
( ) ) /
\ ( (_/
\_)
9 years, 1 month
Routing between tenants networks
by xsuchy
Quick note for those interested in new OpenStack instance:
Routing between two tenants is apparently not possible. Or to be precise
I did not discovered how to do that (and even Larsks did not know).
However ... we can mark same network as "shared". This means that those
networks are visible for all tenants and tenants can assign IP from this
network to their VMs. So you can route two VM of two different tenants,
but they must be with the same network.
So I had two option hows to set up Copr network:
1) put copr-be in copr-net network, but copr-be will be owned by
infrastructure tenant or
2) we can give copr-be two NICs. One with IP from infrastructure network
(with floatingIP mapped to this IP) and second NIC with IP from copr
network. This way copr-be will be able to route builders using private
IP. And we keep others VM (e.g. signer) quite isolated.
The option 2 seems much better to me, therefore I'm going this way.
I already tested it and it really works.
So conclusion is that "copr-net" and "coprdev-net" will be visible to
all tenants. And while you technically can put machines in that network,
you should not do that as those networks are reserved for production and
staging instances of Copr builders.
Mirek
--
,,,
(o o)
=================================oOO==(_)==OOo===========
) mailto:miroslav@suchy.cz tel:+420-603-775737
( One picture is worth 128K words.
)________________________________________Oooo.____________
.oooO ( )
( ) ) /
\ ( (_/
\_)
9 years, 1 month
Prototyping Fedora widgets framework
by Ratnadeep Debnath
Hi all,
As discussed over IRC, I am working on prototyping a framework to
power generic widgets for Fedora. This framework will allow writing
widgets for Fedora in Python, mostly.
Basic components
==============
Dispatcher
----------------
Dispatcher is part of a daemon process which keeps on listening to
fedmsg messages and invoking widgets to save data as needed. Widgets
can be tied to the dispatcher using signals, observer patterns, etc.
Widget
----------
I define a widget implementation as a standalone entity which knows:
1. How to handle raw fedmsg data, format it and save it for enabling
faster query
2. Render data from saved data.
API
------
Provide REST interface to fetch data from a widget for a particular
entity, say, badges info for a user for UserBadgesWidget.
I have started working on a prototype based on the Observer design
pattern here[1].
Please provide your feedback on the same. I am also thinking to work
on a prototype based on signals, to see which prototype allows us to
expose friendly interfaces for writing widgets.
[1]: https://github.com/rtnpro/fedwidgets/blob/master/fedwidgets/prototypes/ob...
Regards,
rtnpro
--
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6
9 years, 1 month
FBR: Add a new icon for fedimg
by Ralph Bean
Tiny freezebreak request here. We want to add a new icon for fedimg
with the following patch:
diff --git a/roles/apps-fp-o/files/img/icons/fedimg.png b/roles/apps-fp-o/files/img/icons/fedimg.png
new file mode 100644
index 0000000..2cc02f0
Binary files /dev/null and b/roles/apps-fp-o/files/img/icons/fedimg.png differ
diff --git a/roles/apps-fp-o/tasks/main.yml b/roles/apps-fp-o/tasks/main.yml
index 948d74c..e4a5d5b 100644
--- a/roles/apps-fp-o/tasks/main.yml
+++ b/roles/apps-fp-o/tasks/main.yml
@@ -28,3 +28,8 @@
- restart httpd
tags:
- apps-fp-o
+
+- name: Copy over any extra icons we carry
+ sync: src=img/icons dest=/srv/web/apps-fp-o/img/icons
+ tags:
+ - apps-fp-o
9 years, 1 month
nagios change
by Kevin Fenzi
Greetings.
I just made a nagios change that causes it to send the very first alert
for something to _just_ irc.
If you are active and looking at a problem at this point, please go and
ack it on the web interface. This will stop escalations.
It will then wait 10minutes and the next alert (if the problem hasn't
recovered or been acked) will go to irc, email and pagers.
It will then send every hour after that to irc, email, and pager until
the problem is acked or solved.
Rationale:
* Much of the time now we have someone on irc who can look at and fix
issues (since we have sysadmin main folks in europe). Paging everyone
is causing pager fatigue especially when someone else is already
fixing it.
* We get a lot of alerts that are short network caused things that
recover in a few minutes. There's usually 0 we can do about them, our
users never notice them, and it's causing pager fatigue to page on
them and then immediately page ok after bothering people. Ideally we
would adjust these checks, and we should, but it's going to take a
while to get them all right.
* We often get a lot of alerts from 1 proxy or the like being rebooted
or restarting apache. These usually only happen for a minute or two
and there's no need to page on them.
* We sometimes get alerts directly related to changes we are currently
making in something and then go fix them. There's no need to page
someone for this, just be aware of irc when making playbook or host
changes and clean up anything you cause to alert.
I'd like to get back to the idea that if you get a page it's an
important thing you need to go look at, not "oh, nagios again".
This is all subject to adjustment, but hopefully it will make life a
bit easier for us sysadmin types and not cause any problems for anyone
else. ;)
kevin
9 years, 1 month