Hey everyone, 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. As always, - File tickets here: https://fedorahosted.org/bodhi/newticket - Help out here: https://fedorahosted.org/bodhi/report/1 - Subscribe to the bodhi mailing list here: https://fedorahosted.org/mailman/listinfo/bodhi - You can always find bodhi here: http://bodhi.fedoraproject.org Thank you all for your patience during the past few weeks, luke 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
Attachment:
pgpd5sHzSmhca.pgp
Description: PGP signature
_______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-announce
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
