Overview
Qumulo Core is a scale-out file storage system. A cluster of nodes presents one namespace over NFS, SMB and S3, and the system is built around continuously maintained analytics: rather than walking the tree to find out where capacity went, the cluster keeps running aggregates so an administrator can see capacity, file counts and throughput broken down by directory in real time. That directory-level accounting is Qumulo’s distinguishing feature, and it is exposed through the same REST API used for cluster, node, quota and share administration.
The ReadyWorks connector calls that API through the json_rest_api.php driver. Unlike the username and password connectors elsewhere in the storage set, this one authenticates with a bearer token: you paste a Qumulo access token into the Bearer Token field and ReadyWorks sends it as Authorization: Bearer on the call. The token is stored encrypted against the connection. You also supply the API domain of the cluster and a server-side working path used while responses are parsed.
In an estate context, the directory analytics are what make this feed worth having. Most storage inventories tell you a volume is 80 percent full. Qumulo can tell you which directory tree grew, which means ReadyWorks can attribute unstructured data growth to a team, a project or an application rather than to a mount point. Combined with quota and share records, that supports capacity chargeback, identifies the trees that dominate a migration’s data-transfer window, and gives a defensible basis for archive and deletion decisions.
The connector is registered as bidirectional. Inbound jobs pull cluster data into staging tables. The outbound side posts a record from ReadyWorks to an endpoint you nominate and captures status, message and record key from the reply. Neither direction ships with a Qumulo endpoint configured.
NOTE: Qumulo access tokens are issued and revoked on the cluster. ReadyWorks stores the token you paste in and does not renew it, so a token with an expiry will stop the connection working on the day it lapses with no warning from the estate side.
Connector Properties
Authentication Methods
Qumulo offers a single authentication method, and it is token-based rather than password-based.
Method 1: Bearer Token (QUMULO_84742fb39b)
Connect to a GET method API with a bearer token
Sends a Qumulo access token as an Authorization: Bearer header on the call. Generate the token on the cluster against a service account with read access to the endpoints you plan to collect, and record where it was issued so it can be revoked without hunting for it if the connection is ever decommissioned.
Connection Configuration Fields (5)
Authentication Configuration
Headers sent on the authentication call:
cURL options:
NOTE: The Bearer Token field is marked optional even though it carries the only credential this method has. Saving a connection with the field blank produces a connection that authenticates with an empty token.
Inbound Job Fields Enabled (44)
Inbound jobs expose the full REST field set, including three levels of enumeration and all five pagination modes.
NOTE: Several labels and tooltips in this form carry defects inherited from the shared ETL5 field templates: the Enumeration 1 Node label reads “Enumaration”, the Append New Data label reads “Exisiting”, and the help text on Enumeration 1 Keys End Point and Enumeration 3 Fields both refer to enumeration 2. The underlying fields behave as their labels say.
Outbound Job Fields Enabled (13)
Outbound jobs expose the REST posting field set, including the outbound field list, the return data mapping and an optional raw JSON body template.
Inbound Job Templates (1)
Qumulo ships one inbound template, and it is the generic REST skeleton rather than a cluster or analytics pull.
Job Template Configuration
Settings
Outbound Job Templates (1)
One outbound template ships, and it is the matching generic REST skeleton.
Job Template Configuration
Settings
Job Parameters and Enumeration
Rest POST API
Outbound fields list:
Return data fields: