I've been working on getting the award-lifecycle-badges cron job to run from badges-backend. I beleive I have the script fixed, but I have a couple of problems;
1. This error message from badges-backend01.stg
requests.exceptions.SSLError: hostname 'admin.fedoraproject.org' doesn't match either of '*.stg.fedoraproject.org', 'stg.fedoraproject.org'
2. The original reason (as far as I can tell) that the script fails is that the request to pull down all of the usernames from FAS times out. In a couple of limited (and babysat) tests on the production machine. My script works, but would take (in my estimation) 10-15 hours to run.
I don't know if the reason behind this is that there are alot of lifecycle badges to be awarded, or the resources available to badges-backend + tahrir + fas isn't sufficient for the number of users/backlog we have, or if my fix is crap.
I'd like to get some advice/suggestions on this and have placed an item on the meeting agenda today.
Basically, to get around the timeout issue, I created a list of search terms (a*, b*, etc) so that I only pull in one letter of the alphabet at a time. The main function pulls down each list of usernames, checks to see if each user needs one of five lifecycle badges and awards the badge if the user qualifies. Here is a bit of the main loop;
fas_credentials = fm_config['fas_credentials']
searchterms = gen_fas_searchterms()
for search_elem in searchterms:
results = get_fas_userlist(fas_credentials, search_elem)
I'd like to take download05 out of dns and test out using cachefilesd
on it. We tried this a number of years ago with rhel6 and ran into
problems, but perhaps rhel7 might be more stable.
Basically this would be setting up a 500GB cache on the server and then
caching 500GB of stuff from nfs. In theory this would reduce load on
the backend NFS server. There is a pending netapp upgrade and storage
folks would need to throttle our access while the upgrade was
happening, so the more load we can take off the filer, the better it
will be when we have to do the upgrade.
I'd take download05 out of dns (so no one should hit it), setup
cachefilesd and test. If all goes well on testing we could re-add it
and see if handles normal load. If not or if it cannot handle regular
load we can just repave it and put it back the way it is now.
4 download machines should be fine for the normal load we have, and
this testing should long be done before the end of the week when we
might need to stage Alpha.
It seems there is a fedpkg/pyrpgk update that depends on using the
namespaced (/rpms/) git checkouts.
I'd like to apply the following to pkgs02:
diff --git a/inventory/group_vars/pkgs b/inventory/group_vars/pkgs
index 2ebef26..fa29449 100644
@@ -18,7 +18,7 @@ git_group: packager
git_server_args: --export-all --syslog --inetd --verbose
and then make sure we are using the systemd git socket instead of
xinetd (which we seem to be for some reason currently).
This should allow namespaced git checkouts and fix:
I also have already made this change in stg a while back and it works
Also , can't unsubscribe java-devel mailing list
On Seg, 2016-03-21 at 18:33 +0000, java-devel-
> The results of your email command are provided below. Attached is
> original message.
> - Results:
> sergio(a)serjux.com is not a member of the java-devel mailing list
> - Done.
Sérgio M. B.
On Seg, 2016-03-21 at 18:15 +0000, Mail Delivery System wrote:
> This is the mail system at host lists.fedoraproject.org.
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
> For further assistance, please send mail to postmaster.
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
> The mail system
> <ocaml-devel(a)lists.fedoraproject.org>: host
> mailman01.vpn.fedoraproject.org[192.168.1.118] said: 550 5.1.1
> <ocaml-devel(a)lists.fedoraproject.org>: Recipient address
> rejected: User
> unknown in local recipient table (in reply to RCPT TO command)
Sérgio M. B.
There's been a lot of recent changes in the Mailman stack, including a new
feature that will let us migrate more lists. I'd like to update the
software stack on prod and keep it under observation for a few days (there
are apparently performance issues for some people).
This freeze break does not include migrating the remaining lists, except
trans-ru. I've received a request to migrate this one, it has been cleared
of the filters that blocked it before, so it shouldn't be any different
from the others.
What say you? :-)