Bodhi/2.0

This is a draft
This is a draft of potential features for Bodhi v2.0. It is meant to spawn discussion and will most likely evolve in the future. Please feel free to add your ideas, comments, and criticism to the 'discussion' section of this page.

Mockups

• Bodhi 2.0 Front Page Mockup by Máirín Duffy

Status

• pyramid branch created in bodhi's git repo
• Bodhi's test suite has been ported to the WebTest framework
• Bodhi's database model has been ported from SQLObject to SQLAlchemy
• Templates have been partially ported from Kid to Mako
• To complete the TG1->pyramid port, bodhi's widgets and controllers
• Pyramid resource traversal has been written (bodhi/resources.py)
• Generic JSON and HTML grid views are now available for all models (Updates, Builds, Comments, Users, Releases, etc)
• SQLObject -> SQLAlchemy migration script written (ticket #609 tools/pickledb.py)
  • You can import an old bodhi database snapshot by running python tools/pickledb.py migrate <snapshot>.
• All of the sanity checking in bodhi's save() method has been ported to ToscaWidgets2/FormEncode validators, and tests cases have been written. (bodhi/validators.py)

Goals

Painless update submission

• At the moment we have an auto-completion widget that aids in the creation of new updates from the web form. With bodhi v2.0, we wish to take this a step further and make it even easier to submit new updates. This could be done in a variety of ways: from providing a list of your candidate updates, to being able to clone existing updates, or by making it simple to submit full 'stack' updates (e.g: firefox & related deps)
• Bodhi shall ensure that a package and its dependencies are always pushed together as a single update unit, even if the update unit is maintained by multiple parties, pushed initially as independent updates.

Policy Knobs

• As opposed to hardcoding policy logic into the system, every aspect of bodhi 2.0's update policy will be exposed as configuration options which will allow us to tweak them as we see necessary without any code changes.
• Policy ideas: User:Kevin/Updates_Policy_Changes_Ideas_Container

Improved bugzilla integration

• During update creation, bodhi v2.0 will display a list of bugs that are potentially related to your update, allowing you to easily add them to it.
• Bodhi will also make it easier for testers to file bugs from bodhi

Improved karma

• Fine grained karma types
• Karma ideas: http://lists.fedoraproject.org/pipermail/devel/2010-March/134087.html http://bochecha.fedorapeople.org/bodhi_karma_revamped
• Preview of karma implementation: http://threebean.org/blog/bodhi2-karma-system-preview/

Testing dashboard

• Make it much more obvious as to what high-priority updates need testing
• For each update, make it obvious what people can do to effectively test the update and provide useful feedback (https://fedorahosted.org/fedora-qa/ticket/154)
• Make it clear *exactly* what has changed in each update, from spec file changes to full code diffs.

AutoQA integration

• Bodhi v2.0 will provide tight AutoQA integration, allowing us to require AutoQA results in our policy, and making it simple to view results and such.

Better security features & workflows

• Improved CVE handling and tracking
• OVAL metadata creation

Improved metrics

• Interactive graphs
• Metric reports

Message bus integration

• Bodhi v2.0 will offer AMQP broker integration. This means that upon various events, bodhi will send notifications to a central message broker, allowing clients and other services to react to them accordingly.
• It will also be designed to potentially listen for events that our infrastructure may send out in the future, such as when a new koji build completes, or when AutoQA finishes testing an update, etc.

Improved database model

• Porting from SQLObject to SQLAlchemy
  • Migration tools for our schema to easily evolve over time
  • Will allow us to perform more sophisticated and efficient SQL queries, thanks to features such as eager-loading

Release phases

• Bodhi v2.0 will become aware of the various release phases. So, when an upcoming release branches from rawhide, bodhi will automatically know to enable the "No Frozen Rawhide" policies. When a release goes EOL, bodhi will know to freeze it, while still making the data easily available and accessible.
• Bodhi v2.0 will also become more flexible with handling different releases, such as Fedora and EPEL, which have different policies.

i18n

• TG2/Pylons makes it very easy to make your application internationalizable.

Improved exception handling

• Right now exceptions propagate to the bodhi logs, but there is no proactive measurements that notify us of errors as they happen. The WebError middleware that comes with TG2 will email us upon every exception and offers a rich traceback debugger that we can use even after the exception has occured.

Improved push process

• The current push process within bodhi (aka The Masher) does a lot of work that can be done in parallel. The next version will effectively scale to multiple processors, prioritize critical/security updates, and sync each release to the mirrors once it is complete (as opposed to waiting until all releases are complete)
• There are a variety of race-conditions that can occur with the current push process. Bodhi v2.0 aims to eliminate these, potentially by locking updates when they are being pushed, or by some other means.
• Ensure that packages are not pushed which would break dependencies within Fedora (or EPEL).

Fedora agnostic

• Bodhi is currently used in many places outside of Fedora. One of the goals of v2.0 is to make it much more flexible for people that aren't within a koji/pkgdb/fas/bz environment.

Well tested and well documented RESTful API

• Will retain backwards compatibility at the JSON level and within python-fedora.

Ported from TurboGears 1 to Pyramid

• Will benefit from many speed enhancements and architectural improvements
• Current bodhi stack: TG1, SQLObject, CherryPy, Kid
• Potential v2.0 stack: Pyramid, SQLAlchemy, Mako