The storlets API is an extension of the Swift API. In some cases we use the Swift API as is. For example, uploading a storlet is done using Swift upload to a designated container. In other cases we add storlets specific headers to existing Swift operations. For example invoking a storlet on download is done by adding the ‘X-Run-Storlet’ header to the Swift download operation.
Storlets are stored to a special container called ‘storlet’.
Note
The name of the container where storlets are uploaded to is configurable. The name ‘storlet’ is the default.
[GET] /v1/{account}/storlet
The body of the response contains a list of the names of the uploaded storlets. The Content-type of the response is (text/plain).
storlet1.jar
storlet2.jar
storlet3.jar
You may write a storlet in Java or Python according to the instructions in the storlet developer guide and upload it to the Object Store. The storlet is uploaded to the container named ‘storlet’, so ‘/storlet’ appears in the url. The storlet may depend on other existing libraries, which must be uploaded to the ‘dependency’ container.
Note
Once again, the name ‘dependency’ is a default, and can be configured differently.
When uploading a storlet, the X-Object-Meta-Storlet-Dependency header requires a value that is a comma separated list of dependencies. The main_class_name parameter for the X-Object-Meta-Storlet-Main header specifies the class in which the invoke method of the storlet is defined. For python written storlets, this parameter should be prefixed with the python module name. For example, if the storlet file is named ‘mystorlet.py’, then the class name must be ‘mystorlet.<class name>’. The X-Object-Meta-Storlet-Language header specified the language in which the storlet is run. Either “Python” or “Java” is available for the value. The X-Object-Meta-Storlet-Interface-Version header should be provided and set to the value ‘1.0’. Although not currently used, the X-Object-Meta-Storlet-Object-Metadata header must be provided and set to ‘no’. See the Storlets Developer’s manual for details of the signature of the invoke method. The content-type of the request should be set to ‘application/octet-stream’.
[PUT] /v1/{account}/storlet/{storlet_object_name}
For Java written storlets
'X-Object-Meta-Storlet-Language' : 'Java'
'X-Object-Meta-Storlet-Interface-Version' : '1.0'
'X-Object-Meta-Storlet-Dependency': dependencies
'X-Object-Meta-Storlet-Object-Metadata' : 'no'
'X-Object-Meta-Storlet-Main': {main_class_name}
'X-Auth-Token': {authorization_token}
For Python written storlets
'X-Object-Meta-Storlet-Language' : 'Python'
'X-Object-Meta-Storlet-Interface-Version' : '1.0'
'X-Object-Meta-Storlet-Dependency': dependencies
'X-Object-Meta-Storlet-Object-Metadata' : 'no'
'X-Object-Meta-Storlet-Main': {module_name.class_name}
'X-Auth-Token': {authorization_token}
You may create and upload your own libraries to assist in running a storlet. These dependencies are uploaded to a special container named ‘dependency’. For an executable dependency (such as a compiled c program), you must specify the X-Object-Meta-Storlet-Dependency-Permissions header. Otherwise, that header may be omitted. The name of the library containing the dependency (i.e. dependency_name) goes into the URI. The content-type of the request should be set to ‘application/octet-stream’.
[PUT] /v1/{account}/dependency/{dependency_object_name}
'X-Object-Meta-Storlet-Dependency-Version': '1'
'X-Object-Meta-Storlet-Dependency-Permissions' : '0755'
'X-Auth-Token': {authorization_token}
Once the storlet and its dependencies are deployed the storlet is ready for invocation. Storlets can be invoked in 3 ways:
Below is the API reference of the abovementioned invocations.
[GET] /v1/{account}/{container}/{object}
An additional header (‘X-Run-Storlet’) must be provided to inform the system to run a storlet.
'X-Run-Storlet': {storlet_name}
'X-Auth-Token': {authorization_token}
One may also provide parameters to the storlet. There are two ways to send parameters:
Through the URL query string. For instance: /v1/{account}/{container}/{object}?param1=val1¶m2=val2
Through the request headers. For instance:
'X-Storlet-Parameter-1': 'param1:val1' 'X-Storlet-Parameter-2': 'param2:val2'
Parameters that start with ‘storlet_’ are not allowed. The ‘storlet_’ prefix is reserved for internal system use.
To invoke a storlet on a range of an object use the ‘X-Storlet-Range’ header. For instance:
'X-Storlet-Range': 'bytes=1-6'
‘X-Storlet-Range’ can take any value that Swift can take for the HTTP ‘Range’ header as described in <http://developer.openstack.org/api-ref-objectstorage-v1.html>. Specifying HTTP ‘Range’ header together with ‘X-Run-Storlet’ is not allowed, and results in ‘400 Bad Request’
Note
In case the object happens to be an SLO the storlet is invoked over the entire object data. Thus, the storlet is invoked on a proxy node.
It is possible to invoke a storlet on GET over more then one object. This is done using the ‘X-Storlet-Extra-Resources’ header, that can be used to specify a comma separated list of object paths of the form <container>/<object>. Currently, cross account extra resources are not supported. In the below GET example the multi input storlet will get 3 object input streams.
[GET] /v1/AUTH_1234/my_container/myobject_1
'X-Run-Storlet': 'multiinputstorlet-1.0.jar'
'X-Storlet-Extra-Resources': 'my_other_container/my_other_object', 'my_other_other_container/my_other_other_object'
'X-Auth-Token': {authorization_token}
When using ‘X-Storlet-Extra-Resources’ the storlet is invoked on a proxy node.
Note
Refer to the multi-input-storlet source for writing a storlet that processes multiple inputs.
[PUT] /v1/{account}/{container}/{object}
An additional header (‘X-Run-Storlet’) must be provided to inform the system to run a storlet.
'X-Run-Storlet': {storlet_name}
'X-Auth-Token': {authorization_token}
As with the invocation upon download, one may provide parameters to the storlet either through the URL query string or through the request headers.
Object copy in Swift can be done using both the PUT and the COPY verbs as shown below
[PUT] /v1/{account}/{container}/{object}
'X-Copy-From': {source container}/{source object}
[COPY] /v1/{account}/{container}/{object}
'Destination': {dest container}/{dest object}
An additional header (‘X-Run-Storlet’) must be provided to inform the system to run a storlet.
'X-Run-Storlet': {storlet_name}
'X-Auth-Token': {authorization_token}
In the PUT case the storlet acts upon the object appearing in the ‘X-Copy-From’ header, creating the object appearing in the request path. In the COPY case the storlet acts upon the object appeairng in the requets path, crating the object appearing in the ‘Destination’ header.
Independently of the verb used to invoke a copy, one can add the ‘X-Storlet-Extra-Resources’ header. Thus, one can e.g. create an object which is a concatenation of the copy source and the extra resources. As with the invocation upon downlod, when using extra resources, the storlet is invoked on a proxy node.
Use the ‘X-Storlet-Run-On-Proxy’ header to enforce the engine to invoke the storlet on the proxy, e.g.:
'X-Storlet-Run-On-Proxy': ''
Storlets ACLs are an extension to Swift’s container read acl that allow to give users access to data through a storlet. In other words, a certain user may not have access to read objects from a container unless the access is done through a specific storlet. Setting storlets ACLs is done using the POST verb on a container as follows:
[POST] /v1/{account}/{container}
X-Storlet-Container-Read: {user_name}
X-Storlet-Name: {storlet_name}
X-Auth-Token: {authorization_token}
Currently, a storlet ACL can be set only for a single user. Storlets ACLs can be viewed as any other container read ACL by performing HEAD request on the container. The ACL will be shown as .r:storlets.<user_name>_<storlet_name> as part of the Container-Read-ACL.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.