<div dir="ltr"><div>Hi Matt,</div><div><br></div><div>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</div><div><br></div><div>Best regards</div><div><br></div><div>Miguel<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 27, 2018 at 4:32 AM, Gorka Eguileor <span dir="ltr"><<a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 24/08, Jay S Bryant wrote:<br>
><br>
><br>
> On 8/23/2018 12:07 PM, Gorka Eguileor wrote:<br>
> > On 23/08, Dan Smith wrote:<br>
> > > > I think Nova should never have to rely on Cinder's hosts/backends<br>
> > > > information to do migrations or any other operation.<br>
> > > ><br>
> > > > In this case even if Nova had that info, it wouldn't be the solution.<br>
> > > > Cinder would reject migrations if there's an incompatibility on the<br>
> > > > Volume Type (AZ, Referenced backend, capabilities...)<br>
> > > I think I'm missing a bunch of cinder knowledge required to fully grok<br>
> > > this situation and probably need to do some reading. Is there some<br>
> > > reason that a volume type can't exist in multiple backends or something?<br>
> > > I guess I think of volume type as flavor, and the same definition in two<br>
> > > places would be interchangeable -- is that not the case?<br>
> > ><br>
> > Hi,<br>
> ><br>
> > I just know the basics of flavors, and they are kind of similar, though<br>
> > I'm sure there are quite a few differences.<br>
> ><br>
> > Sure, multiple storage arrays can meet the requirements of a Volume<br>
> > Type, but then when you create the volume you don't know where it's<br>
> > going to land. If your volume type is too generic you volume could land<br>
> > somewhere your cell cannot reach.<br>
> ><br>
> ><br>
> > > > I don't know anything about Nova cells, so I don't know the specifics of<br>
> > > > how we could do the mapping between them and Cinder backends, but<br>
> > > > considering the limited range of possibilities in Cinder I would say we<br>
> > > > only have Volume Types and AZs to work a solution.<br>
> > > I think the only mapping we need is affinity or distance. The point of<br>
> > > needing to migrate the volume would purely be because moving cells<br>
> > > likely means you moved physically farther away from where you were,<br>
> > > potentially with different storage connections and networking. It<br>
> > > doesn't *have* to mean that, but I think in reality it would. So the<br>
> > > question I think Matt is looking to answer here is "how do we move an<br>
> > > instance from a DC in building A to building C and make sure the<br>
> > > volume gets moved to some storage local in the new building so we're<br>
> > > not just transiting back to the original home for no reason?"<br>
> > ><br>
> > > Does that explanation help or are you saying that's fundamentally hard<br>
> > > to do/orchestrate?<br>
> > ><br>
> > > Fundamentally, the cells thing doesn't even need to be part of the<br>
> > > discussion, as the same rules would apply if we're just doing a normal<br>
> > > migration but need to make sure that storage remains affined to compute.<br>
> > ><br>
> > We could probably work something out using the affinity filter, but<br>
> > right now we don't have a way of doing what you need.<br>
> ><br>
> > We could probably rework the migration to accept scheduler hints to be<br>
> > used with the affinity filter and to accept calls with the host or the<br>
> > hints, that way it could migrate a volume without knowing the<br>
> > destination host and decide it based on affinity.<br>
> ><br>
> > We may have to do more modifications, but it could be a way to do it.<br>
> ><br>
> ><br>
> ><br>
> > > > I don't know how the Nova Placement works, but it could hold an<br>
> > > > equivalency mapping of volume types to cells as in:<br>
> > > ><br>
> > > >   Cell#1        Cell#2<br>
> > > ><br>
> > > > VolTypeA <--> VolTypeD<br>
> > > > VolTypeB <--> VolTypeE<br>
> > > > VolTypeC <--> VolTypeF<br>
> > > ><br>
> > > > Then it could do volume retypes (allowing migration) and that would<br>
> > > > properly move the volumes from one backend to another.<br>
> > > The only way I can think that we could do this in placement would be if<br>
> > > volume types were resource providers and we assigned them traits that<br>
> > > had special meaning to nova indicating equivalence. Several of the words<br>
> > > in that sentence are likely to freak out placement people, myself<br>
> > > included :)<br>
> > ><br>
> > > So is the concern just that we need to know what volume types in one<br>
> > > backend map to those in another so that when we do the migration we know<br>
> > > what to ask for? Is "they are the same name" not enough? Going back to<br>
> > > the flavor analogy, you could kinda compare two flavor definitions and<br>
> > > have a good idea if they're equivalent or not...<br>
> > ><br>
> > > --Dan<br>
> > In Cinder you don't get that from Volume Types, unless all your backends<br>
> > have the same hardware and are configured exactly the same.<br>
> ><br>
> > There can be some storage specific information there, which doesn't<br>
> > correlate to anything on other hardware.  Volume types may refer to a<br>
> > specific pool that has been configured in the array to use specific type<br>
> > of disks.  But even the info on the type of disks is unknown to the<br>
> > volume type.<br>
> ><br>
> > I haven't checked the PTG agenda yet, but is there a meeting on this?<br>
> > Because we may want to have one to try to understand the requirements<br>
> > and figure out if there's a way to do it with current Cinder<br>
> > functionality of if we'd need something new.<br>
> Gorka,<br>
><br>
> I don't think that this has been put on the agenda yet.  Might be good to<br>
> add.  I don't think we have a cross project time officially planned with<br>
> Nova.  I will start that discussion with Melanie so that we can cover the<br>
> couple of cross projects subjects we have.<br>
><br>
> Jay<br>
<br>
</div></div>Thanks Jay!<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> > Cheers,<br>
> > Gorka.<br>
> ><br>
> > ______________________________<wbr>______________________________<wbr>______________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>