<div dir="ltr">Hi, <div><br>I think we should revert this patch that was added here (<a href="https://review.openstack.org/#/c/29767/">https://review.openstack.org/#/c/29767/</a>). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on. The idea of the patch was that providing this information would "allow hardware device vendors management stations to allow them to segment the network in a more precise manager (for example automatically trunk the vlan on the physical switch port connected to the compute node on which the vm instance was started)." <br>
<br>In my opinion I don't think this is the right approach. There are several other ways to get this information of where a specific port lives. For example, in the OVS plugin case the agent running on the nova-compute node can update the port in quantum to provide this information. Alternatively, quantum could query nova using the port.device_id to determine which server the instance is on. <br>
<br>My motivation for removing this code is I now have the free cycles to work on <a href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a>  discussed here (<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html">http://lists.openstack.org/pipermail/openstack-dev/2013-May/009088.html</a>)  . This was about moving the quantum port creation from the nova-compute host to nova-api if a network-uuid is passed in. This will allow us to remove all the quantum logic from the nova-compute nodes and simplify orchestration. </div>
<div><br></div><div style>Thoughts? </div><div style><br></div><div style>Best, </div><div style><br></div><div style>Aaron</div></div>