Managing Cloud ONTAP programmatically through REST

Recently, we’ve announced Cloud ONTAP – a virtual clustered Data ONTAP that runs in Amazon's EC2 and uses Amazon's EBS as the underlying disks. By using SnapMirror/SnapVault, it is now possible to transfer datasets seamlessly between on-premise data centers and AWS:

 

cdot_snapmirror.jpg

 

OnCommand Cloud Manager (OCCM) will be the tool to configure and deploy Cloud ONTAP. It will also give capabilities to help configuring NetApp Private Storage for AWS in its first release. Basic provisioning functionalityfor Cloud ONTAP is provided by OCCM (e.g., creating a NetApp volume including an NFS export). Traditional management of the system should be performed through the new version of the on-box System Manager, OnCommand Unified Manager, automation tools (e.g., OnCommand Workflow Automation), or through ONTAP's own APIs. OCCM will be available free of charge through the AWS Marketplace or through NetApp directly. If you want to test-drive Cloud ONTAP and OnCommand Cloud Manager, have a look at poc.netapp.com.

 

In this post, we’ll have a quick look on how to create, monitor and administer Cloud ONTAP instances through OnCommand Cloud Manager’s REST API.

 

The full REST documentation for OCCM can be found at (hostname is the IP/hostname of the OCCM instance): 

https://<hostname>/occm/api-doc/

Let's first authenticate and get our token. In a production enviroment, obviously make sure to follow best practices for using secured connections: 

USER='myuser@foo.com'
PASSWORD='supersecret'

curl --request POST \
     --cookie-jar "cookies.txt" \
     --header "Accept: application/json" \
     --header "Content-Type: application/json" \
     --data "{\"email\":\"$USER\", \"password\":\"$PASSWORD\" }" \
     --insecure \
     'https://<hostname>:443/occm/api/auth/login'

Now that we're authenticated, let's retrieve some information about our current user: 

curl --request GET \
     --cookie "cookies.txt" \
     --header "Accept: application/json" \
     --insecure \
     'https://<hostname>:443/occm/api/auth/current-user'

Response: 

{
 "publicId":"User-1",
 "workingEnvironments":[],
 "firstName":"Al",
 "lastName":"Bundy",
 "email":"myemail@foo.com",
 "roleId":"Role-1",
 "consumerId":null,
 "hasKeys":true,
 "s3Bucket":"myownbucketforbilling"
}

Let's check if we already have some instances of Cloud ONTAP running: 

curl --request GET \
     --cookie "cookies.txt" \
     --header "Accept: application/json" \
     --insecure \
     'https://<hostname>:443/occm/api/working_environments/vsa'

Response: 

[
  {
    "vsaId":"Vsa-xxxxxx",
    "publicId":"VsaWorkingEnvironment-xxxxx",
    "name":"test",
    "consumerId":"Consumer-2345",
    "cloudProviderName":"amazon",
    "regionName":"us-east-1",
    "instancesCount":3,
    "reservedSize":{"size":0.0,"unit":"GB"},
    "vpcId":"vpc-xxxxxxx",
    "svmName":"svm_test",
    "status":"AVAILABLE",
    "activeActions":null,
    "encryptVolume":false,
    "instanceState":"running",
    "workingEnvironmentType":"VSA"
  }
]

We can get the status of an instance by calling: 

curl --request GET \
     --cookie "cookies.txt" \
     --header "Accept: application/json" \
     --insecure \
     'https://<hostname>:443/occm/api/vsa/Vsa-7qBp3f0b/state'

Response: 

{
  "state":"stopped",
  "activeActions":null
}

By calling the start/stop API, we can bring up or shut down an instance: 

curl --request POST \
     --cookie "cookies.txt" \
     --header "Accept: application/json" \
     --header "Content-Type: application/json" \
     --insecure \
     'https://<hostname>:443/occm/api/vsa/Vsa-7qBp3f0b/start'

As the holy grail, let's create a Cloud ONTAP instance from scratch:

curl --request POST \
     --cookie "cookies.txt" \
     --header "Accept: application/json" \
     --header "Content-Type: application/json" \
     --data "{\"name\": \"testforblog\", \"keyPair\": { \"name\": \"my_aws_keypair\" }, \"vpcId\": \"vpc-xxxxxx\", \"description\": \"Test Env for Blog Post\", \"svmPassword\": \"supersecret\", \"subnetId\": \"subnet-d2xxxxx\", \"cloudType\": { \"instanceType\": \"m3.xlarge\", \"capacityLimit\": { \"size\": 2, \"unit\": \"TB\" }, \"requiresLicense\": false }, \"platformLicense\": null, \"encryptVolume\": false, \"region\": \"us-east-1\", \"consumerId\": \"Consumer-2345\", \"svmUserName\": \"admin\", \"volume\": { \"name\": \"my_application\", \"tier\": { \"name\": \"GP2\", \"iops\": 3000 }, \"enableCompression\": true, \"enableDeduplication\": true, \"exportPolicy\": \"all\", \"enableThinProvisioning\": true, \"sizeGb\": 50, \"snapshotPolicyName\": \"default\" }}" \
     --insecure \
     'https://<hostname>:443/occm/api/working_environments/vsa'

 

If you think this post was helpful or if you have questions, feel free to leave a comment!

 

Clemens

Comments
Frequent Contributor

Hi Clemens,

 

Great post.  I've been starting to play around with the OnCommand Cloud Manager REST APIs and your info on the topic was a helpful little primer.

 

I think there might be a syntax error or perhaps a change in the syntax with OCCM (I'm using 2.1.0) 

 

     'https://<hostname>:443/occm/api/auth/current_user'

 Should be... "-" rather than "_"

 

     'https://<hostname>:443/occm/api/auth/current-user'

Thanks again,

Tony

Frequent Contributor

Hi Tony,

 

I've updated the post, thanks for the comment. I think you are right, the API might have changed a little bit since the first release.

 

Regards,

Clemens