AUS/Status:08-12-2010

I'll fix this later.

Goals:

   Data center support: achieving a reasonable amount of lag between multiple data centers (text files = crappy, db = not), have multiple aus servers

   Better integration with release automation tools

   Less overhead per release and reducing chance for human error

   Supreme confidence FTW that AUS is doing what it is supposed to be doing

   Transition to new system without any downtime or regressions

This coming week:

   nthomas, catlee: sketch out what we'd do to create a system separate from patcher -- what would it look like, what's the scope?

   morgamic: jump on schema, get additional resources for API and test migration tasks

   morgamic: schedule check-ins and file bugs for tasks below, create schedule somewhere (wiki, spreadsheet, whatever)

August Tasks:

   Agree on a basic schema.  Make it be so, document, check in somewhere.

   Config -> other data store to  avoid having code updates for every release and help witha automation  (don't just store it in a config.php file).

   Audit trail: be able to track what happens with updates over time to offer the capability of doing rollbacks.

   Create new tool to send update information to AUS3 data store.

   Move tests out of fitnesse so they can be run from the command line using pyunit.

September Tasks:

   Continuous integration for tests using hudson or equivalent.

   Create API that allows us to push snippets to test/beta/release channels via command line or other brokering/messaging

   Admin goals: be able to disable  update easily ('enabled' flag in db?).  Permissions (release drivers  should be able to push updates to beta/release channel)

   Testing: grab live data from aus2 and see if aus3 gives same results

   Add hook for NS/Zeus to clear cache when an update gets pushed (and memcache, if applicable)

Schema Ideas

• https://wiki.mozilla.org/AUS:v3
• collapsed seems the easiest; which will be less overhead especially if we're keying off of product/version/channel 99% of the time
• how do we store metadata for the update payload?
  • blob in the main table?
  • foreign key to another table (updates table, plus colums for each value)

Problems to solve

• reduce duplicated data
• set up wildcard rules to handle the common case

Rules

• 1 step up gets the partial
• os block gets checked first
• throttle gets checked first (global)
• per-product throttle

New attributes

• Rob strong has added more key/value pairs to the update XML