Open Stack

Hi Kevin!

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.

I've left a few comments inline....


On Mon, May 19, 2014 at 3:52 PM, Kevin Benton <blak111 at gmail.com> wrote:

> Hello,
>
> 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].
>
> 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.
>

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.

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?


> 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.
>

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.

Setting it manually should also, of course, be possible, but less
manageable with large numbers of servers.


>
> 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.
>

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.


Cheers,
Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140520/32514d68/attachment.html>