Open Stack

Yes, I meant EBS not ECS. Too many similar acronyms...

The thing about the Amazon folk is that they collect a lot of metrics, and
pretty much do everything on a fairly empirical basis. This is a huge
advantage. Starting thinking about what I could with good metrics and
building on the performance characteristics of flash. Turns out ... I can
see how this could work (and very, very well). But that requires a much
longer write-up than I have time for at the moment.




On Tue, Oct 21, 2014 at 12:11 PM, Dan Genin <daniel.genin at jhuapl.edu> wrote:

>  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>
> 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://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/7b49a0b3/attachment.html>