From Fedora Project Wiki

Revision as of 13:05, 9 September 2016 by Sgilson (talk | contribs) (Created page with "== Two Approaches to the Orchestrator == In the Modularity Group, we have two approaches to take in how the orchestrator and koji relate to each other. They differ in which ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Two Approaches to the Orchestrator

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:

    $ fedpkg module-build

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:

    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)

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:

    $ fedpkg module-build

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.