Zeller

Joined 28 June 2013
no edit summary
No edit summary
No edit summary
Line 18: Line 18:
* Make /status GET queriable (other than var1 and var2). Other release tables use the column variables ready and complete.
* Make /status GET queriable (other than var1 and var2). Other release tables use the column variables ready and complete.
* Run a JOIN via the name column between release_status and *_releases, and print that JSON info upon /status/<release-name> GET request.
* Run a JOIN via the name column between release_status and *_releases, and print that JSON info upon /status/<release-name> GET request.
* Take progress bars from bootstrap rather than change the entire css
*  
*  


Line 31: Line 32:
* Have StatusAPI update the database tables *-release, and check that name is in release_data
* Have StatusAPI update the database tables *-release, and check that name is in release_data
* Check to see if name already exists in tables *-release, and check that name is in release_data before adding to release_status... use as switch between creating a new row and updating rows.
* Check to see if name already exists in tables *-release, and check that name is in release_data before adding to release_status... use as switch between creating a new row and updating rows.
* DATETIME stamps need to not have T or +01:00


=== Bug 1032978 - Add a standalone process that listens to pulse for release related buildbot messages ===
=== Bug 1032978 - Add a standalone process that listens to pulse for release related buildbot messages ===
Line 39: Line 41:
* If collecting, release_data, then the table will gain ~0.5mb/release, which I estimate makes it ~117Mb/year.
* If collecting, release_data, then the table will gain ~0.5mb/release, which I estimate makes it ~117Mb/year.
* If version = "None", then routing_key doesn't have <u>build</u>.release-*
* If version = "None", then routing_key doesn't have <u>build</u>.release-*
* Some pulse fields are unnecessary, such as 'exchange', and 'serializer'
* Nothing says *.finished
==== Questions ====
==== Questions ====
* What do do with release messages that don't fit the expected:
* What do do with release messages that don't fit the expected:
Line 48: Line 52:
* Should I look at routing_key, or key, or?
* Should I look at routing_key, or key, or?
* Do we want to keep all buildbot release pulse data, to be able to use it later to deduce new things, or forgoe all that entirely? (feature creep)
* Do we want to keep all buildbot release pulse data, to be able to use it later to deduce new things, or forgoe all that entirely? (feature creep)
*  
* Does only build.release-* need to be caught, or also unittest.release-*, talos.release-*, etc?
==== To Do ====
==== To Do ====
* Long-running standalone script (shipit-agent.py) that listens to pulse and uses / status/<release-name> with POST to update update.db for <release-name> status
* Long-running standalone script (shipit-agent.py) that listens to pulse and uses / status/<release-name> with POST to update update.db for <release-name> status
Confirmed users
194

edits