Project

General

Profile

Create and Maintain S3 feature list for compatibility tracking » History » Version 1

Jessica Mack, 06/07/2015 12:40 AM

1 1 Jessica Mack
h1. Create and Maintain S3 feature list for compatibility tracking
2
3
h3. Summary
4
5
Create a detailled page, listing each feature of S3, with the link to the S3 documentation, it's implementation status in Ceph, and links to the code and the tests of this features, would give a better visibility to developpers what's missing, but also to users what's working.
6
7
h3. Owners
8
9
* Name (Affiliation)
10
* Name (Affiliation)
11
* Name
12
13
h3. Interested Parties
14
15
* Christophe Courtaut <christophe.courtaut@gmail.com>
16
* Loic Dachary <loic@dachary.org>
17
* Yehuda Sadeh (Inktank)
18
* Danny Al-Gaaf
19
* Name
20
21
h3. Current Status
22
23
As of now, the documentation page about S3 Api ( http://eu.ceph.com/docs/next/radosgw/s3/ ) is not accurate, and only contains a very brief list of feature, and if it is supported or not.
24
 
25
h3. Detailed Description
26
27
The main idea is to maintain a list of S3 Features, with links to the amazon documentation, the status of the ceph implementation, links to the code and the tests that implements it.
28
A draft page live here :  https://github.com/kri5/ceph/blob/wip-s3-compliance-doc/doc/radosgw/s3_compliance.rst
29
It is divided in multiple parts, which one reflects the Amazon S3 API documentation : http://docs.aws.amazon.com/AmazonS3/...I/APIRest.html . To track the evolution of the API, a static mirror of the web pages is updated on a regular basis and published as soon as a diff shows. A custom script is likely to be needed to get rid of the page cosmetic elements. Based on the diff, someone would have to copy paste the differences so that they can be acted upon later on.
30
Each part of the documentation is represented by a table, in which we will have the following columns :
31
32
p((. - Header (For HTTP Header documentation only)
33
34
p((. - Type (For HTTP Request only) -> GET / POST / PUT / DELETE / HEAD / OPTIONS
35
36
p((. - Operation (For HTTP Request only)
37
38
p((. - Supported -> Yes / No / Partial / N/A
39
40
p((. - Code Links -> Links to the implementation of the feature
41
42
p((. - Tracker Links -> Links to the http://tracker.ceph.com/ issue matching the implementation
43
44
p((. - Tests Links -> Links to the tests related to the feature
45
46
For each Operation ( for instance "List Multipart Uploads":http://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadListMPUpload.html ) the list of parameters should also be listed with a checkbox showing if it is supported or not. A link to a relevant part of the code helps check the actual implementation when it's there and helps implement the missing parameters that should probably be implemented in the same area of the code base.
47
"Bucket restrictions and limitations":http://docs.aws.amazon.com/AmazonS3/2006-03-01/dev/BucketRestrictions.html and other transversal rules / behavior should be listed and matched against code such as the one stating that a bucket name can "only start with a number, letter and underscore":https://github.com/ceph/ceph/blob/master/src/rgw/rgw_rest_s3.cc#L1906 and highlight that underscore is not allowed by S3 to start a bucket name.
48
In order to help with the maintenance, the permalink to the table entry matching the S3 feature would have to be inserted as a comment in the code. For instance
49
  @// https://github.com/kri5/ceph/blob/wi...ons-on-buckets@
50
Would allow the developer to run the following to quickly find the entry point as well as the history:
51
@git log --stat --patch -S 's3_compliance.rst#operations-on-buckets'@
52
 
53
A use case of this list could be:
54
* a casual developer sees the list
55
* (s)he sees response element KeyMarker of List multipart bucket is missing. Clicks on the link describing it, in the table.
56
* it looks achievable and (s)he clicks on the link to the area where it should probably be implemented. Gives it a try and submit a pull request.
57
58
As mentionned earlier, this is a draft, and the format might evolve. 
59
Tip: A Very useful plugin for vim to edit rst tables : https://github.com/nvie/vim-rst-tables
60
61
h3. Work items
62
63
h3. Coding tasks
64
65
# script to track the S3 api changes
66
# Add tests to s3-tests for unsupported features (https://github.com/ceph/s3-tests)
67
68
h3. Documentation tasksEdit section
69
70
# Create a page which list all S3 Feature
71
# Check S3 feature implementation status in RGW.
72
# For each task, link to the implementation code, and the tests.
73
# Replace  http://eu.ceph.com/docs/next/radosgw/s3/ with the new document
74
# mark the entry points of each feature in the code