User:Bhearsum/Balrog/Administration
This page describes and documents the web-based administration interface for AUS3.
Build Machine Use Cases
Build machines have a relative small set of interactions with the server. The following use cases demonstrate them all:
Releases
At the start of the release process a new release is created in the AUS database. Its entry contains all platform independent information: release name, versions, filenames, bouncer products, etc. No platform information (including a list of platforms to be built) is included in the initial entry. If the release already exists an error will be raised.
At the end of each en-US and l10n repack job the newly created build is added to the AUS database, associated with the release created in the previous step. If the build already exists an error will be raised.
Once all builds for a release have been added to the database the betatest and releasetest channel rules for that stream will be updated to point at the newly created release.
Making the beta & release channels live will not be done by automation, and thus aren't covered here.
Nightly Updates
When a branch that receives nightly updates is set-up, a rule will be added that maps all users on its nightly channel to a release identified by $product-$channel-latest (Eg, Firefox-nightly)1. This is a one time set-up and requires no additional maintenance down the road.
When a new nightly build is ready to be published, the build machine will add it to the AUS database in two places: the $product-$channel-latest release, as well as a $product-$channel-$buildid release. Once the -latest release has been updated the new update is live.
Web Administration
Use Cases
In contrast to build machines, the human-driven interface is capable of modifying all parts of the AUS database. These use cases are highly dependent on UI, so are only bullet points for now:
- Turn off updates for a specific channel, branch, or globally
- Adjust throttling for a specific rule or across a whole branch
- Change an update channel to point at a different release
- Add rules to block a specific architecture
- Add, modify, or delete a custom rule
- Add, modify, or delete a release
UI
TBD
API
Both the build machine client and the web administration API will make use of the REST interface described below:
| URI | Method | Parameters | Description |
|---|---|---|---|
| /releases | GET | Retrieves all release names | |
| /releases/[name] | GET | Retrieve the release identified by "name" | |
| /releases/[name] | PUT | details - the JSON blob associated with this release | Update the release with the supplied JSON data. If non-existent, it is created. Be careful when using this for existing releases that already have builds added to them -- the JSON blob given here overrides all data for the release, not just platform independent data. |
| /releases/[name] | DELETE | Delete the release | |
| /releases/[name]/builds | GET | Retrieve all builds from a release | |
| /releases/[name]/builds/[platform]/[locale] | GET | Retrieve a specific build from a release | |
| /releases/[name]/builds/[platform]/[locale] | PUT | details - the JSON blob associated with this build | Update the build with the supplied JSON data. If non-existent, it is created. |
| /releases/[name]/builds/[platform]/[locale] | DELETE | Delete the build | |
| /rule | POST | priority | Create a new rule with the supplied parameters. |
| mapping | |||
| throttle | |||
| update_type | |||
| product | |||
| version | |||
| channel | |||
| buildTarget | |||
| buildID | |||
| locale | |||
| osVersion | |||
| distribution | |||
| distVersion | |||
| headerArchitecture | |||
| comment | |||
| /rule | GET | Same as /rule POST | Retrieve all of the rules that match the specified parameters. Any missing parameters are regarded as wildcards, therefore a request with no parameters returns all rules. |
| /rule/[id] | PUT | Same as /rule POST | Replace the rule with the supplied parameters. Any missing parameters will be considered NULL. |
| /rule/[id] | POST | Same as /rule POST | Update the rule with any parameters passed. Any missing parameters will not be changed. |
| /rule/[id] | DELETE | Delete the rule |
Footnotes
1. $product-$channel-latest only works in a world where no channel names overlap, which we should be in once 1.9.2 is dead. Doing it this way ensures that we nightly updates work after version bumps happen *and* we don't need to maintain a branch name <-> version mapping a la existing AUS.