I will be talking about Cinder, what it is, why it is, who’s involved. I’ll go a little bit into the API. We’ll talk a little more in detail about the attach & detach calls. The interesting thing here is that attach and detach need both nova-volume and compute to cooperate. That is also the case for boot from volume, so we’ll talk a bit about that. I’ll talk about what we’ve achieved so far, what’s left, and how you can get involved.
Cinder is the name given to the project to break out nova-volume into its own service, much like quantum is to nova-network.Cinder has a RESTful web api, so the idea is to make it independent of nova.The features we want to see added to Nova-volume, and some of these already exist, are beginning to make it a pretty complex service.For example, we need an intelligent scheduler, which is able to differentiate between storage backends based on capabilities like whether it supports snapshots, what kind of performance it has.We want to see multiple volume drivers work together, which also ties in with the scheduler.We want to be able to convert image templates into bootable volumes, which potentially involves talking to glance.All of these things make nova-volume complex enough to warrant making it a service of its own.
John Griffith’s the interim lead for Cinder until actual elections, etc. begin for the project.Most of the companies here have their proprietary storage offerings.
Normally, for a project to be accepted as an Openstack project, it needs to go through an incubation process. This typically involves a couple of releases, the community should actively begin using it and contributing. In case of cinder, however, they made an exception, similar to quantum. Because nova-volume is reasonably mature and has community participation. And the idea is to make cinder, at least in its initial versions, as close as possible to the existing nova-volume service.
OpenStack CinderRenuka Apte – Citrix Systems
Overview• What is Cinder• Who’s Involved• API• nova-volume attach/detach now & ahead• Boot from volume now & ahead• Current Status• What’s left & timeline• How to get involved
What is Cinder• Service that was previously nova-volume• REST based API• Why? • Increasing Complexity in nova-volume • Scheduler • Multiple volume drivers working together • Interactions with other components, e.g. glance
Who’s Involved• SolidFire • John Griffith• Rackspace • Vish, Jesse Andrews, Anthony Young, Nirmal Ranganathan…• HP • Tim Reddin, Duncan Thomas• Ceph • Josh Durgin• Zadara • Vladimir Popovski• NetApp • Rob Esker• Citrix • Renuka Apte
Current Flow of Attach/DetachCalls• user attach • compute.api reserve_volume (sets attaching state) casts to manager • compute.manager initialize_connection (gets connection info) • compute.manager attach (sets instance_id and attach state • (unreserve_volume called on error)• user detach • compute.api casts to manager • compute.manager terminate_connection • compute_manager detach (removes instance_id and attach state) • (unreserve_volume called during terminate)
Future Flow (tentative)• user attach • compute_api initialize_connection (sets instance_id, attaching state, gets connection info) • starts greenthread (optionally, could be sync as well) • makes call to manager passing down connection info • attach (sets instance_id and attach state) • creates bdm data• user detach • compute_api starts greenthread (optionally, could be sync as well) • detach (sets detaching state) • makes call to manager • terminate_connection (clears instance_id and attach state) • destroys bdm data
Boot from Volume, now• Current state • nova boot [--flavor <flavor>] [--image <image>] [-- block_device_mapping <dev_name=mapping>] <name> • The format of mapping is <dev_name=<id>:<type>:<size(GB)>:<delete_on_terminate>• Current way of creating bootable volumes • get the image from url or template from swift • create a nova-volume • attach it to a running instance • cp/dd
Boot from Volume, ahead• Considerations • Who should create bootable volume? • Should cinder be a client to glance or replicate functionality for streaming templates?• Boot from Volume • Create a bootable Volume • Option #1: Create Volume from an Image (or snapshot?) • cinder create-volume-from-image --image_id=[image_id] • Option #2: Mark an existing volume as bootable • Launch an instance from that Volume • nova boot --from_volume=[vol_id]
Current Status• Use cinder to create/delete/list/show volumes• python-cinderclient works • Runs against nova-volume and cinder • Supports create/delete/list/show• Can point devstack to install cinder • create/delete volumes• QA • Jenkins, smokestack on checkins • pep8, unit tests and hacking checks
In the Pipeline• Folsom-2 • Volume decoupling • API extensions • attach • detach • reserve_volume • unreserve_volume • initialize_connection • terminate_connection • Separate volume api• Further up • Boot from volume
Incubation• Normal process • couple of releases • acceptance by community • contributions• Exception for Cinder • already an OpenStack project • nova-volume is reasonably mature and reviewed
Try it out• Pull devstack • git clone https://github.com/openstack-dev/devstack.git • cd devstack • git review –d 7042• Edit localrc • In ENABLED_SERVICES, replace n-vol (if it exists, else add) cinder • Also add c-api, c-vol, c-sch• Run stack.sh
Getting Involved• Reviews• Feedback• Feature priorities• Resources: • http://etherpad.openstack.org/cinder-worksheet • Progress, status, updates • Repo: https://github.com/openstack/cinder/ • Blueprints: • https://blueprints.launchpad.net/nova/+spec/volume-decoupling • https://blueprints.launchpad.net/cinder • Mailing list: • email@example.com with [Openstack][Cinder] on subject line • Meetings: • Wednesdays at 16:00 UTC