On 8/23/2018 12:07 PM, Gorka Eguileor wrote:
On 23/08, Dan Smith wrote:
I think Nova should never have to rely on Cinder's hosts/backends
information to do migrations or any other operation.
In this case even if Nova had that info, it wouldn't be the solution.
Cinder would reject migrations if there's an incompatibility on the
Volume Type (AZ, Referenced backend, capabilities...)
I think I'm missing a bunch of cinder knowledge required to fully grok
this situation and probably need to do some reading. Is there some
reason that a volume type can't exist in multiple backends or something?
I guess I think of volume type as flavor, and the same definition in two
places would be interchangeable -- is that not the case?
Hi,
I just know the basics of flavors, and they are kind of similar, though
I'm sure there are quite a few differences.
Sure, multiple storage arrays can meet the requirements of a Volume
Type, but then when you create the volume you don't know where it's
going to land. If your volume type is too generic you volume could land
somewhere your cell cannot reach.
I don't know anything about Nova cells, so I don't know the specifics of
how we could do the mapping between them and Cinder backends, but
considering the limited range of possibilities in Cinder I would say we
only have Volume Types and AZs to work a solution.
I think the only mapping we need is affinity or distance. The point of
needing to migrate the volume would purely be because moving cells
likely means you moved physically farther away from where you were,
potentially with different storage connections and networking. It
doesn't *have* to mean that, but I think in reality it would. So the
question I think Matt is looking to answer here is "how do we move an
instance from a DC in building A to building C and make sure the
volume gets moved to some storage local in the new building so we're
not just transiting back to the original home for no reason?"
Does that explanation help or are you saying that's fundamentally hard
to do/orchestrate?
Fundamentally, the cells thing doesn't even need to be part of the
discussion, as the same rules would apply if we're just doing a normal
migration but need to make sure that storage remains affined to compute.
We could probably work something out using the affinity filter, but
right now we don't have a way of doing what you need.
We could probably rework the migration to accept scheduler hints to be
used with the affinity filter and to accept calls with the host or the
hints, that way it could migrate a volume without knowing the
destination host and decide it based on affinity.
We may have to do more modifications, but it could be a way to do it.
I don't know how the Nova Placement works, but it could hold an
equivalency mapping of volume types to cells as in:
Cell#1 Cell#2
VolTypeA <--> VolTypeD
VolTypeB <--> VolTypeE
VolTypeC <--> VolTypeF
Then it could do volume retypes (allowing migration) and that would
properly move the volumes from one backend to another.
The only way I can think that we could do this in placement would be if
volume types were resource providers and we assigned them traits that
had special meaning to nova indicating equivalence. Several of the words
in that sentence are likely to freak out placement people, myself
included :)
So is the concern just that we need to know what volume types in one
backend map to those in another so that when we do the migration we know
what to ask for? Is "they are the same name" not enough? Going back to
the flavor analogy, you could kinda compare two flavor definitions and
have a good idea if they're equivalent or not...
--Dan
In Cinder you don't get that from Volume Types, unless all your backends
have the same hardware and are configured exactly the same.
There can be some storage specific information there, which doesn't
correlate to anything on other hardware. Volume types may refer to a
specific pool that has been configured in the array to use specific type
of disks. But even the info on the type of disks is unknown to the
volume type.
I haven't checked the PTG agenda yet, but is there a meeting on this?
Because we may want to have one to try to understand the requirements
and figure out if there's a way to do it with current Cinder
functionality of if we'd need something new.
Gorka,
I don't think that this has been put on the agenda yet. Might be good
to add. I don't think we have a cross project time officially planned
with Nova. I will start that discussion with Melanie so that we can
cover the couple of cross projects subjects we have.
Jay
Cheers,
Gorka.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
