As many have already noticed, I performed a large bodhi upgrade recently. A
few weeks ago, during The Incident, I was forced to perform what was originally
going to be a week long bodhi migration and upgrade, overnight. During the
past two weeks I've pushed out 24 versions of bodhi to our infrastructure,
fixing various show-stoppers, and making sure that updates got out the door.
One of the most noticable changes is that bodhi is much more responsive.
Previously, bodhi was a single python process, running on a single server.
This single server was also responsible for composing the updates repositories,
and rawhide, among lots of other bodhi-related churn. This lead to much pain
and suffering for all.
The bodhi deployment has since changed. All bodhi requests are now load
balanced to a bunch of app servers, each running mod_wsgi with multiple bodhi
processes, each with multiple threads. All of the hard work is now done on an
isolated releng server. This separate bodhi "masher" is now responsible for
composing repositories, updating bugs, generating update notices, sending
emails, extended metadata generation, and calculating metrics. I also added
support for inter-bodhi communication, which allows our bodhi web frontends to
kick off push requests to our bodhi-masher instance.
Some of the new features in this release:
- A much more flexible karma automatism scheme. Stable/unstable karma
thresholds are now fully configurable
- Support for bug aliases
- A 'newpackage' update type
- Newer updates which obsolete older ones will now inherit their bugs and notes.
- A shiny new API in the fedora.client.bodhi module
- Lots of improved releng and security team support, making our lives little easier
- An improved `make update` template (be sure to update your Makefile.common)
- Some new bodhi-client features
- Creating updates for multiple releases using a single form
Note: This is not perfect yet. You can use the "New Update Form" to add any
number of builds for any number of releases, but bodhi will still create a
single update for each. This issue will be resolved in the next major bodhi
release, which will contain a full model redesign.
- updateinfo.xml generation takes about 20 seconds, instead of 20 minutes.
- A lot of metrics enhancements
- A ton of bug and usability fixes
Bodhi is far from being feature complete. Some new features in the pipeline:
- DeltaRPM generation
- Security issue (CVE) tracking and triaging
- Dependency closure verification, utilizing the power of rpmgrok.
- A complete remodeling from SQLObject to SQLAlchemy, which is almost complete,
will give us a lot more flexibility, speed, and power over our update model.
This will also allow for things such as having multi-builds for multiple
releases in a single update.
- File tickets here: https://fedorahosted.org/bodhi/newticket
- Help out here: https://fedorahosted.org/bodhi/report/1
- Subscribe to the bodhi mailing list here:
- You can always find bodhi here: http://bodhi.fedoraproject.org
Thank you all for your patience during the past few weeks,
p.s. If you're having issues with the bodhi client, a fixed version will be
going out with the next batch of updates. For the impatient, you can pull
fixed versions from koji (also, make sure your Makefile.common is up to date):
koji download-build --arch=noarch python-fedora-0.3.5-1.fc10
koji download-build --arch=noarch bodhi-0.5.2-1.fc9