{{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 'discussion' section of this page.}}

{{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 'discussion' section of this page.}}

* Pyramid resource traversal has been written ([http://git.fedorahosted.org/git?p=bodhi.git;a=blob;f=bodhi/resources.py;h=6d15cadf1ae749fd462d519d399286106c84ad86;hb=refs/heads/pyramid bodhi/resources.py])

+

* Generic JSON and HTML grid views are now available for all models (Updates, Builds, Comments, Users, Releases, etc)

** 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. ([https://git.fedorahosted.org/cgit/bodhi.git/tree/bodhi/validators.py?h=pyramid bodhi/validators.py])

+

+

== Goals ==

=== 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)

* 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 ===

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

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

* Make it much more obvious as to what high-priority updates need testing

* 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

+

* 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===

===AutoQA integration===

Line 48:

Line 72:

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

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

−

===Optimized push process===

+

===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)

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

* 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===

===Fedora agnostic===

Line 58:

Line 83:

* Will retain backwards compatibility 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 Pyramid===

* Will benefit from many speed enhancements and architectural improvements

* Will benefit from many speed enhancements and architectural improvements

* Current bodhi stack: TG1, SQLObject, CherryPy, Kid

* Current bodhi stack: TG1, SQLObject, CherryPy, Kid

−

* Potential v2.0 stack: TG2, SQLAlchemy, ToscaWidgets2, Mako

+

* Potential v2.0 stack: Pyramid, SQLAlchemy, Mako

Revision as of 16:47, 9 May 2014

This is a draftThis 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.

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.

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