Hi folks, This email is to solicit input on a discussion that came up on IRC tonight, with a proposal to have Image Factory allow us to request the builds of child objects at the same time we are requesting the builds for their parents.
Jan and I hit an issue tonight with submitting builds to Image Factory. The problem is essentially caused by the fact that, in our new (reimplemented) build_all method[1], we submit a request to build a new image version, and the immediately commence building target images. This appears to typically work fine when building for a single provider, but when there are multiple providers, this often causes the build to fail, as we end up submitting the target_image builds before the image_version build has completed. In our discussion, we talked about the implementation of this. The "right way" in Conductor would be to set up a background task to handle this. We would submit a request to build an image version, and then wait for a callback from Factory saying it was done. When it was done, we would then submit tasks for each target image we wished to build. (We would have to do this eventually anyway, to allow us to automatically push the image when we got a callback that the build had completed. One-call build-and-push would help here, but this isn't what we're talking about in this email.) Ian proposed that this might be done in Factory itself: <imcleod> matty_dubs: Would it be super-helpful to you to be able to request child image types while the parent is still in progress? Because we could do that. We'd have to add some polling internal to factory, but it's not particularly onerous. My gut is that this would make things significantly simpler, at least on the Conductor side. We wouldn't need to worry about queuing tasks to be sent upon receipt of callbacks. It also just feels architecturally cleaner, to not have two applications that need to know a lot about the inner workings of the other. Ian is going to investigate a bit to get an estimate of how involved this would be. But in the event that it's not too involved, I propose that this would be the best course of action, versus us trying to implement the same sort of thing in Conductor. Do any of you folks have opinions on the matter? -- Matt [1] https://github.com/aeolusproject/conductor/blob/tim-stable-rebased/src/app/decorators/controllers/tim/base_images_controller_decorator.rb#L85 -- specifically, line 95 does not wait
