<div dir="ltr">Hi Rob, <div><br></div><div style>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.</div>
<div style><br></div><div style>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 8:42 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 16 May 2013 17:59, Gary Kotton <<a href="mailto:gkotton@redhat.com">gkotton@redhat.com</a>> wrote:<br>

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