Jump to: navigation, search

Difference between revisions of "Shares Service"

Line 12: Line 12:
 
Please note the following [[OpenStack]] standard definition of terms (this glossary is repurposed from a separate blueprint and is included here for consistency and to eliminate conflict over term definitions):
 
Please note the following [[OpenStack]] standard definition of terms (this glossary is repurposed from a separate blueprint and is included here for consistency and to eliminate conflict over term definitions):
  
−
disk: block-based storage read and written by a virtual machine
+
* disk: block-based storage read and written by a virtual machine
−
 
+
* ephemeral disk: a disk that is stored locally on the hypervisor host; will be discarded if the VM is shut down and on failures
−
ephemeral disk: a disk that is stored locally on the hypervisor host; will be discarded if the VM is shut down and on failures
+
* disk image: a sequence of bytes managed by Glance, copied to local storage by Nova to create an ephemeral disk
−
 
+
* volume: persistent (non-ephemeral) block-based storage.  Note that this definition may (and often does) conflict with vendor-specific definitions.
−
disk image: a sequence of bytes managed by Glance, copied to local storage by Nova to create an ephemeral disk
+
* block device mapping: means by which a VM launched by Nova determines disks are attached to it, including both ephemeral disks and persistent volumes
−
 
 
−
volume: persistent (non-ephemeral) block-based storage
 
−
 
 
−
block device mapping: means by which a VM launched by Nova determines disks are attached to it, including both ephemeral disks and persistent volumes
 
  
 
== Background ==
 
== Background ==
Line 35: Line 31:
 
Concordant with the transition from nova-volume to Cinder, the opportunity to define a broader vision for storage provisioning in [[OpenStack]] exists.  An expanded vision for Cinder is both appropriate for an independent project / service in [[OpenStack]] and is also timely given a variety of user driven requirements advocating for expanded capabilities.  We propose and intend to act to evolve Cinder as the canonical storage provisioning control plane in [[OpenStack]] independent of storage protocol type (whether block or file).  This proposal and associated blueprints intend to, in phases, accommodate file-based storage as well.  Please note that object storage is not considered in scope given well established API and mechanisms (i.e. Swift). This blueprint should be treated as an overarching / umbrella design document with separate blueprints defined for each of the phases and to also account for "whole experience" interaction.
 
Concordant with the transition from nova-volume to Cinder, the opportunity to define a broader vision for storage provisioning in [[OpenStack]] exists.  An expanded vision for Cinder is both appropriate for an independent project / service in [[OpenStack]] and is also timely given a variety of user driven requirements advocating for expanded capabilities.  We propose and intend to act to evolve Cinder as the canonical storage provisioning control plane in [[OpenStack]] independent of storage protocol type (whether block or file).  This proposal and associated blueprints intend to, in phases, accommodate file-based storage as well.  Please note that object storage is not considered in scope given well established API and mechanisms (i.e. Swift). This blueprint should be treated as an overarching / umbrella design document with separate blueprints defined for each of the phases and to also account for "whole experience" interaction.
  
−
The subordinate blueprints:
+
== Blueprints ==
  
−
# File-based Volume Driver
+
The master blueprint is here: [https://blueprints.launchpad.net/cinder/+spec/cinder-protocol-enhancements Cinder Protocol Enhancements]
−
# Extension of the Cinder API
 
−
# Extended API Reference Driver
 
−
# Absorption of provisioned NAS to instances
 
−
# Quantum Support
 
  
 
=== 1) File-Based Volume Driver ===
 
=== 1) File-Based Volume Driver ===
Line 47: Line 39:
 
Implementation of a Cinder file-based volume driver.  This makes use of files as virtual block devices for mounted file systems already present at the hypervisor.  The hypervisor would still present the file into the instance as a block device.   
 
Implementation of a Cinder file-based volume driver.  This makes use of files as virtual block devices for mounted file systems already present at the hypervisor.  The hypervisor would still present the file into the instance as a block device.   
  
−
https://blueprints.launchpad.net/cinder/+spec/nfs-files-as-virtual-block-devices
+
[https://blueprints.launchpad.net/cinder/+spec/nfs-files-as-virtual-block-devices Allow the use of NFS files as virtual block devices]
  
 
Note: the above provides generic NFS support as a reference implementation
 
Note: the above provides generic NFS support as a reference implementation
  
−
https://blueprints.launchpad.net/cinder/+spec/netapp-nfs-cinder-driver
+
[https://blueprints.launchpad.net/cinder/+spec/netapp-nfs-cinder-driver NetApp-NFS Driver for Cinder]
  
 
=== 2) Extension of the Cinder API ===
 
=== 2) Extension of the Cinder API ===
  
