Open Stack

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