|
|
| Line 1: |
Line 1: |
| == Two Approaches to the Orchestrator ==
| | {{admon/important|This page is deprecated| All Fedora Modularity Documentation has moved to the new [https://docs.pagure.org/modularity/ Fedora Modularity Documentation website] with source hosted along side the code in the [https://pagure.io/modularity Fedora Modularity website git repository]}} |
| | |
| In the Modularity Group, we have two approaches to take in how the orchestrator
| |
| and koji relate to each other. They differ in which system owns the code for
| |
| finishing the build of a module.
| |
| | |
| === Modules as first-class citizens in koji ===
| |
| | |
| In this approach, koji owns the code for building a module from front-to-back.
| |
| | |
| A packager might execute the following:
| |
| | |
| <pre>
| |
| $ fedpkg module-build
| |
| </pre>
| |
| | |
| Which would talk to koji over XMLRPC and schedule a module-build. That module
| |
| build would entail rebuilding *all* of the constituent RPMs from source as
| |
| subtasks, and it would in the end create a repo for them with the built module
| |
| metadata baked in.
| |
| | |
| When that build of the module completes, it would publish a message to the bus
| |
| which gets picked up by taskotron which would run any checks we have defined
| |
| for whole modules.
| |
| | |
| When those checks finish, they publish a message which gets picked up by the
| |
| orchestrator. In this approach, the orchestrator is *very* simple. Its
| |
| pseudocode looks like this:
| |
| | |
| <pre>
| |
| def on_event_from_taskotron(event):
| |
| | |
| if not event.is_about_a_module:
| |
| return
| |
| | |
| if not event.check_passed_successfully:
| |
| email_relevant_people("rebuild is stuck")
| |
| return
| |
| | |
| dependants = ask_PDC_for_dependants(events.module_that_just_got_built)
| |
| for other_module in dependants:
| |
| koji.schedule_rebuild_of(other_module)
| |
| </pre>
| |
| | |
| And that's it. It listens to the bus only. There is no other way to talk to the orchestrator.
| |
| Users initiate the process by asking koji
| |
| | |
| === Orchestrator as the owner of module-build ===
| |
| | |
| In this approach, modules are not first-class citizens in koji, and the
| |
| orchestrator owns more of the logic about how to build them.
| |
| | |
| A packager might execute the following:
| |
| | |
| <pre>
| |
| $ fedpkg module-build
| |
| </pre>
| |
| | |
| Which would talk to the orchestrator over a REST api (which means it has to be
| |
| a webapp now). The orchestrator would pull down the yaml file and start
| |
| scheduling builds for all of those components individually in a tag/target
| |
| specifically for that module.
| |
| | |
| It has to keep track (in a database) of all the ones it has submitted so that,
| |
| as they finish and each get validated by taskotron, it can know if they are now all done or not.
| |
| | |
| Once they are all done, it then has to build the repo (either itself, or by
| |
| scheduling another task in koji that would have to be modified anyways to
| |
| insert the built module metadata yaml).
| |
| | |
| Finally, it would have to publish a fedmsg message saying that it is done.
| |
