[openstack-dev] [Nova][Quantum] Move quantum port creation to nova-api

Aaron Rosen arosen at nicira.com
Mon May 20 16:26:40 UTC 2013


Hi Rob,

Good points. I think Salvatore is right that some integration should happen
between quantum and Ironic for this to play nicely. It seems in order to
make ironic play nicely with quantum we'd need to register each physical
port's mac with quantum a head of time but it seems like there are other
issues besides that. For example, which network is this mac going to reside
on as it's dynamic thus should we be preventing others from creating ports
on different networks with this same mac...etc.

Aaron


On Fri, May 17, 2013 at 8:42 AM, Robert Collins
<robertc at robertcollins.net>wrote:

> On 16 May 2013 17:59, Gary Kotton <gkotton at redhat.com> wrote:
> > On 05/15/2013 10:53 PM, Aaron Rosen wrote:
> >
> > Hi,
> >
> > I created the following blueprint and wanted to hear what the community
> > though before starting on it.
> >
> > https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
> >
> >
> > In the BP you wrote: "The only downside I see of moving this logic into
> > nova-api is that we would slow down the response time from nova-api to
> > provision instances."
> >
> > This can be addressed by nova prefetching quantum ports. When nova needs
> a
> > port is can be retrieved from a cached pool. This may be a way of
> addressing
> > this at a later stage if the nova api is indeed a bottleneck when it
> comes
> > to the quantum interface (please note that this currently happens on the
> > compute node at the moment)
>
>
> There is another downside : you cannot create ports for baremetal
> until you have scheduled the instance onto a baremetal machine :
> baremetal ethernet addresses are immutable [leaving aside LAA which we
> could in principle do by having a DHCP handoff for that - but I don't
> fancy getting PXE firmware updates out there to make it reliable : LAA
> needs to be optional, not mandatory].
>
> We could ask for a port with no MAC or a random MAC and then update it
> when the schedule has happened, but those both have downsides too - if
> the MAC is already on an admin created port, you'll have to handle
> Quantum rejecting the update and telling you what port you really need
> to use.
>
> I believe PowerVM has some similar constraints too.
>
> -Rob
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130520/711aae3f/attachment.html>


More information about the OpenStack-dev mailing list