Open Stack

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