The infrastructure team will be having it's weekly meeting tomorrow,
2013-02-21 at 19:00 UTC in #fedora-meeting on the freenode network.
#topic New folks introductions and Apprentice tasks.
If any new folks want to give a quick one line bio or any apprentices
would like to ask general questions, they can do so in this part of the
meeting. Don't be shy!
#topic Applications status / discussion
Check in on status of our applications: pkgdb, fas, bodhi, koji,
community, voting, tagger, packager, dpsearch, etc.
If there's new releases, bugs we need to work around or things to note.
#topic Sysadmin status / discussion
Here we talk about sysadmin related happenings from the previous week,
or things that are upcoming.
#topic Private Cloud status update / discussion
#topic Upcoming Tasks/Items
#info 2013-02-28 end of 4th quarter
#info 2013-03-01 nag fi-apprentices
#info 2013-03-07 remove inactive apprentices.
#info 2013-03-19 to 2013-03-26 - koji update
#info 2013-03-29 - spring holiday.
#info 2013-04-02 to 2013-04-16 ALPHA infrastructure freeze
#info 2013-04-16 F19 alpha release
#info 2013-05-07 to 2013-05-21 BETA infrastructure freeze
#info 2013-05-21 F19 beta release
#info 2013-05-31 end of 1st quarter
#info 2013-06-11 to 2013-06-25 FINAL infrastructure freeze.
#info 2013-06-25 F19 FINAL release
#topic Open Floor
Submit your agenda items, as tickets in the trac instance and send a
note replying to this thread.
More info here:
Askbot instance on server -> bastion01.phx2.fedoraproject.org <- is once again sending lots of emails due to a missing database column error.
File "/usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in execute
return self.cursor.execute(query, args)
DatabaseError: column askbot_post.approved does not exist
LINE 1: ...kbot_post"."author_id", "askbot_post"."added_at", "askbot_po...
Just wanted to bring it to your notice.
Dear all, I'm preparing a new fas release now. This release has a few new
strings so I'll be pushing it out to the translators soon. Translators
generally like to have about 10 days to work so I'll be planning to release
and push to production on Thursday the 28th of February.
Now that we're using git flow, I'm going to try something new -- develop is
going to continue to be open for work/merging of new features/etc. The
release/08.16 branch is where I'll be merging bugfixes for the release,
translations, and other things for the release. Hopefully these will be
able to go on in parallel.
If there are any hotfixes before release, we'll need to merge them to
develop, release/0.8.16, and master. Hopefully this won't be too much of a
If there's anything I've forgotten in thinking about how to manage this
release via git flow, feel free to let me know :-)
Here's the new python-bugzilla release to support the future
bugzilla.redhat.com 4.4 update.
Of the incompatibilities listed below, the only one that I know fedora
infrastructure is using is Bug.url renamed to Bug.weburl. pkgdb supposedly
Feel free to ping me if you hit any issues.
-------- Original Message --------
Subject: [python-bugzilla] ANNOUNCE: python-bugzilla 0.8.0 released
Date: Sat, 16 Feb 2013 12:29:02 -0500
From: Cole Robinson <crobinso(a)redhat.com>
Reply-To: python-bugzilla user/developer list
To: python-bugzilla user/developer list <python-bugzilla(a)lists.fedorahosted.org>
I'm happy to announce a new release of python-bugzilla, version 0.8.0.
The releases can be downloaded from:
This release includes:
- Replace usage of non-upstream Red Hat bugzilla APIs with upstream replacements
- Test suite improvements, nearly complete code coverage
- Fix all open bug reports and RFEs
In particular, this release is necessary to support the next major update of
bugzilla.redhat.com. Most of the custom bugzilla.redhat.com XMLRPC API calls
are being removed, so python-bugzilla has been adjusted to transparently use
the upstream API replacements. There are some behavior changes though (that I
- Format of Bug.longdescs/Bug.comments changed, though most of the info is
still available. Main change is that 'body' was renamed to 'text'
- ID field for Bug.attachments was renamed from attach_id -> id
- Bug.url (actual URL for the bug report) was been renamed to Bug.weburl.
Bug.url is now the URL field in the bug report.
- RHBZ parameter format back compatibility now must be explicitly enabled in
the API by setting RHBugzilla.rhbz_back_compat = True. Can also be set via
__init__. What this toggles:
-- Converts 'blocks'/'blockedby'/'blocked', 'keywords', and 'alias' fields
from a list to old style comma separated string
-- Converts current more verbose 'flags' field to old style comma separated string
-- Converts 'groups' value into more verbose setting per the old format.
However, usage of this back compat option is not recommended. I suggest
updating your scripts to use the new values returned by bugzilla.redhat.com,
since most fields are now stable and won't change in the future.
If you hit any regressions, please drop a mail to
python-bugzilla(a)lists.fedoraproject.org or file a bug in rhbz:
python-bugzilla mailing list
With the new version of bugzilla that is currently deployed on
partner-bugzilla, there are some API changes  that have prompted
changes in python-bugzilla.
AFAIK, the updates to python-bugzilla have all been written but there
are changes to how the code does updates. I've requested a new build
for testing integration and they should land sometime in the next day or
If you're maintaining something that uses python-bugzilla, you might
want to take a look to make sure that you won't need code changes when
the new 4.4 hits production servers.
I don't know when the planned release date is at the moment but I
suspect that it will be soon. I'll update this thread when I know more.
I am Hitendra from Mumbai, India
IRC handle - hitendra
I would like to work system administration, preferably user management
followed in fedora, automating repetead task by writing scripts .
I would like to learn SCM administration for CVS, although I have
experience in Rational Clearcase which is also a SCM and Red Hat Linux
I am owner of a project hosted on Fedora Hosted.
So far I've been keeping web page of my project on fedorapeople.org and this
solution worked quite well until now. After the project evolved there are
some problems with current solution. The biggest of them is that only I can
modify the website. Besides that changing project owner in the future would
change the address of the website.
Is there any possibility to host static HTML web page (instead of Trac
instance) on Fedora Hosted? It would be great if all members of FAS group
associated with the project could make changes to the website through SSH.
Today Patrick got the trac plugin for openid working pretty well with the
new openid service. This effectively breaks our tight bind to the fas db
(and mod_auth_pgsql) from the hosted boxes.
A while back we discussed the possibility of scaling the hosted service
out horizontally somewhat by being able to break the projects up into
chunks of data.
We said we'd need folks to refer to their sites with something like:
so we could direct them to the right machine via dns on the backend. And
we could then more easily add capacity as needed.
One thing we've been doing is running fedorahosted behind https. Part of
that is b/c we were doing a basic-auth to pgsql to auth against fas. With
openid that won't be an issue anymore.
The second reason is for personal/private/confidential items in tickets or
what-not - for example the board trac instance. To that I suggest we
bottle up the board trac instance, stuff it somewhere we can put an ssl
cert in front of it and move along.
For the rest we make them non-ssl'd. The openid login, of course would be
ssl'd, but the rest of the site doesn't really need to be, does it?
So we'd still need to get people to refer to the right urls. I don't think
that would be likely to happen over night but we can at least start doing
What we get:
1. we get the possibility of not having all of our eggs in the one basket
of serverbeach and the two hosted instances running now
2. we can possibly gain performance by getting some of the data off of the
one big gluster dastastore.
3. we gain the ability to setup a 'newhosted' server, put a few
trac/git/etc instances over there and try things out w/o breaking all the
rest of them.
4. If we suddenly find we have a single, extremely popular project (good
problem to have imo) then we can give it a dedicate instance and maintain
Does anyone like this idea? Is anyone opposed to it? Got criticisms that
sould be addressed? Things I'm completely blanking about?
let me know.
Recently I have been working on a new OpenID implementation for the Fedora
Account System, and I would like to ask everyone of the Infrastructure team
to test it and give me feedback.
You can test it by going to any website that accepts OpenID as
authentication, and enter "http://<username>.id.stg.fedoraproject.org/" as
your OpenID, with "<username>" replaced by your FAS username.
Please give me feedback on websites that were successful, that were not
successful, and on the system itself.
You can reach me either by replying to this mail, or on IRC as puiterwijk
in the #fedora-admin channel.
Thanks in advance,