0-day bodhi

[Luke Macken]

So, after about 20 hours of straight hacking, bodhi seems to be in
fairly good shape at the moment (after rewriting/gutting most of it in
the past 2 days).

The first instance was/is deployed to app3, but was only able to take
submissions as it cannot write to /mnt/koji.  So I deployed bodhi on app5
and did a bunch of initial testing in a development environment with a local
sqlite db.  Everything seemed to work great ("everything" meaning mashing the
repos and generating/sending update announcements.  Other stuff like
updateinfo.xml generation will have to be redesigned and reimplemented)).
I changed the proxy config to point to app5, so hopefully that should
propagate shortly and transparently switch over.

So I threw together a Masher[0] for bodhi that should allow releng to
queue up pushes as they please, and it will churn them out to
/mnt/koji/mash/updates/f7-updates{,-testing}-YYMMDD.HHSS, and then
symlink it to /mnt/koji/mash/updates/fc7-updates{,testing} when
complete.  From here an hourly sync script (that may or may not exist
yet) will pick it up and it will eventually make it out to the mirrors.

>From bodhi's end, it should be able to crunch out updates repos and send
email notices around just fine.  Some critical stuff that we need ASAP:

    o Access control.  We need to make sure that only {,co-}maintainers
      can submit/modify/push their packages.  It would be nice to be
      able to do this by calling the pkdb or koji, but the pkgdb doesn't
      have the API, and koji doesn't know about co-maintainers.  Worse
      case scenario is we parse the owners.list ourselves.

    o Bodhi needs a client cert (instead of using mine)

    o Ability to submit/modify multiple updates at once.  See my post on
      fedora-maintainers[1]

    o XML-RPC API and bodhi-client tool, for doing stuff from the
      command-line.  As shiny as bodhi is, I'd personally rather stay
      out of firefox as much as possible.

    o updateinfo.xml.gz integration.  The old-style updates pushing
      would insert/remove the extended metadata on the fly (and move it
      out of the way when running createrepo, then shove it back in).
      I'm thinking it would be fairly simple to iterate over the mashed
      repo and create/insert this metadata on the fly.  I'm not sure how
      intensive of a process this will be, so we'll just have to try it
      and find out.

That's all I can think of at the moment.. anyone have anything else that
is a top priority for bodhi ?

luke

[0]:
https://hosted.fedoraproject.org/projects/bodhi/browser/bodhi/masher.py
[1]:
https://www.redhat.com/archives/fedora-maintainers/2007-May/msg01034.html