Open Stack

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 <geguileo at 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-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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180827/55682794/attachment.html>