−
Extension of the Cinder API (http://api.openstack.org) to accommodate:
+
Extension of the [http://api.openstack.org Cinder API] to accommodate:
  
−
* creation of filesystems (e.g. the create API would need to support a "protocol" & likely a permissions "mask" and "ownership" parameter)
+
* Creation of filesystems (e.g. the create API needs to support a "protocol" & a permissions "mask" and "ownership" parameters)
−
* mounting filesystems (e.g. via extension of the attach API to accommodate mount semantics or
+
* Mounting filesystems
−
* possibly by creating an additional & separate "mount" call, additional provision to accommodate specifying and passing specific mount options)
+
* Creation & deletion of snapshots & clones
−
* creation & deletion of snapshots
+
* Unmounting filesystems
−
* unmounting filesystems
+
* Deletion of filesystems
−
* deletion of filesystems
 
  
 
==== Proposed API description: ====
 
==== Proposed API description: ====
  
−
Create share:
+
'''Create share:'''
−
CLI:
+
 
−
cinder share-create [--snapshot_id <snapshot_id>] [--display_name <display_name>] [--display_description <display_description>] <share_protocol> <size>
+
CLI: <code><nowiki>cinder share-create [--snapshot_id <snapshot_id>] [--display_name <display_name>] [--display_description <display_description>] <share_protocol> <size></nowiki></code>
 +
 
 
Note: snapshot id should be used when creating new share from snapshot is required.
 
Note: snapshot id should be used when creating new share from snapshot is required.
 +
 +
Request: <code><nowiki>POST /v1/<tenant_id>/shares</nowiki></code>
 +
 +
Body:<code><nowiki> {"snapshot_id": null, "display_name": "sh0", "proto": "cifs", "display_description": null, "size": 1}}' </nowiki></code>
 +
 +
Successful response code: <code><nowiki>200</nowiki></code>
 +
 +
Response body: <code><nowiki> '{"share": {"status": "creating", "display_name": "sh0", "share_type": "CIFS", "export_location": null, "id": "d596078a-7bfb-4977-b10d-2cf5528e708d", "size": 1}}' </nowiki></code>
 +
 +
'''Delete share:'''
 +
 +
<code><nowiki> cinder share-delete <share_id> </nowiki></code>
 +
 +
Request: <code><nowiki>DELETE /v1/<tenant_id>/shares/<share_id></nowiki></code>
 +
 +
Body: <code><nowiki>None</nowiki></code>
 +
 +
Successful response code: <code><nowiki>200</nowiki></code>
 +
 +
Response body: <code><nowiki>None</nowiki></code>
 +
 +
'''List shares:'''
 +
 +
<code><nowiki>cinder share-list</nowiki></code>
  
 
Request:
 
Request:
−
POST /v1/<tenant_id>/shares
+
<code><nowiki>GET /v1/<tenant_id>/shares/detail</nowiki></code>
−
Body: {"snapshot_id": null, "display_name": "sh0", "proto": "cifs", "display_description": null, "size": 1}}'
+
 
−
Successful response code: 200
+
Body: <code><nowiki>None</nowiki></code>
 +
 
 +
Successful response code: <code><nowiki>200</nowiki></code>
 +
 
 
Response body:
 
Response body:
−
'{"share": {"status": "creating", "display_name": "sh0", "share_type": "CIFS", "export_location": null, "id": "d596078a-7bfb-4977-b10d-2cf5528e708d", "size": 1}}'
+
<code><nowiki> '{"shares": [{"status": "available", "display_name": "sh1", "share_type": "NFS", "export_location": "172.18.194.81:/opt/nfs/volume-9d908180-f9ea-42b2-9079-88a59ade5339", "id": "9d908180-f9ea-42b2-9079-88a59ade5339", "size": 1}, {"status": "available", "display_name": "sh0", "share_type": "CIFS", "export_location": "//172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971", "id": "adcc79e4-336c-4ad2-9d38-2b65d062d971", "size": 1}]}' </nowiki></code>
 +
 
 +
'''Show share:'''
  
