Mirantis OpenStack Express — REST Access to Object Store

This is the twelfth in a series of short tutorials showing how to perform common cloud operations tasks in Mirantis OpenStack Express — Mirantis’ “Private Cloud as a Service”

In our last video, we showed you a little bit about how the Swift Object Store works and tweaked a parameter to fully-enable Public objects in Mirantis OpenStack Express. Now we’ll look a little deeper at Swift from a RESTful perspective.

Step by Step

Developers who want to write applications that access OpenStack APIs are mostly going to work with one of the many SDKs available -- we’ve linked a list of these at the end of this article. When starting out, though, it’s interesting to play with OpenStack REST functions via a terminal, using a tool like cURL that allows rapid iteration.

To start this exercise, let’s log into our MOX cloud’s controller node as root by leapfrogging in using Fuel. On our Dashboard, click the Credentials link, grab the Fuel Master Node’s IP address, and SSH to fuel@(that IP). Supply the password. Then look in Fuel’s GUI for the Fully-Qualified Domain Name (FQDN) of your cloud’s Controller: mine is node-5. SSH from Fuel to root@(FQDN) -- no password is required this time. Then enter source openrc to align your shell session with the OpenStack APIs.

Log into your Controller node as before, by leapfrogging in via the Fuel Master Node using the IP address in your Mirantis OpenStack Express dashboard's Credentials tab. SSH from Fuel to the Controller. Then enter source openrc to copy authentication into your environment for the CLIs and clients.

Last time, we used the CLI Swift client command swift stat -v to get info about the Public URL of our container and its Swift Storage URL. This time, we’re going to authenticate RESTfully, straight to Keystone’s internal address from the Controller’s command line.

The swift stat -v command returns your StorageURL and an Auth Token. But it's also possible to authenticate to Keystone directly, using a REST command, and recover both a token and the service catalog.

We can find the internal IP address of Keystone through Horizon, by clicking on Admin, then on System Info, and bringing up the Services tab

You can find the internal address of your Keystone in Horizon, under System Info's Services tab.

Now let’s compose the command we’ll use to authenticate. The simplest way to request a token is to get one that’s ‘unscoped’ — meaning that it lets us do anything our account is permissioned to do. This is okay for querying Keystone, but it’s dangerous to use an unscoped token to access storage and other important subsystems. So instead, we’re going to use a longer form authentication request that lets us get back a project-scoped token mdash; one that will let us access and modify objects belonging to the admin project, but not those belonging to other projects.

This is the cURL expression we'll use:

curl -D "headers.txt" -H "Content-Type: application/json" -d '{ "auth": {"identity": {"methods": ["password"],"password": {"user": {"name": "admin","domain": { "id": "default" },"password": "secretsecret"}}},"scope": {"project": {"name": "admin","domain": { "id": "default" }}}}}' http://192.168.0.10:5000/v3/auth/tokens | python -mjson.tool > pretty.json

The auth function we’re invoking is going to hand us back our token in the header of the response, assigned to the variable X-Subject-Token. So we use the -D command to designate a separate file in which curl will save headers.

The -H command includes a header with the request, identifying the kind of response payload we want to get back: json data.

The -d command identifies the json dataset we’re sending to Keystone. Note that this is an expanded form of the json for a default token: it conveys the username, password, and the project — since we’re admin, that’s called admin.

At the end, we put the internal URL for Keystone and the port (5000), appending to this URL /v3/auth/tokens — the function we’re calling. Finally, we’re piping the response body (just the json we get back) to a handy python tool (which you’ll find already present on your Controller node) that parses json data and ‘pretty-prints’ it — we’re going to save this output in the file pretty.json, for review.

Returned Data

We can extract our token from the saved header file.

Issuing an appropriate cURL command nets you a project-scoped Auth Token, passed back in the X-Subject-Token header of the response.

And if we read down the json body, we can also find the Public URL for the object-store. Or we can extract the Public URLs for all components with grep and awk, or parse the json with whatever language we’re using.

We've saved a formatted version of the JSON response body, which contains the service catalog. It's easy to scroll down and find the Public URL for your Object Store.

Composing a cURL expression with token and Storage URL, appending the name of our container (DemoContainer) gets us a listing of the container's contents: our image file, image.png.

Given the token and the Public URL, you can compose a cURL command to list the contents of any container in your project.

In our next tutorial, we’ll dive deeper into Mirantis OpenStack Express VPNaaS. Thanks for watching!

Resources:

• Mirantis OpenStack Express 2.0 Documentation
• Mirantis OpenStack Express Operations Guide
• OpenStack Command-Line Reference
• OpenStack Object Storage API v1 Reference
• API Examples Using cURL
• OpenStack SDKs for Popular Languages

Check out Express for yourself at https://express.mirantis.com.