BuildController is responsible for a lot of things. Unfortunately, it is very difficult to determine where and how BuildController does its job, which makes it more difficult to extend and modify as well as test.

Instead, it may be more useful to think of BuildController as the thing that converts MachineOSBuilds into build pods, jobs, et. al. Similar to how we have a subcontroller for dealing with build pods, we should have another subcontroller whose job is to produce MachineOSBuilds.

Done When:

• A MachineOSBuildController (or similar) is introduced into pkg/controller/build whose sole job is to watch for MachineOSConfig creation / changes, as well as MachineConfigPool config updates.
• In response to the aforementioned events, MachineOSBuildController should create a MachineOSBuild object using those inputs.
• If a build is currently in progress and one of the aforementioned events occurs, either MachineOSBuildController or BuildController (TBD which one), should cancel the running build, clean up any ephemeral build objects, and start a new build.
• BuildController can be simplified to only look for the creation and deletion of MachineOSBuild objects.
• This, coupled with https://issues.redhat.com/browse/MCO-1326, will go a long way toward making BuildController more resilient, modular, and testable.