Bodhi/2.0: Difference between revisions

Revision as of 20:10, 7 December 2010

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 'discussions' section.

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)

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.

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 should also make it easier for testers to file bugs from bodhi

Improved karma

Fine grained karma types

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

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 will 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 stack debugger that we can use even after the exception has occured.

Optimized 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.

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 2

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

@@ Line 1: / Line 1: @@
-Bodhi v2.0
+{{admon/note|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 'discussions' section.}}
-Painless update submission
+=== 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)
-Policy Knobs
+=== 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.
-Improved bugzilla integration
+===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 should also make it easier for testers to file bugs from bodhi
-Improved karma
+===Improved karma===
 * Fine grained karma types
-Testing dashboard
+===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
-AutoQA integration
+===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
+===Better security features & workflows===
 * Improved CVE handling and tracking
 * OVAL metadata creation
-Improved metrics
+===Improved metrics===
 * Interactive graphs
 * Metric reports
-Message bus integration
+===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
+===Improved database model===
 * Porting from SQLObject to SQLAlchemy
 ** Migration tools will 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
+===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
+===i18n===
 * TG2/Pylons makes it very easy to make your application internationalizable.
-Improved exception handling
+===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 stack debugger that we can use even after the exception has occured.
-Optimized push process
+===Optimized 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.
-Fedora agnostic
+===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, well documeted RESTful API
+===Well tested and well documented RESTful API===
-* Will retain backwards compatiblity at the JSON level and within python-fedora.
+* Will retain backwards compatibility at the JSON level and within python-fedora.
-Ported from TurboGears 1 to 2
+===Ported from TurboGears 1 to 2===
 * Will benefit from many speed enhancements and architectural improvements
 * Current bodhi stack: TG1, SQLObject, CherryPy, Kid
 * Potential v2.0 stack: TG2, SQLAlchemy, ToscaWidgets2, Mako

Search