[SRU] Swift bucket X-Timestamp not set by Rados Gateway
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Cloud Archive |
Invalid
|
Undecided
|
Unassigned | ||
Mitaka |
Fix Released
|
High
|
Unassigned | ||
ceph (Ubuntu) |
Fix Released
|
High
|
Frode Nordahl | ||
Xenial |
Fix Released
|
High
|
Unassigned | ||
Yakkety |
Fix Released
|
High
|
Unassigned | ||
Zesty |
Fix Released
|
High
|
Frode Nordahl |
Bug Description
[Impact]
* A basic characteristic of a object store is the ability to create
buckets and objects and to query for information about said
buckets and objects.
* In the current version of the ceph radosgw package it is not
possible to get creation time for buckets. This is a serious
defect and makes it impossible to use Ubuntu with ceph as a
object store for some applications.
* The issue has been fixed in upstream master
* The proposed debdiff solves the issue by including patches cherry
picked and adapted from upstream master branch fixing this issue.
[Test Case]
* Use Juju to deploy Ceph cluster with radosgw and relation to OpenStack
Keystone. Example bundle: http://
* Install OpenStack Swift client
sudo apt-get install python-swiftclient
* Load OpenStack Credentials pointing to your test deployment
wget https:/
. novarc
* Create swift bucket
swift post test
* Display information about newly created bucket
swift stat test
* Observe that key 'X-Timestamp' has value 0.0
* Delete bucket
swift delete test
* Install patched radosgw packages on 'ceph-radosgw' unit and repeat
* Verify that key 'X-Timestamp' now has a value > 0.0 and corrensponding
to the unixtime of when you created the bucket.
[Regression Potential]
* The patch is simple and I see little potential for any regression as a
result of it being applied.
[Original bug description]
When creating a swift/radosgw bucket in horizon the bucket gets created, but shows up with a creation date of 19700101
In the apache log one can observe
curl -i http://
Container HEAD failed: http://
However a manual curl call succeeds. Also the radosgw.log shows successful PUT/GET requests.
I get similar results using the swift command line utility with containers inheriting a creation date of 19700101 even though I can see the correct date being passed to rados in the headers of the request.
Also similarly issues with ceilometer intergration, similarly linked:
2016-05-31 06:28:16.931 1117922 WARNING ceilometer.
2016-05-31 06:28:16.931 1117922 ERROR ceilometer.
This is using charm version: 86 against Openstack Mitaka
This also seems pretty reproduceable with any ceph, ceph-rados and mitaka install via the juju charms.
summary: |
- Mitaka - Ceilometer-agent is unable to authenticate against the - objectstore endpoint (rados-gw) + Mitaka - Issues authenticating against radosgw + bucket creation date of + 19700101 |
description: | updated |
Changed in ceph (Ubuntu): | |
status: | New → Confirmed |
tags: | added: sts |
Changed in ceph (Ubuntu): | |
assignee: | nobody → Frode Nordahl (fnordahl) |
description: | updated |
summary: |
- Swift container X-Timestamp not set by Rados Gateway + [SRU] Swift container X-Timestamp not set by Rados Gateway |
description: | updated |
description: | updated |
description: | updated |
summary: |
- [SRU] Swift container X-Timestamp not set by Rados Gateway + [SRU] Swift bucket X-Timestamp not set by Rados Gateway |
Changed in ceph (Ubuntu Zesty): | |
status: | Confirmed → In Progress |
tags: | added: sts-sru |
description: | updated |
Changed in ceph (Ubuntu Zesty): | |
status: | In Progress → Fix Released |
Changed in ceph (Ubuntu Zesty): | |
status: | Fix Released → In Progress |
Changed in cloud-archive: | |
status: | New → Invalid |
Changed in ceph (Ubuntu Zesty): | |
importance: | Undecided → High |
Changed in ceph (Ubuntu Xenial): | |
importance: | Undecided → High |
Changed in ceph (Ubuntu Yakkety): | |
importance: | Undecided → High |
tags: | added: verification-done-yakkety |
tags: |
added: sts-sru-done removed: sts-sru |
Hi Benjamin, i'm currently looking into the timestamp issue you have observed and will update this bug if/once i find anything. With regards to the "404 Not Found" in the logs, I think this is expected as I have seen the same behaviour with the swift when running with --debug so as to see headers and response. Basically when creating a resource the client first checks (GET) to see if it exists and if it does not (i.e. it gets a 404 Not Found) then it sends a new request to create the resource e.g. container/bucket.