Open Stack

Did you mean EBS? I thought it was generally hard to get the same kind 
of performance from block storage that local ephemeral storage provides 
but perhaps Amazon has found a way. Life would certainly be much simpler 
with a single ephemeral backend. Storage pools 
(https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools) 
should provide some of the same benefits.

On 10/21/2014 02:54 PM, Preston L. Bannister wrote:
> As a side-note, the new AWS flavors seem to indicate that the Amazon 
> infrastructure is moving to all ECS volumes (and all flash, possibly), 
> both ephemeral and not. This makes sense, as fewer code paths and less 
> interoperability complexity is a good thing.
>
> That the same balance of concerns should apply in OpenStack, seems likely.
>
>
>
>
> On Tue, Oct 21, 2014 at 7:59 AM, Dan Genin <daniel.genin at jhuapl.edu 
> <mailto:daniel.genin at jhuapl.edu>> wrote:
>
>     Hello,
>
>     I would like to add to DevStack the ability to stand up Nova with
>     LVM ephemeral
>     storage. Below is a draft of the blueprint describing the proposed
>     feature.
>
>     Suggestions on architecture, implementation and the blueprint in
>     general are very
>     welcome.
>
>     Best,
>     Dan
>
>     ========================
>     Enable LVM ephemeral storage for Nova
>     ========================
>
>     Currently DevStack supports only file based ephemeral storage for
>     Nova, e.g.,
>     raw and qcow2. This is an obstacle to Tempest testing of Nova with
>     LVM ephemeral
>     storage, which in the past has been inadvertantly broken
>     (see for example, https://bugs.launchpad.net/nova/+bug/1373962),
>     and to Tempest
>     testing of new features based on LVM ephemeral storage, such as
>     LVM ephemeral
>     storage encryption.
>
>     To enable Nova to come up with LVM ephemeral storage it must be
>     provided a
>     volume group. Based on an initial discussion with Dean Troyer,
>     this is best
>     achieved by creating a single volume group for all services that
>     potentially
>     need LVM storage; at the moment these are Nova and Cinder.
>
>     Implementation of this feature will:
>
>      * move code in lib/cinder/cinder_backends/lvm to lib/lvm with
>     appropriate
>        modifications
>
>      * rename the Cinder volume group to something generic, e.g.,
>     devstack-vg
>
>      * modify the Cinder initialization and cleanup code appropriately
>     to use
>        the new volume group
>
>      * initialize the volume group in stack.sh, shortly before
>     services are
>        launched
>
>      * cleanup the volume group in unstack.sh after the services have been
>        shutdown
>
>     The question of how large to make the common Nova-Cinder volume
>     group in order
>     to enable LVM ephemeral Tempest testing will have to be explored.
>     Although,
>     given the tiny instance disks used in Nova Tempest tests, the current
>     Cinder volume group size may already be adequate.
>
>     No new configuration options will be necessary, assuming the
>     volume group size
>     will not be made configurable.
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/e11d5af6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/e11d5af6/attachment.bin>