−
Delete share:
+
<code><nowiki>cinder share-show <share_id></nowiki></code>
−
cinder share-delete <share_id>
 
  
 
Request:
 
Request:
−
DELETE /v1/<tenant_id>/shares/<share_id>
+
<code><nowiki>GET /v1/<tenant_id>/shares/<share_id></nowiki></code>
−
Body: None
+
 
−
Successful response code: 200
+
Body: <code><nowiki>None</nowiki></code>
−
Response body: None
 
  
−
List shares:
+
Successful response code: <code><nowiki>200</nowiki></code>
−
cinder share-list
 
  
−
Request:
 
−
GET /v1/<tenant_id>/shares/detail
 
−
Body: None
 
−
Successful response code: 200
 
 
Response body:
 
Response body:
−
'{"shares": [{"status": "available", "display_name": "sh1", "share_type": "NFS", "export_location": "172.18.194.81:/opt/nfs/volume-9d908180-f9ea-42b2-9079-88a59ade5339", "id": "9d908180-f9ea-42b2-9079-88a59ade5339", "size": 1}, {"status": "available", "display_name": "sh0", "share_type": "CIFS", "export_location": "//172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971", "id": "adcc79e4-336c-4ad2-9d38-2b65d062d971", "size": 1}]}'
+
<code><nowiki> '{"share": {"status": "available", "display_name": "sh0", "share_type": "CIFS", "export_location": "//172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971", "id": "adcc79e4-336c-4ad2-9d38-2b65d062d971", "size": 1}}' </nowiki></code>
  
−
Show share:
+
'''Allow access to share:'''
−
cinder share-show <share_id>
 
  
−
Request:
+
<code><nowiki> cinder share-allow <share_id> <access_type> <access_to> </nowiki></code>
−
GET /v1/<tenant_id>/shares/<share_id>
 
−
Body: None
 
−
Successful response code: 200
 
−
Response body:
 
−
'{"share": {"status": "available", "display_name": "sh0", "share_type": "CIFS", "export_location": "//172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971", "id": "adcc79e4-336c-4ad2-9d38-2b65d062d971", "size": 1}}'
 
  
−
Allow access to share:
 
−
cinder share-allow <share_id> <access_type> <access_to>
 
 
Note: access_type and access_to depends from the backend. For task4 only 'ip' type is implemented.
 
Note: access_type and access_to depends from the backend. For task4 only 'ip' type is implemented.
  
 
Request:
 
Request:
−
POST /v1/<tenant_id>/shares/<share_id>/action
+
<code><nowiki> POST /v1/<tenant_id>/shares/<share_id>/action </nowiki></code>
−
Body: {"os-access_allow": {"access_type": "ip", "access_to": "10.0.1.*"}}'
+
 
−
Successful response code: 202
+
Body: <code><nowiki> {"os-access_allow": {"access_type": "ip", "access_to": "10.0.1.*"}}' </nowiki></code>
−
Response body: None
+
 
 +
Successful response code: <code><nowiki>202</nowiki></code>
 +
 
 +
