stub account response output missing policy information

Bug #1632171 reported by clayg
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
New
Low
Praveen N

Bug Description

The standard stub response from a not-yet-vivified account response looks like this:

    ubuntu@saio:~$ curl -H 'x-auth-token: AUTH_tkb60a7daaa81f431d8bfe0336f664c25f' http://saio:8080/v1/AUTH_test2 -I
    HTTP/1.1 204 No Content
    Content-Type: text/plain; charset=utf-8
    X-Account-Object-Count: 0
    X-Timestamp: 1476148431.41888
    X-Account-Bytes-Used: 0
    X-Account-Container-Count: 0
    X-Put-Timestamp: 1476148431.41888
    Content-Length: 0
    X-Trans-Id: tx90aebc67fe2e468bbb58d-0057fc3ccf
    Date: Tue, 11 Oct 2016 01:13:51 GMT

all of the container/object count/bytes are filled in with default zeros

it stays this way even after you add metadata:

    ubuntu@saio:~$ curl -H 'x-auth-token: AUTH_tkb60a7daaa81f431d8bfe0336f664c25f' http://saio:8080/v1/AUTH_test2 -I
    HTTP/1.1 204 No Content
    Content-Length: 0
    X-Account-Object-Count: 0
    X-Account-Meta-Color: blue
    X-Timestamp: 1476148443.33746
    X-Account-Bytes-Used: 0
    X-Account-Container-Count: 0
    Content-Type: text/plain; charset=utf-8
    Accept-Ranges: bytes
    X-Trans-Id: tx607b229846a44c1bb261a-0057fc3cdd
    Date: Tue, 11 Oct 2016 01:14:05 GMT

But once you create a container in a storage policy you start to see additional stats show up for those policies:

    ubuntu@saio:~$ curl -H 'x-auth-token: AUTH_tkb60a7daaa81f431d8bfe0336f664c25f' http://saio:8080/v1/AUTH_test2 -I
    HTTP/1.1 204 No Content
    Content-Length: 0
    Accept-Ranges: bytes
    X-Account-Object-Count: 0
    X-Account-Storage-Policy-Default-Bytes-Used: 0
    X-Account-Meta-Color: blue
    X-Account-Storage-Policy-Default-Object-Count: 0
    X-Timestamp: 1476148443.34108
    X-Account-Bytes-Used: 0
    X-Account-Container-Count: 1
    Content-Type: text/plain; charset=utf-8
    X-Account-Storage-Policy-Default-Container-Count: 1
    X-Trans-Id: tx62a71784ec5b42e18cd3b-0057fc3d76
    Date: Tue, 11 Oct 2016 01:16:38 GMT

... and they stay there even if you delete the container:

    ubuntu@saio:~$ curl -H 'x-auth-token: AUTH_tkb60a7daaa81f431d8bfe0336f664c25f' http://saio:8080/v1/AUTH_test2 -I
    HTTP/1.1 204 No Content
    Content-Length: 0
    Accept-Ranges: bytes
    X-Account-Object-Count: 0
    X-Account-Storage-Policy-Default-Bytes-Used: 0
    X-Account-Meta-Color: blue
    X-Account-Storage-Policy-Default-Object-Count: 0
    X-Timestamp: 1476148443.33131
    X-Account-Bytes-Used: 0
    X-Account-Container-Count: 0
    Content-Type: text/plain; charset=utf-8
    X-Account-Storage-Policy-Default-Container-Count: 0
    X-Trans-Id: txe3bac046f7924ba4ac0ea-0057fc3d86
    Date: Tue, 11 Oct 2016 01:16:54 GMT

