Bug 803792 - "resource not found" under component outlines in uploading image
"resource not found" under component outlines in uploading image
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: imagefactory (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Scott Seago
Martin Kočí
: Rebase, Triaged
Depends On: 795403 809504
  Show dependency treegraph
Reported: 2012-03-15 12:35 EDT by Mike Orazi
Modified: 2012-08-29 10:56 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Story Points: ---
Clone Of: 795403
Last Closed: 2012-06-21 14:57:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Comment 1 Mike Orazi 2012-03-15 12:36:12 EDT
Per Jim there is an underlying race condition in imagefactory that should be addressed.
Comment 2 Mike Orazi 2012-04-03 13:50:49 EDT
See comments 24-26 on BZ 795403 for additional info.
Comment 3 wes hayutin 2012-04-03 21:21:36 EDT
I believe the important issue here is addressed in ..
Comment 4 Jim Meyering 2012-05-11 10:48:04 EDT
Now that the iwhd problem is fixed, the remaining issue (if there is one) is with imagefactory, so I'm reassigning this to Scott.
Comment 7 Scott Seago 2012-05-30 20:45:15 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.