Response body: {{None</nowiki></pre>
 +
 
 +
 
 +
'''Deny access to share:'''
 +
 
 +
<code><nowiki>cinder share-deny <share_id> <access_rule_id></nowiki></code>
  
−
Deny access to share:
 
−
cinder share-deny <share_id> <access_rule_id>
 
 
Request:
 
Request:
−
POST /v1/<tenant_id>/shares/<share_id>/action
+
<code><nowiki>POST /v1/<tenant_id>/shares/<share_id>/action</nowiki></code>
−
Body: {"os-access_deny": {"access_id": "20"}}
+
 
−
Successful response code: 202
+
Body: <code><nowiki> {"os-access_deny": {"access_id": "20"}} </nowiki></code>
−
Response body:
+
 
−
None
+
Successful response code: <code><nowiki>202</nowiki></code>
 +
 
 +
Response body: <code><nowiki>None</nowiki></code>
 +
 
 +
'''List share access rules:'''
  
−
List share access rules:
+
<code><nowiki>cinder share-access-list <share_id></nowiki></code>
−
cinder share-access-list <share_id>
 
  
 
Request:
 
Request:
−
POST /v1/<tenant_id>/shares/<share_id>/action
+
 
−
Body: {"os-access_list": null}
+
<pre><nowiki> POST /v1/<tenant_id>/shares/<share_id>/action
−
Successful response code: 200
+
 
 +
Body: {"os-access_list": null} </nowiki></pre>
 +
 
 +
 
 +
Successful response code: <code><nowiki>200</nowiki></code>
 +
 
 
Response body:
 
Response body:
−
'{"access_list": [{"state": "active", "id": 20, "access_type": "ip", "access_to": "10.0.0.*"}, {"state": "active", "id": 21, "access_type": "ip", "access_to": "10.0.1.*"}]}'
+
<code><nowiki> '{"access_list": [{"state": "active", "id": 20, "access_type": "ip", "access_to": "10.0.0.*"}, {"state": "active", "id": 21, "access_type": "ip", "access_to": "10.0.1.*"}]}' </nowiki></code>
 +
 
 +
'''Create snapshot from share:'''
  
−
Create snapshot from share:
+
<code><nowiki>cinder snapshot-create [--force <True|False>] [--display_name <display_name>] [--display_description <display_description>] <volume_id></nowiki></code>
−
cinder snapshot-create [--force <True|False>] [--display_name <display_name>] [--display_description <display_description>] <volume_id>
 
  
 
Request:
 
Request:
−
POST /v1/<tenant_id>/snapshots
+
<code><nowiki>POST /v1/<tenant_id>/snapshots</nowiki></code>
−
Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}}
+
 
−
Successful response code: 200
+
Body: <code><nowiki> {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}} </nowiki></code>
 +
 
 +
Successful response code: <code><nowiki>200</nowiki></code>
 +
 
 
Response body:
 
Response body:
−
{"snapshot": {"status": "creating", "display_name": "snap0", "created_at": "2012-08-21 11:25:44.668712", "display_description": null, "source_type": "NFS", "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f", "id": "b8531da9-de22-4df0-8e40-ffbe7d290811", "size": 1}}
+
<code><nowiki> {"snapshot": {"status": "creating", "display_name": "snap0", "created_at": "2012-08-21 11:25:44.668712", "display_description": null, "source_type": "NFS", "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f", "id": "b8531da9-de22-4df0-8e40-ffbe7d290811", "size": 1}} </nowiki></code>
  
−
Snapshot delete:
+
''' Snapshot delete:'''
−
cinder snapshot-delete <snapshot_id>
+
 
 +
<code><nowiki> cinder snapshot-delete <snapshot_id> </nowiki></code>
  
 
Request:
 
Request:
−
DELETE /v1/<tenant_id>/snapshots/<snapshot_id>
+
 
−
POST /v1/<tenant_id>/snapshots
+
<pre><nowiki> DELETE /v1/<tenant_id>/snapshots/<snapshot_id>
−
Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}}
+
POST /v1/<tenant_id>/snapshots </nowiki></pre>
−
Successful response code: 200
+
 
 +
 
 +
<code><nowiki> Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}} </nowiki></code>
 +
 
 +
Successful response code: <code><nowiki> 200 </nowiki></code>
 +
 
 
Response body:
 
Response body:
  
−
Snapshots list:
+
'''Snapshots list:'''
−
cinder snapshot-list
+
 
 +
<code><nowiki>cinder snapshot-list</nowiki></code>
  
 
Request:
 
Request:
−
GET /v1/<tenant_id>/snapshots/detail
+
 
−
Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}}
+
<code><nowiki>GET /v1/<tenant_id>/snapshots/detail</nowiki></code>
−
Successful response code: 200
+
 
 +
Body: <code><nowiki> {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}} </nowiki></code>
 +
 
 +
Successful response code: <code><nowiki>200</nowiki></code>
 +
 
 
Response body:
 
Response body:
−
{"snapshots": [{"status": "available", "display_name": "snap0", "created_at": "2012-08-21 11:25:44", "display_description": null, "id": "b8531da9-de22-4df0-8e40-ffbe7d290811", "source_type": "NFS", "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f", "os-extended-snapshot-attributes:progress": "100%", "os-extended-snapshot-attributes:project_id": "cc629b78b21142699a36ee0749749720", "size": 1}]}
+
<code><nowiki> {"snapshots": [{"status": "available", "display_name": "snap0", "created_at": "2012-08-21 11:25:44", "display_description": null, "id": "b8531da9-de22-4df0-8e40-ffbe7d290811", "source_type": "NFS", "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f", "os-extended-snapshot-attributes:progress": "100%", "os-extended-snapshot-attributes:project_id": "cc629b78b21142699a36ee0749749720", "size": 1}]} </nowiki></code>
  
 
=== 3) Extended API Reference Driver ===
 
