<div>One of the first steps needed to help decouple volumes from Nova, is to</div><div>define what the Openstack Volume API should look like.  I would like to start</div><div>by discussing the main api endpoints, and discussing the interaction of</div>
<div>compute attaching/detaching from volumes.</div><div><br></div><div>All of the following endpoints will support basic CRUD opperations similar to</div><div>others described in the Openstack 1.1 API.</div><div><br></div>
<div>/volumes</div><div>    Justin already has a pretty good start to this.  We will need to discuss</div><div>    what data we will need to store/display about volumes, but I will save</div><div>    that for a later discussion.</div>
<div><br></div><div>/snapshots</div><div>    This will allow us to expose snapshot functionality from the underlying</div><div>    storage systems.</div><div><br></div><div>/exports</div><div>    This will be used to expose a volume to be consumed by an external system.</div>
<div>    The Nova attach api call will make a call to /exports to set up a volume</div><div>    to be attached to a VM.  This will store information that is specific</div><div>    about a particular attachement (for example maybe CHAP authentication </div>
<div>    information for an iscsi export).  This helps with decoupling volumes </div><div>    from nova, and makes the attachement process more generic so that other </div><div>    systems can easily consume the volumes service.  It is also undecided if </div>
<div>    this should be a publicly available api, or just used by backend services.</div><div><br></div><div>The exports endpoint is the biggest change that we are proposing, so we would</div><div>like to solicit feedback on this idea.  </div>
<div><br></div><div>--</div><div>Chuck Thier (@creiht)</div>