[Openstack-docs] Compute | Networking | Storage refactoring

John Garbutt John.Garbutt at citrix.com
Tue Aug 7 11:22:58 UTC 2012


I like the distinction between Block Storage and Object Storage, and I think the docs should reflect the sets of things the administrators will deploy.
- I would document Swift as a stand-a-lone doc on Object Storage, with information on how to integrate with Keystone.
- I think Quantum could be deployed separately, so document how Quantum works, and how it integrates with Keystone.
- Then the compute doc would then tell you how nova uses Glance, Cinder, Quantum, Keystone. Given Glance and Cinder are probably not deployed stand-alone, I would cover their docs in the Compute doc.

About storage, I like to think in terms of the VM life cycle:
1) When you start a VM where do you boot from (i.e. where does the VM's root disk come from):
- image in glance
- snapshot in glance
- volume (i.e. a disk provided by cinder)
2) A VM can then have extra disk attached using the hypervisor. These are Volumes, managed by Cinder, attached by Nova
3) A VM can mount any storage it wants, just like any other machine, like mounting an NFS share. OpenStack is not involved here.

Notes:
A) When you boot from an image or snapshot from glance it gets copied to the hypervisor's storage (ephemeral disks also go here):
- local disk (the common case for cloud workloads) - if hypervisor fails, you lose the disk
- shared storage (more common for traditional workloads) - often used by hypervisors to implement live-migration and HA features
B) The image from glance can be stored in many places, but common options are:
- reliable block storage, such as swift or s3
- use file backend with storage mounted from somewhere else
C) The volume is managed by glance, provides access to blocks. The hypervisor connects to this storage using:
- iSCSI
- some other remote block storage protocol (like sheepdog / Ceph RBD etc)

Thanks,
John

> -----Original Message-----
> From: John Garbutt
> Sent: Tuesday, August 7, 2012 11:56 AM
> To: John Garbutt
> Subject: FW: [Openstack-docs] Compute | Networking | Storage refactoring
> 
> 
> 
> From: Anne Gentle [mailto:anne at openstack.org]
> Sent: Tuesday, August 7, 2012 12:27 AM
> To: Razique Mahroua
> Cc: openstack-docs at lists.openstack.org
> Subject: Re: [Openstack-docs] Compute | Networking | Storage refactoring
> 
> 
> On Thu, Aug 2, 2012 at 6:02 AM, Razique Mahroua
> <razique.mahroua at gmail.com> wrote:
> Hi guys,
> the confusing thing about "Storage" is that there are two (maybe more to come)
> projects - swift and Glance. Storage is rather an abstract term when it comes to
> those services since both can operate the same way datas, but both serve
> originally different purposes.
> 
> Interesting, I hadn't thought of Glance as a "storage" option but it does store
> and retrieve images so I guess it could be thought of that way. I see it more as
> Storage: block or object. Then you have decisions to make about what you store
> your images in - block or object storage or just on disk on your cloud controller I
> guess?
> 
> Though, since both could be deployed autonomously, it could be more a "data
> management " category ?
> or "Data storing" ? glance being originally designated as the "imaging service "
> Same goes for Cinder actually
> 
> Right, and the Ceph project confuses me too so that'll be a tough one to sort
> out. :) I started bringing in that long blog entry and just wasn't sure whether to
> bring it all in or not.
> 
> As for keystone, I think it could have its own topic, being the only one all the OPS
> services aim to/ should use from now on.
> 
> Now that's interesting - I don't think it should be its own top-level topic, but
> shared modules/chapters throughout. Anyone else have opinions on the Identity
> portion?
> 
> 
> BTW : any news about Atlas ?
> that ring a (weak) bell, but not so sure
> 
> Atlas was a load balancing project, and I think the new load balancing project is
> going to use the Atlas API spec.
> 
> 
> Razique
> 
> Nuage & Co - Razique Mahroua
> razique.mahroua at gmail.com
> 
> 
> 
> Le 28 juil. 2012 à 05:51, Lorin Hochstein <lorin at nimbisservices.com> a écrit :
> 
> 
> On Jul 26, 2012, at 9:48 AM, Anne Gentle <anne at openstack.org> wrote:
> 
> 
> Hi all -
> I'd like to propose an approach to the organization of the docs site
> centered around three "needs" for readers:
> 
> Compute
> Networking
> Storage
> 
> I believe the benefits of this top-level approach give us reuse of
> content and easier finding of what people seek. It's not a huge
> refactoring since I see it as:
> 
> Compute Administration
> Networking Administration
> Storage Administration
> 
> While these books do exist, the need is in the content itself to be
> modular so it can be shared. For example, the Storage Administration
> guide only describes Object Storage, not Block Storage.
> 
> Sounds like a reasonable approach to me. Of course, there will be difficult
> choices ("Is glance part of Compute or Storage? Where does Keystone go, since
> it cuts across?") But, like David Weinberger says, "Everything is Miscellaneous".
> We'll just need to have good cross-reference links across the docs as needed.
> 
> 
> 
> One concern is I don't want to confuse Object Storage (Swift)
> operators by inserting a lot of Volume information where they don't
> need it. But I do believe that we need to round out the coverage of
> documentation.
> 
> I think as long as block storage and object storage are clearly delineated, this
> will be fine. And Ceph crosses block and object storage, so it will have a clear
> home here.
> 
> 
> This question leads into, how do we document installing and
> configuring networking WITH computing (quantum with nova)? How are
> people getting this information now?
> 
> This is something I'd like to know as well. How do you configure quantum? Or
> how about cinder?
> 
> 
> 
> I'd love some feedback on how to move forward with the addition of
> core projects but the lack of integrated how-to-configure
> documentation. I'll be happy to propose a patch with the refactor, but
> it will mean less patching of Essex, I believe.
> 
> Thanks for your input,
> Anne
> 
> I fear we'll probably have to troll through the devstack source. :(
> 
> 
> Take care,
> 
> Lorin
> --
> Lorin Hochstein
> Lead Architect - Cloud Services
> Nimbis Services, Inc.
> www.nimbisservices.com
> 
> 
> 
> 
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> 



More information about the Openstack-docs mailing list