Open Stack

Hi Devananda,

Most of this should work fine. The only problem part is handling the
servers that are first being booted and have never been connected to
Ironic. Neutron doesn't have control over the default network that all
un-provisioned switch ports should be a member of. Even if we added support
for this, the management network that you would likely want them to be on
is normally a network not known to Neutron.

For that workflow to work, I think the switch-ports should be manually
configured to be in the management VLAN by default. Then the servers will
be able to boot up and receive their PXE image from ironic, etc. Once
Ironic will create an external attachment point using the information
learned from LLDP. It's then up to the backend implementation to assure
that when that external attachment point isn't associated to a specific
neutron network that it will be in the default network it was configured in
to begin with.

The workflow would then be:
1. Admin puts all switch ports that might have Ironic servers plugged into
them into the management network.
2. A new Ironic server is plugged in and successfully boots to management
network and learns it's switch ID/port from LLDP.
3. The Ironic management server makes a call to Neutron to create an
external attachment point using the switch ID/port received from the new
server.
4. When the server is being assigned to a tenant, Ironic passes the
external attachment ID to Nova, which adds it to the neutron port creation
request.
5. Neutron will then assign the external attachment point to the network in
the port creation request, at which point the backend will be triggered to
configure the switch-port for appropriate VLAN access, etc.
6. Once the server is terminated, Ironic will remove the network ID from
the external attachment point, which will instruct the Neutron backend to
return the port to the default VLAN it was in before. In this case it would
be the management VLAN and it would be back on the appropriate network for
provisioning again.

Does that make sense?

Thanks,
Kevin Benton



On Tue, May 20, 2014 at 9:48 AM, Devananda van der Veen <
devananda.vdv at gmail.com> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140520/0f25f709/attachment.html>