On 10/28/2014 02:50 PM, John Griffith wrote:
On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
Great, thank you, Duncan. I will then proceed with the shared
volume group.
Dan
On 10/28/2014 02:06 PM, Duncan Thomas
Duncan, I don't think it's possible to have multiple volume groups using
the same physical volume[1]. In fact, counter-intuitively (at least to
me) the nesting actually goes the other way with multiple physical
volumes comprising a single volume group. The LVM naming scheme actually
makes more
On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge...@jhuapl.edu wrote:
So this brings us back to the original proposal of having separate
backing files for Cinder and Nova which Dean thought might take too much
space.
Between Cinder, Nova and Swift (and Ceph, etc) everybody wants some
Hi Dan
You're quite right, the nesting isn't as I thought it was, sorry to mislead you.
It isn't a show stopper, it just makes testing some proposed useful
functionality slightly harder. If nova were to namespace its volumes
(e.g. start all the volume names with nova-*) then that would allow
the
On 10/28/2014 11:56 AM, Dean Troyer wrote:
On Tue, Oct 28, 2014 at 9:27 AM, Dan Genin daniel.ge...@jhuapl.edu
mailto:daniel.ge...@jhuapl.edu wrote:
So this brings us back to the original proposal of having separate
backing files for Cinder and Nova which Dean thought might take
too
On 10/28/2014 12:47 PM, Duncan Thomas wrote:
Hi Dan
You're quite right, the nesting isn't as I thought it was, sorry to mislead you.
It isn't a show stopper, it just makes testing some proposed useful
functionality slightly harder. If nova were to namespace its volumes
(e.g. start all the
Cinder volumes are always (unless you go change the default) in the
form: volume-uuid, and since the string 'volume-' is never a valid
uuid, then I think we can work around nova volumes fine when we come
to write our tests.
Sorry for the repeated circling on this, but I think I'm now happy.
On 28 October 2014 18:01, Dan Genin daniel.ge...@jhuapl.edu wrote:
Changing Nova disk names is a lng shot. It's likely I will be doing
something else by the time that gets merged:) So we are left with the two
options of 1) using a shared volume group and, thus, complicating life for
Great, thank you, Duncan. I will then proceed with the shared volume group.
Dan
On 10/28/2014 02:06 PM, Duncan Thomas wrote:
Cinder volumes are always (unless you go change the default) in the
form: volume-uuid, and since the string 'volume-' is never a valid
uuid, then I think we can work
On Tue, Oct 28, 2014 at 12:37 PM, Dan Genin daniel.ge...@jhuapl.edu wrote:
Great, thank you, Duncan. I will then proceed with the shared volume group.
Dan
On 10/28/2014 02:06 PM, Duncan Thomas wrote:
Cinder volumes are always (unless you go change the default) in the
form: volume-uuid,
On Tue, Oct 21, 2014 at 2:48 PM, Dan Genin daniel.ge...@jhuapl.edu wrote:
So then it is probably best to leave existing Cinder LVM code in
lib/cinder_backends/lvm alone and create a similar set of lvm scripts for
Nova,
perhaps in lib/nova_backends/lvm?
Dan
On 10/21/2014 03:10 PM, Duncan
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
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
Sharing the vg with cinder is likely to cause some pain testing proposed
features cinder reconciling backend with the cinder db. Creating a second
vg sharing the same backend pv is easy and avoids all such problems.
Duncan Thomas
On Oct 21, 2014 4:07 PM, Dan Genin daniel.ge...@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
Do you mean that Cinder will be confused by Nova's volumes in its volume
group?
Yeah, sure that would be similarly easy to implement. Thank you for the
suggestion!
Dan
On 10/21/2014 03:10 PM, Duncan Thomas wrote:
Sharing the vg with cinder is likely to cause some pain testing
proposed
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
So then it is probably best to leave existing Cinder LVM code in
lib/cinder_backends/lvm alone and create a similar set of lvm scripts
for Nova,
perhaps in lib/nova_backends/lvm?
Dan
On 10/21/2014 03:10 PM, Duncan Thomas wrote:
Sharing the vg with cinder is likely to cause some pain testing
18 matches
Mail list logo