one note on this bug.. is not provider accounts were configured

Reason why entries are empty is that both image body and template body in warehouse are missing.

Why this happened can be found in iwhd.log:
log of the template creation:

Jan 26 09:14:30 iwhd[13399]: 127.0.0.1.42932 "PUT /templates" -
Jan 26 09:14:30 iwhd[13399]: 127.0.0.1.42932 401 0
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43058 "GET /" -
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43058 200 554
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43059 "PUT /templates/0619126a-482a-11e1-8f39-5cf3fc217780" 907
iwhd: failed to open file: templates/0619126a-482a-11e1-8f39-5cf3fc217780: No such file or directory
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43059 500 0
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43060 "PUT /templates/0619126a-482a-11e1-8f39-5cf3fc217780/object_type" 8
Jan 26 09:28:32 iwhd[13399]: no size, mongo may be dead
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43060 201 8
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43061 "PUT /templates/0619126a-482a-11e1-8f39-5cf3fc217780/uuid" 36
Jan 26 09:28:32 iwhd[13399]: no size, mongo may be dead
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43061 201 36
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43062 "POST /templates/0619126a-482a-11e1-8f39-5cf3fc217780" 8
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43062 200 447
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43063 "GET /templates/0619126a-482a-11e1-8f39-5cf3fc217780/object_type" -
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43063 200 8
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43064 "GET /templates/0619126a-482a-11e1-8f39-5cf3fc217780/uuid" -
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43064 200 36
Jan 26 09:28:32 iwhd[13399]: 127.0.0.1.43065 "GET /templates/0619126a-482a-11e1-8f39-5cf3fc217780" -
Jan 26 09:28:32 iwhd[13399]: templates/0619126a-482a-11e1-8f39-5cf3fc217780 not found at primary


From above it seems that bucket '/template' wasn't created because the create request was unauthorized (401). Then following request on saving template's body fails with message "No such file or directory" (probably because 'template' directory wasn't created in prev. step). Rest of requests (saving template's attributes) pass - attrs are saved in mongodb.

There are two bugs:
1) bucket creation request is unauthorized - I don't know why, this requires more testing to find out if this happens more often.

2) if template body is not saved, conductor should abort object creation (not create attrs for the object) and report an error to the user - this happens if oauth is off because restlient raises an exception on status codes != 200. But oauth requests don't raise an exception for error status codes and aeolus-image-rubygem continues in attributes creation then. Note that oauth is enabled by default.

1) I'm not able to reporoduce 1) and can't find it in code

2) an exception should be raised even if a request si done through oauth lib. Also on some places in aeolus-image-rubygem RestClient::* Exceptions. So probably more general exception should be raised in do_Request and this exception should be catched instead of RestClient::*.

I wasn't able to reproduce this bug, from logs I identified 2 potential problems described above but for fixing of problem 1) I would need to be able to reproduce this. Wes, are you able to reproduce this?

I'm going to fix up #2 here, since it (a) needs to be fixed, and (b) might shed some light on why #1 happens (but not reproduceably).

Heh, in WarehouseModel:

            unless self.warehouse.buckets.include?(self.bucket.name)
              begin
                self.bucket = self.warehouse.create_bucket(self.bucket.name)
              rescue
                # there was an iwhd bug ago - it wasn't possible to find out
                # if a bucket exists or not, then code 500 was returned.
                # I'm not sure if it's already fixed or not so I'm wrapping it
                # with rescue block. If exception is raised we can assume
                # that bucket already exists.
              end

We eat any exceptions when creating a bucket, because we (blindly) assume it's an old iwhd bug. That's... probably not good.

I haven't seen this exact issue previously, and couldn't reproduce it on a fresh install using RHEL 6.2.

However, based on Jan's comments and my subsequent investigation, I think what happened is that something went wrong when using OAuth -- the keys didn't match, perhaps, or something was just broken along the chain. We inappropriately swallowed the errors that would have informed you of this, so everything appeared to work until you went to list images and realized that nothing had actually worked.

I now have a patch on the list that will cause requests to raise exceptions if HTTP errors are encountered, which is what the other code expects to happen: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-January/008486.html

As for Jan's first problem, I couldn't see any instances of creating buckets without authentication. But with the above patch, we will now raise an exception (403 - Forbidden) if you attempt to create a bucket without authentication when OAuth is enabled, so it will expose any further bugs.

Tentatively marking as POST, because I suspect the described issue (which I could not reproduce) was some sort of fluke whose root cause was masked by our inappropriate swallowing of exceptions. Please re-open if this does not appear correct.

920ad8a in rubygem-aeolus-image-0.3.0-7

Created attachment 560074 [details]
import_with_name

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2012-0583.html