RFC: Factory support for nested build requests

Jason Guiditta jguiditt at redhat.com
Thu Jan 10 14:37:56 UTC 2013


On 09/01/13 18:46 -0500, Matt Wagner wrote:
>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

Matt, my initial reaction is that it does indeed make sense to 'hide'
this in factory, if it is doable there.  I prefer the idea of
conductor (or any factory client) not having to know about some of
these details.

-j


More information about the aeolus-devel mailing list