The orchestrator coordinates module builds and is responsible for a number of tasks:
The orchestrator implements a RESTful interface for module build submission and state querying. Not all REST methods are supported. See below for details.
Module submission is done via posting the modulemd SCM URL.
POST /rida/module-builds/
{ "scmurl": "git://pkgs.fedoraproject.org/modules/foo.git/foo.yaml?#f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 }
The response, in case of a successful submission, would include the task ID.
HTTP 201 Created
{ id: 42 }
Once created, the client can query the current build state by requesting the build task's URL. Querying the BPO service might be preferred, however.
GET /rida/module-builds/42
The response, if the task exists, would include various pieces of information about the referenced build task.
HTTP 200 OK
{ "id": 42, "state": "build", "tasks": { "rpms/foo" : "6378/closed", "rpms/bar : "6379/open" } }
"id" is the ID of the task. "state" refers to the orchestrator module build state and might be one of "init", "wait", "build", "done", "failed" or "ready". "tasks" is a dictionary of component names in the format of "type/NVR" and related koji or other supported buildsystem tasks and their states.
The list of all tracked builds and their states can be obtained by querying the "module-builds" resource.
GET /rida/module-builds/
HTTP 200 OK
[ { "id": 41", "state": "done" }, { "id": 42, "state": "build" }, { "id": 43, "state": "init" } ]
Possible response codes are for various requests include:
You can see the list of possible states with:
import rida print(rida.BUILD_STATES)
Here's a description of what each of them means:
This is (obviously) the first state a module build enters.
When a user first submits a module build, it enters this state. We parse the modulemd file, learn the NVR, and create a record for the module build.
Then, we validate that the components are available, and that we can fetch them. If this is all good, then we set the build to the 'wait' state. If anything goes wrong, we jump immediately to the 'failed' state.
Here, the scheduler picks up tasks in wait and switches to build immediately. Eventually, we'll add throttling logic here so we don't submit too many builds for the build system to handle.
The scheduler works on builds in this state. We prepare the buildroot, submit builds for all the components, and wait for the results to come back.
Once all components have succeeded, we set the top-level module build to 'done'.
If any of the component builds fail, then we set the top-level module build to 'failed' also.
This is a state to be set when a module is ready to be part of a larger compose. perhaps it is set by an external service that knows about the Grand Plan.