Open Stack

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.

Cheers,
Gorka.