<div dir="ltr">Hi Kevin!<div><br></div><div>I had a few conversations with folks at the summit regarding this. Broadly speaking, yes -- this integration would be very helpful for both discovery and network/tenant isolation at the bare metal layer.</div>

<div><br></div><div>I've left a few comments inline....<br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 3:52 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr">Hello,<div><br></div><div>I am working on an extension for neutron to allow external attachment point information to be stored and used by backend plugins/drivers to place switch ports into neutron networks[1]. </div>




<div><br></div><div>One of the primary use cases is to integrate ironic with neutron. The basic workflow is that ironic will create the external attachment points when servers are initially installed. </div></div></blockquote>


<div><br></div><div>This also should account for servers that are already racked, which Ironic is instructed to manage. These servers would be booted into a discovery state, eg. running ironic-python-agent, and hardware information (inventory, LLDP data, etc) could be sent back to Ironic.</div>

<div><br></div><div>To do this, nodes not yet registered with Ironic will need to be PXE booted on a common management LAN (either untagged VLAN or a specific management VLAN), which can route HTTP(S) and TFTP traffic to an instance of ironic-api and ironic-conductor services. How will the routing be done by Neutron for unknown ports?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>This step could either be automated (extract switch-ID and port number of LLDP message) or it could be manually performed by an admin who notes the ports a server is plugged into. </div></div></blockquote>

<div><br></div><div>Ironic could extract info from LLDP if the machine has booted into the ironic-python-agent ramdisk and is able to communicate with Ironic services. So it needs to be networked /before/ it's enrolled with Ironic. If that's possible -- great. I believe this is the workflow that the IPA team intends to follow.</div>

<div><br></div><div>Setting it manually should also, of course, be possible, but less manageable with large numbers of servers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">

<div><br></div><div>Then when an instance is chosen for assignment and the neutron port needs to be created, the creation request would reference the corresponding attachment ID and neutron would configure the physical switch port to place the port on the appropriate neutron network.</div>

</div></blockquote><div><br></div><div>Implementation question here -- today, Nova does the network attachment for instances (or at least, Nova initiates the calls out to Neutron). Ironic can expose this information to Nova and allow Nova to coordinate with Neutron, or Ironic can simply call out to Neutron, as it does today when setting the dhcp extra options. I'm not sure which approach is better.</div>

<div> </div><div><br></div><div>Cheers,</div><div>Devananda</div></div></div></div></div>