The OpenStack Object Store is a facility that lets applications store and retrieve binary objects using the RESTful methods of the Swift API — this scales better than OS-level access to block storage and conventional file systems.
OpenStack Object Storage can be installed either on one server or multi server for development or testing purposes, a multiple-server installation enables the higher availability and redundancy you want in a production distributed object storage system. Accounts, containers, and objects in the Object Storage system can be managed.
To know more details about its installation procedure, refer to Installing OpenStack Object Storage
We are now ready to test our installation of OpenStack Object Storage, and we can achieve this in a couple of ways—by using curl and using the swift command-line utility.
Subscribe to our youtube channel to get new updates..!
Ensure that you are logged in to your swift virtual machine. To accomplish this, run:
How to achieve it…
In this recipe, we will use the swift command to test connectivity with OpenStack Object Storage.
Using a swift command to test OpenStack Object Storage:
The swift client is the command-line interface (CLI) for the Object Storage service API and its extensions. The Swift engine is the default back-end for the Object Store, and is also used by Glance for storing images in HA deployments.
Rather than seeing the web service output, we can use the command-line tool swift (previously known as st) to ensure that we have a working setup. Note that the output matches the reply headers seen, when queried using curl.
swift -A https://172.16.0.200:5000/v2.0 -U service:swift -K swift -V 2.0 stat
You should see the following output:
How it works…
OpenStack Object Storage is a web service, so we can use traditional command-line web clients to troubleshoot and verify our OpenStack Object Storage installation. This becomes very useful for debugging OpenStack Object Storage at this low level, just as you would debug any web service.
The swift command uses the credentials, we supplied while building the proxy-server.conf. In turn, this command authenticates us against the keystone and then lists the statistics of that container.