Per Jim there is an underlying race condition in imagefactory that should be addressed.

See comments 24-26 on BZ 795403 for additional info.

I believe the important issue here is addressed in ..
https://bugzilla.redhat.com/show_bug.cgi?id=795403#c17

Now that the iwhd problem is fixed, the remaining issue (if there is one) is with imagefactory, so I'm reassigning this to Scott.

So the original bug was definitely "blocker" material -- if a user deleted a top level image (not a build or provider image) _while_ factory was in the middle of a build, factory set the latest_build attribute on the (now defunct) image in iwhd, resulting in an inconsistent iwhd state -- when iwhd went over the list of image uuids with attributes attempting to pull the actual image object, it would error out every time conductor attempted an 'image list' call. That has been fixed.

The remaining issue is the fact that, if the image is deleted while a build is in progress, factory will probably still create the 'provider image' objects and will probably upload the new image to the provider. The build itself will then (probably) fail when attempting to set the latest_build attribute. Conductor will probably never see this, since conductor starts with the list of top level images (and this one is gone).

Someone should test this, but if the above _guesses_ on what will happen are true, then there's really nothing of a blocking nature here -- but some things should be fixed on a subsequent release. Namely that factory should probably check to make sure that the top level image obj still exists before saving the built image metadata or uploading it anywhere. Conductor should (perhaps?) prevent deletion of images while there's an ongoing build.

The only thing that would consist of a "fix it now" sort of blocker would be if the 'deletion during build' scenario results in either factory or conductor going into an inconsistent state or otherwise fails to work properly after this occurs.