OpenStack Cinder


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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 Cinder

    1. 1. OpenStack CinderRenuka Apte – Citrix Systems
    2. 2. 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
    3. 3. 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
    4. 4. 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
    5. 5. REST API• What’s supported today • create • delete • list • show• Extensions (to come) • attach • detach • reserve_volume • unreserve_volume • initialize_connection • terminate_connection
    6. 6. 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)
    7. 7. 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
    8. 8. 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
    9. 9. 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]
    10. 10. 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
    11. 11. 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
    12. 12. Incubation• Normal process • couple of releases • acceptance by community • contributions• Exception for Cinder • already an OpenStack project • nova-volume is reasonably mature and reviewed
    13. 13. Try it out• Pull devstack • git clone • 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
    14. 14. Getting Involved• Reviews• Feedback• Feature priorities• Resources: • • Progress, status, updates • Repo: • Blueprints: • • • Mailing list: • with [Openstack][Cinder] on subject line • Meetings: • Wednesdays at 16:00 UTC