On 24/08, Jay S Bryant wrote: > > > 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
Thanks 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 __________________________________________________________________________ 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
