DeltaCloud
  1. DeltaCloud
  2. DTACLOUD-175

Executing "HEAD /api/buckets/:bucket_id/:blob_id - returns 200 OK but no user meta_data

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Component/s: Server
    • Labels:
      None
    • Environment:

      Description

      Using deltalcoud-core-0.5.0-8:

      (>> rpm -qa |grep deltacloud
      deltacloud-core-ec2-0.5.0-8.el6.noarch
      deltacloud-core-vsphere-0.5.0-8.el6.noarch
      rubygem-deltacloud-client-0.5.0-2.el6.noarch
      deltacloud-core-0.5.0-8.el6.noarch
      deltacloud-core-rhevm-0.5.0-8.el6.noarch)

      curl -i -X HEAD --user "username:password" "http://ibm-x3200m3-01.rhts.eng.bos.redhat.com:3005/api/buckets/bucket-rlandy2/03222012blob6?format=xml"

      HTTP/1.1 204 No Content
      X-Runtime: 0.562315
      Server: Apache-Deltacloud/0.5.0
      X-Deltacloud-Blobmeta-version: 2.4
      X-Deltacloud-Blobmeta-name: myblob
      X-Deltacloud-Blobmeta-author: rlandy
      Date: Fri, 23 Mar 2012 20:06:18 GMT
      Connection: close

      Using deltacloud git commit version 7e372dfca79c02a799046287e5936129216b781b, no user meta_data is returned:

      curl -i -X HEAD --user "username:password" "http://localhost:3009/api/buckets/bucket-rlandy2/03222012blob6?format=xml"HTTP/1.1 200 OK
      X-Runtime: 0.427717
      X-Frame-Options: sameorigin
      Date: Fri, 23 Mar 2012 20:07:45 GMT
      Content-Length: 457
      X-XSS-Protection: 1; mode=block
      Content-Type: application/xml
      Server: Apache-Deltacloud/0.5.0
      Connection: keep-alive

      curl: (18) transfer closed with 457 bytes remaining to read

      Log output copied below:

      == Info: About to connect() to localhost port 3009 (#0)
      == Info: Trying 127.0.0.1... == Info: connected
      == Info: Connected to localhost (127.0.0.1) port 3009 (#0)
      == Info: Server auth using Basic with user '...'
      => Send header, 328 bytes (0x148)
      0000: HEAD /api/buckets/bucket-rlandy2/03222012blob6?format=xml HTTP/1
      0040: .1
      0044: Authorization: Basic ...
      0084: ...==
      00af: User-Agent: curl/7.21.7 (x86_64-redhat-linux-gnu) libcurl/7.21.7
      00ef: NSS/3.13.1.0 zlib/1.2.5 libidn/1.22 libssh2/1.2.7
      0123: Host: localhost:3009
      0139: Accept: /
      0146:
      <= Recv header, 17 bytes (0x11)
      0000: HTTP/1.1 200 OK
      <= Recv header, 21 bytes (0x15)
      0000: X-Runtime: 0.393294
      <= Recv header, 29 bytes (0x1d)
      0000: X-Frame-Options: sameorigin
      <= Recv header, 37 bytes (0x25)
      0000: Date: Fri, 23 Mar 2012 20:10:27 GMT
      <= Recv header, 21 bytes (0x15)
      0000: Content-Length: 457
      <= Recv header, 33 bytes (0x21)
      0000: X-XSS-Protection: 1; mode=block
      <= Recv header, 31 bytes (0x1f)
      0000: Content-Type: application/xml
      <= Recv header, 33 bytes (0x21)
      0000: Server: Apache-Deltacloud/0.5.0
      <= Recv header, 24 bytes (0x18)
      0000: Connection: keep-alive
      <= Recv header, 2 bytes (0x2)
      0000:
      <= Recv data, 0 bytes (0x0)
      == Info: transfer closed with 457 bytes remaining to read
      == Info: Closing connection #0

        Activity

        Hide
        Marios Andreou added a comment -

        Spent best part of today on this but am giving up for now for the sake of my sanity.

        Notes:

        -> cURL is generating the correct request. For some reason, HEAD /api/buckets/:bucket_name/:blob_name is actually hitting the route GET /api/buckets/:bucket_name/:blob_name

        -> The issue is specific to the machine being tested... I couldn't recreate on my local machine using the same code (fresh clone of dc git repo on both). Also reinforced by the original comment above, assuming that the machine running deltalcoud-core-0.5.0-8 is not the same as this testing machine.

        -> Interesting/weird behaviour: if you remove ALL the routes from server.rb (i.e. all 'collection :foo do' blocks) except buckets (and blob subcollection), the problem magically disappears. This would suggest an issue with Rabbit and subcollections, except the problem is not reproducible on other machines..?

        -> tried the same request with telnet and got the same behaviour:

        telnet 127.0.0.1 3001
        HEAD /api/buckets/mariosanotherbucketohyeah/someshinynewblob?format=xml HTTP/1.1
        Authorization: Basic <THE_AUTH_BLOB>
        Host: localhost:3001
        Accept: /

        HTTP/1.1 200 OK
        Content-Type: application/xml
        Server: Apache-Deltacloud/0.5.0
        X-Runtime: 1.625874
        X-XSS-Protection: 1; mode=block
        X-Frame-Options: sameorigin
        Content-Length: 679
        Date: Thu, 29 Mar 2012 11:25:58 GMT
        Connection: keep-alive

        (correct response is 204 with blob metadata in the headers)

        -> tried swapping sinatra 1.3.2 with 1.3.1 (matching what my machine is running) - no joy

        -> testing machine:

        `uname -a`: Linux qe-blade-02.idm.lab.bos.redhat.com 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

        `ruby -v`: ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

        gems: sinatra (1.3.1), thin (1.3.1), rack (1.4.1), rack-accept (0.4.4), rack-protection (1.2.0), rack-test (0.6.1), eventmachine (0.12.10), aws (2.5.6)

        Show
        Marios Andreou added a comment - Spent best part of today on this but am giving up for now for the sake of my sanity. Notes: -> cURL is generating the correct request. For some reason, HEAD /api/buckets/:bucket_name/:blob_name is actually hitting the route GET /api/buckets/:bucket_name/:blob_name -> The issue is specific to the machine being tested... I couldn't recreate on my local machine using the same code (fresh clone of dc git repo on both). Also reinforced by the original comment above, assuming that the machine running deltalcoud-core-0.5.0-8 is not the same as this testing machine. -> Interesting/weird behaviour: if you remove ALL the routes from server.rb (i.e. all 'collection :foo do' blocks) except buckets (and blob subcollection), the problem magically disappears. This would suggest an issue with Rabbit and subcollections, except the problem is not reproducible on other machines..? -> tried the same request with telnet and got the same behaviour: telnet 127.0.0.1 3001 HEAD /api/buckets/mariosanotherbucketohyeah/someshinynewblob?format=xml HTTP/1.1 Authorization: Basic < THE_AUTH_BLOB > Host: localhost:3001 Accept: / HTTP/1.1 200 OK Content-Type: application/xml Server: Apache-Deltacloud/0.5.0 X-Runtime: 1.625874 X-XSS-Protection: 1; mode=block X-Frame-Options: sameorigin Content-Length: 679 Date: Thu, 29 Mar 2012 11:25:58 GMT Connection: keep-alive (correct response is 204 with blob metadata in the headers) -> tried swapping sinatra 1.3.2 with 1.3.1 (matching what my machine is running) - no joy -> testing machine: `uname -a`: Linux qe-blade-02.idm.lab.bos.redhat.com 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux `ruby -v`: ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux] gems: sinatra (1.3.1), thin (1.3.1), rack (1.4.1), rack-accept (0.4.4), rack-protection (1.2.0), rack-test (0.6.1), eventmachine (0.12.10), aws (2.5.6)
        Hide
        Marios Andreou added a comment -

        Just tried again with current git master - this is the same as you report above (7e372dfca79c02a799046287e5936129216b781b)

        git log:
        commit 7e372dfca79c02a799046287e5936129216b781b
        Author: marios <marios@redhat.com>
        Date: Wed Mar 21 15:44:33 2012 +0200

        Bugfix - for DTACLOUD-164 - return json output for create instance action (minor logic error)

        https://issues.apache.org/jira/browse/DTACLOUD-164

        exact cURL command:

        curl -i -X HEAD --user "user:pass" http://localhost:3001/api/buckets/mariosanotherbucketohyeah/someshinynewblob?format=xml

        RESPONSE:

        HTTP/1.1 204 No Content
        X-Deltacloud-Blobmeta-zee: foo
        X-Runtime: 1.807733
        Date: Tue, 27 Mar 2012 15:42:08 GMT
        X-Deltacloud-Blobmeta-version: short_one
        X-Frame-Options: sameorigin
        X-XSS-Protection: 1; mode=block
        Server: Apache-Deltacloud/0.5.0
        X-Deltacloud-Blobmeta-author: marios
        Connection: close

        If the problem is reliably reproducible then perhaps I can try on the machine you are using for testing? E-mail me details if possible or we talk about it some more.

        Show
        Marios Andreou added a comment - Just tried again with current git master - this is the same as you report above (7e372dfca79c02a799046287e5936129216b781b) git log: commit 7e372dfca79c02a799046287e5936129216b781b Author: marios <marios@redhat.com> Date: Wed Mar 21 15:44:33 2012 +0200 Bugfix - for DTACLOUD-164 - return json output for create instance action (minor logic error) https://issues.apache.org/jira/browse/DTACLOUD-164 exact cURL command: curl -i -X HEAD --user "user:pass" http://localhost:3001/api/buckets/mariosanotherbucketohyeah/someshinynewblob?format=xml RESPONSE: HTTP/1.1 204 No Content X-Deltacloud-Blobmeta-zee: foo X-Runtime: 1.807733 Date: Tue, 27 Mar 2012 15:42:08 GMT X-Deltacloud-Blobmeta-version: short_one X-Frame-Options: sameorigin X-XSS-Protection: 1; mode=block Server: Apache-Deltacloud/0.5.0 X-Deltacloud-Blobmeta-author: marios Connection: close If the problem is reliably reproducible then perhaps I can try on the machine you are using for testing? E-mail me details if possible or we talk about it some more.
        Hide
        Ronelle Landy added a comment -

        Note from Marios:

        " ... I couldn't recreate. HEAD (command) should be giving: 204 No Content with the metadata in the headers... "

        Note from rlandy:

        Logging this issue in JIRA because I could recreate the problem with the current git master branch version. deltacloud-0.5.0-8 (CFs rpm) does not show the same problem. Perhaps this was fixed with the other fixes implemented for DTACLOUD 171-174?

        Show
        Ronelle Landy added a comment - Note from Marios: " ... I couldn't recreate. HEAD (command) should be giving: 204 No Content with the metadata in the headers... " Note from rlandy: Logging this issue in JIRA because I could recreate the problem with the current git master branch version. deltacloud-0.5.0-8 (CFs rpm) does not show the same problem. Perhaps this was fixed with the other fixes implemented for DTACLOUD 171-174?

          People

          • Assignee:
            Marios Andreou
            Reporter:
            Ronelle Landy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development