Hi Matt, Isn't multiple port binding what we need in the case of ports? In my mind, the big motivator for multiple port binding is the ability to change a port's backend
Best regards Miguel On Mon, Aug 27, 2018 at 4:32 AM, Gorka Eguileor <gegui...@redhat.com> wrote: > 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 >
__________________________________________________________________________ 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