This dynamism makes it a little hard to set expectations for new clients (e.g. lp bug #1622138)

Praveen N (praveenn)
Changed in swift:
assignee: nobody → Praveen N (praveenn)
Revision history for this message
HCLTech-SSW (hcltech-ssw) wrote :

Hi Clay,

As we have analyzed this issue, if we want to fix this issue then it can be accomplished when all the container would be deleted from that account, then account stat can be reverted to the initial stage.

Please confirm.

Revision history for this message
HCLTech-SSW (hcltech-ssw) wrote :
Download full text (3.4 KiB)

Hi Clay,

Further investigation are as follows:

We have executed and verified the following steps to reproduce this bug with some findings:

1. Executed the stat command using curl on a new account AUTH_test.
   curl -H 'x-auth-token: <authentication-token>' http://<ip-address>:8080/v1/AUTH_test -I

   HTTP/1.1 204 No Content
   Content-Type: text/plain; charset=utf-8
   X-Account-Object-Count: 0
   X-Timestamp: 1509346141.91633
   X-Account-Bytes-Used: 0
   X-Account-Container-Count: 0
   X-Put-Timestamp: 1509346141.91633
   Content-Length: 0

We found that no account database file is created, and hence the proxy server is giving the fake account list in the response from proxy-server (controller/account.py).

2. Executed the command to create a container on account AUTH_test.
   curl -X PUT -H 'x-auth-token: <authentication-token>' http://<ipaddress>:8080/v1/AUTH_test/newContainer -I

   HTTP/1.1 201 Created
   Content-Length: 0
   Content-Type: text/html; charset=UTF-8

3. Again executed the stat command on account AUTH_test.
   curl -H 'x-auth-token: <authentication-token>' http://<ip-address>:8080/v1/AUTH_test -I

   HTTP/1.1 204 No Content
   Content-Length: 0
   X-Account-Object-Count: 0
   X-Account-Meta-Colour: blue
   X-Account-Storage-Policy-Policy-0-Bytes-Used: 0
   X-Account-Storage-Policy-Policy-0-Container-Count: 1
   X-Timestamp: 1509346208.41299
   X-Account-Storage-Policy-Policy-0-Object-Count: 0
   X-Account-Bytes-Used: 0
   X-Account-Container-Count: 1
   Content-Type: application/json; charset=utf-8
   Accept-Ranges: bytes

We found that during container creation, the policy stat table is also updated and one account database file is created.

4. Executed the delete container command on account AUTH_test.
   curl -X DELETE -H 'x-auth-token: <authentication-token>' http://<ip address>:8080/v1/AUTH_test/newContainer -I

   HTTP/1.1 204 No Content
   Content-Length: 0
   Content-Type: text/html; charset=UTF-8

We found that the container related stats have been updated along with policy stat table and account database file is still present.

5. Again executed the stat command on account AUTH_test.
   curl -H 'x-auth-token: <authentication-token>' http://<ip-address>:8080/v1/AUTH_test -I

   HTTP/1.1 204 No Content
   Content-Length: 0
   X-Account-Object-Count: 0
   X-Account-Meta-Colour: blue
   X-Account-Storage-Policy-Policy-0-Bytes-Used: 0
   X-Account-Storage-Policy-Policy-0-Container-Count: 0
   X-Timestamp: 1509346208.41299
   X-Account-Storage-Policy-Policy-0-Object-Count: 0
   X-Account-Bytes-Used: 0
   X-Account-Container-Count: 0
   Content-Type: application/json; charset=utf-8
   Accept-Ranges: bytes

Since in stat command, the account server is reading contents from the account_stat and policy_stat table from account database file, so it is giving information about account-storage policy.

6. To recheck we just renamed the physically presented account data file, and then executed the stat command again.
   curl -H 'x-auth-token: <authentication-token>' http://<ip-address>:8080/v1/AUTH_test -I

   HTTP/1.1 204 No Content
   Content-Type: text/plain; charset=utf-8
   X-Account-Object-C...

Read more...

Revision history for this message
clayg (clay-gerrard) wrote :

I think everything you described is correct. I guess the "bug" as it were was just that the policy stats rows don't exist for storage policies you're not using and when the account is created you're not using any policies?

Maybe that's just won't fix - and lp bug #1622138 is just a doc bug that the initial response for a new account won't have any per-policy stats until you're using a storage policy...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.