=== 3) Extended API Reference Driver ===

Revision as of 15:10, 1 October 2012

  • Launchpad Entry: cinder-protocol-enhancements
  • Created: 29 Sep 2012
  • Contributors: Robert Esker, Ben Swartzlander

Introduction

This document is intended to vet a concept and establish a vision for extending Cinder capabilities. More detailed blueprints (in Launchpad) and further detail in this specification will follow as necessary.

Glossary

Please note the following OpenStack standard definition of terms (this glossary is repurposed from a separate blueprint and is included here for consistency and to eliminate conflict over term definitions):

  • disk: block-based storage read and written by a virtual machine
  • ephemeral disk: a disk that is stored locally on the hypervisor host; will be discarded if the VM is shut down and on failures
  • disk image: a sequence of bytes managed by Glance, copied to local storage by Nova to create an ephemeral disk
  • volume: persistent (non-ephemeral) block-based storage. Note that this definition may (and often does) conflict with vendor-specific definitions.
  • block device mapping: means by which a VM launched by Nova determines disks are attached to it, including both ephemeral disks and persistent volumes

Background

Cinder characteristics

  • The OpenStack Cinder project separates the former nova-volume into an independent service for Folsom and beyond.
  • Instances can be created from ephemeral disks or volumes presently
  • Creating an ephemeral disk is done by Nova downloading the specified disk image from Glance over HTTP, writing it to local (to the hypervisor) storage
  • Ad hoc requests for storage, whether by running instances or outside of the Nova context can be accommodated either programmatically against the Cinder API or via the python-cinderclient tool.
  • Cinder, in the initial form and as a legacy of nova-volume, provides a block only construct.

High-level proposal

Concordant with the transition from nova-volume to Cinder, the opportunity to define a broader vision for storage provisioning in OpenStack exists. An expanded vision for Cinder is both appropriate for an independent project / service in OpenStack and is also timely given a variety of user driven requirements advocating for expanded capabilities. We propose and intend to act to evolve Cinder as the canonical storage provisioning control plane in OpenStack independent of storage protocol type (whether block or file). This proposal and associated blueprints intend to, in phases, accommodate file-based storage as well. Please note that object storage is not considered in scope given well established API and mechanisms (i.e. Swift). This blueprint should be treated as an overarching / umbrella design document with separate blueprints defined for each of the phases and to also account for "whole experience" interaction.

Blueprints

The master blueprint is here: Cinder Protocol Enhancements

1) File-Based Volume Driver

Implementation of a Cinder file-based volume driver. This makes use of files as virtual block devices for mounted file systems already present at the hypervisor. The hypervisor would still present the file into the instance as a block device.

Allow the use of NFS files as virtual block devices

Note: the above provides generic NFS support as a reference implementation

NetApp-NFS Driver for Cinder

2) Extension of the Cinder API

Extension of the Cinder API to accommodate:

  • Creation of filesystems (e.g. the create API needs to support a "protocol" & a permissions "mask" and "ownership" parameters)
  • Mounting filesystems
  • Creation & deletion of snapshots & clones
  • Unmounting filesystems
  • Deletion of filesystems

Proposed API description:

Create share:

CLI: cinder share-create [--snapshot_id <snapshot_id>] [--display_name <display_name>] [--display_description <display_description>] <share_protocol> <size>

Note: snapshot id should be used when creating new share from snapshot is required.

Request: POST /v1/<tenant_id>/shares

Body: {"snapshot_id": null, "display_name": "sh0", "proto": "cifs", "display_description": null, "size": 1}}'

Successful response code: 200

Response body: '{"share": {"status": "creating", "display_name": "sh0", "share_type": "CIFS", "export_location": null, "id": "d596078a-7bfb-4977-b10d-2cf5528e708d", "size": 1}}'

Delete share:

cinder share-delete <share_id>

Request: DELETE /v1/<tenant_id>/shares/<share_id>

Body: None

Successful response code: 200

Response body: None

List shares:

cinder share-list

Request: GET /v1/<tenant_id>/shares/detail

Body: None

Successful response code: 200

