Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev