[Change Request] Spam l10n-admin-members instead.
by Ricky Zhou
The db connection limit errors were our fault, we'll look into those
separately, the rest of the spam should go to l10n-admin-members instead
:-)
---
modules/transifex/templates/00-default.conf.erb | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/modules/transifex/templates/00-default.conf.erb b/modules/transifex/templates/00-default.conf.erb
index 320fec0..067a1d4 100644
--- a/modules/transifex/templates/00-default.conf.erb
+++ b/modules/transifex/templates/00-default.conf.erb
@@ -31,10 +31,7 @@ logging.basicConfig(
)
ADMINS = (
- ('Diego Burigo Zacarao', 'diegobz(a)gmail.com'),
- ('Dimitris Glezos', 'dimitris(a)glezos.com'),
- ('Ignacio Vazquez-Abrams', 'ivazqueznet(a)gmail.com'),
- ('Fedora Admins', 'admin(a)fedoraproject.org'),
+ ('Fedora Admins', 'l10n-admin-members(a)fedoraproject.org'),
)
MANAGERS = ADMINS
--
1.5.5.6
14 years, 7 months
Messaging SIG - proposal for our notification infrastructure
by John (J5) Palmieri
Hey everyone. I put up a proposal[1] that describes a publish/subscribe setup for the infrastructure wide notification system. I haven't quite gotten to the publish side of things because the QMF docs get a little hazy there but the meat of the proposal is there and I wanted to get feedback sooner than later. An event/notification system is important to the work I need to do going forward. I specifically avoided method invocation and properties/statistics as they can be added in a later round if we feel we need them. I do feel statistics might be nice (for instance keeping track of information that is expensive to do via a query but cheap to update based on events) but they are a bonus that we don't need right away.
[1] https://fedoraproject.org/wiki/Messaging_SIG/PublishSubscribeNotification...
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
14 years, 7 months
Need a package added to the compose for F-10 and F-11
by Rich Megginson
The package 389-adminutil is needed to build 389-admin and 389-dsgw, but
I don't want to push out 389-adminutil to stable by itself without the
other 389 packages - I'd like to push out to stable all of the 389
packages at the same time. Therefore, I'd like 389-adminutil added to
the "compose" for F-10 and F-11 so that I can build 389-admin and
389-dsgw on F-10 and F-11.
Thanks.
14 years, 7 months
[Change Request] Don't try to restart iscsi{,d}
by Ricky Zhou
In light of what I just did to xen15, I'd like to make this change so
that puppet never makes the same mistake :-)
---
modules/iscsi-initiator-utils/manifests/init.pp | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/modules/iscsi-initiator-utils/manifests/init.pp b/modules/iscsi-initiator-utils/manifests/init.pp
index 4fbd54c..193b377 100644
--- a/modules/iscsi-initiator-utils/manifests/init.pp
+++ b/modules/iscsi-initiator-utils/manifests/init.pp
@@ -33,7 +33,9 @@ class iscsi-initiator-utils::initiator {
file { '/etc/iscsi/initiatorname.iscsi':
content => template("iscsi-initiator-utils/initiatorname.iscsi.erb"),
require => Package['iscsi-initiator-utils'],
- notify => [Service['iscsi'], Service['iscsid']],
+ # Never, ever notify this service - do any restarts manually
+ # after making sure that nothing is using a disk on iscsi.
+ #notify => [Service['iscsi'], Service['iscsid']],
}
}
--
1.5.5.6
14 years, 7 months
Change request - Convert smolt host table to innodb
by Ricky Zhou
Hi, we've been looking at all the smolt outages recently, and after
looking into it a bit, we'd like to try converting the host table in the
smolt database to InnoDB so that we will get row level locking.
This is a very low impact change, and when we tested in staging, it
caused smolt to stop accepting new submissions for about 20 minutes
(smoltSendProfile will simply time out during that period). If we run
into any issues, we can easily revert back to MyISAM (and doing so took
<5 minutes on staging).
Can I get two +1s for this?
Thanks,
Ricky
14 years, 7 months
xen15 outage - sorry :-(
by Ricky Zhou
Hey, here's a quick report of what just happened on xen15 and its
guests:
At around 3:00 UTC, I saw a puppet error email complaining about an
error on running /sbin/service iscsi start on xen15. I logged onto
xen15 and stupidly ran a /etc/init.d/iscsi restart, realizing what I had
actually done a moment later.
I saw disk errors on the consoles of db2 and relepel1, which were on
iscsi. At this point, I tried to shut all iscsi guests on that machine
down (db2, relepel1, sign-bridge1) with xm shutdown. db2 and relepel1
both finished shutting down, but I had to xm destroy sign-bridge1 as it
hung at the end.
After all guests were down, I followed the Logging Out procedure at
https://fedoraproject.org/wiki/ISCSI_Infrastructure_SOP, ran
/etc/init.d/iscsi restart, then followed the Logging In procedure.
At that point, I was able to xm create all three guests again, and they
seem back up now (although an unrelated VPN outage is still keeping web
apps down at the moment).
If anybody sees any issues on any of these hosts - particularly with
data on db2, it could be related to this. Sorry about this, I'll
definitely think more before I run a command like that next time.
Thanks,
Ricky
14 years, 7 months
Change request - Yum update
by Mike McGrath
Turns out there's yet another kernel update available for RHEL5. Since
I've run into issues updating a kernel and not other packages I'd like us
to do a yum update of all the packages. We shouldn't be far off but
there's a kernel and glibc update available. We can run them through
staging first for good measure.
The reboot is on Thursday, it'd be good to have this all done prior to
that.
-Mike
14 years, 7 months
F-I freeze!
by Mike McGrath
It's that time of the year again! The alpha will be out in two weeks
from tomorrow and that means we'll be frozen tomorrow.
http://fedoraproject.org/wiki/Infrastructure/SOP/Release#Change_Freeze
This is a pre-release freeze. We have gotten the OK from release
engineering to go ahead with our planed kernel update this Thursday
(thanks smooge)
Let me know if you have any questions.
-Mike
14 years, 7 months