Response body: '{"shares": [{"status": "available", "display_name": "sh1", "share_type": "NFS", "export_location": "172.18.194.81:/opt/nfs/volume-9d908180-f9ea-42b2-9079-88a59ade5339", "id": "9d908180-f9ea-42b2-9079-88a59ade5339", "size": 1}, {"status": "available", "display_name": "sh0", "share_type": "CIFS", "export_location": "//172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971", "id": "adcc79e4-336c-4ad2-9d38-2b65d062d971", "size": 1}]}'

Show share:

cinder share-show <share_id>

Request: GET /v1/<tenant_id>/shares/<share_id>

Body: None

Successful response code: 200

Response body: '{"share": {"status": "available", "display_name": "sh0", "share_type": "CIFS", "export_location": "//172.18.194.81/volume-adcc79e4-336c-4ad2-9d38-2b65d062d971", "id": "adcc79e4-336c-4ad2-9d38-2b65d062d971", "size": 1}}'

Allow access to share:

cinder share-allow <share_id> <access_type> <access_to>

Note: access_type and access_to depends from the backend. For task4 only 'ip' type is implemented.

Request: POST /v1/<tenant_id>/shares/<share_id>/action

Body: {"os-access_allow": {"access_type": "ip", "access_to": "10.0.1.*"}}'

Successful response code: 202

Response body: {{None</nowiki></pre>


Deny access to share:

cinder share-deny <share_id> <access_rule_id>

Request: POST /v1/<tenant_id>/shares/<share_id>/action

Body: {"os-access_deny": {"access_id": "20"}}

Successful response code: 202

Response body: None

List share access rules:

cinder share-access-list <share_id>

Request: 

 POST /v1/<tenant_id>/shares/<share_id>/action

Body: {"os-access_list": null}


Successful response code: 200

Response body: '{"access_list": [{"state": "active", "id": 20, "access_type": "ip", "access_to": "10.0.0.*"}, {"state": "active", "id": 21, "access_type": "ip", "access_to": "10.0.1.*"}]}'

Create snapshot from share:

cinder snapshot-create [--force <True|False>] [--display_name <display_name>] [--display_description <display_description>] <volume_id>

Request: POST /v1/<tenant_id>/snapshots

Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}}

Successful response code: 200

Response body: {"snapshot": {"status": "creating", "display_name": "snap0", "created_at": "2012-08-21 11:25:44.668712", "display_description": null, "source_type": "NFS", "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f", "id": "b8531da9-de22-4df0-8e40-ffbe7d290811", "size": 1}}

Snapshot delete:

cinder snapshot-delete <snapshot_id>

Request: 

 DELETE /v1/<tenant_id>/snapshots/<snapshot_id>
POST /v1/<tenant_id>/snapshots


Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}}

Successful response code: 200

Response body:

Snapshots list:

cinder snapshot-list

Request:

GET /v1/<tenant_id>/snapshots/detail

Body: {"snapshot": {"display_name": "snap0", "force": false, "display_description": null, "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f"}}

Successful response code: 200

Response body: {"snapshots": [{"status": "available", "display_name": "snap0", "created_at": "2012-08-21 11:25:44", "display_description": null, "id": "b8531da9-de22-4df0-8e40-ffbe7d290811", "source_type": "NFS", "volume_id": "7cd97eb7-6d55-418d-964c-858a6bee9d2f", "os-extended-snapshot-attributes:progress": "100%", "os-extended-snapshot-attributes:project_id": "cc629b78b21142699a36ee0749749720", "size": 1}]}

3) Extended API Reference Driver

Creation of a reference Cinder driver for shared file system use under the proposed expanded API. As an example, a NetApp driver for this would be able to advertise, accept, and respond to requests for NFSv3, NFSv4, NFSv4.1 (w/ pNFS), & contemporary CIFS / SMB protocols (eg versions 2, 2.1, 3). Additional modification of python-cinderclient will be necessary to provide for the expanded array of request parameters.

4) Control of NAS Storage Mounting from Cinder

Proposal for handling injection / updates of mounts to instantiated guests operating in the Nova context. A listener / agent that could either be interacted directly or more likely poll or receive updates from instance metadata changes would represent one possible solution.

5) Quantum Support

Full consideration for cross-instance network encapsulation as part of a Quantum & Keystone integrated security model.

Retrieved from "https://wiki.openstack.org/w/index.php?title=Shares_Service&oldid=3426"