Open Stack

On Tue, May 28, 2019 at 8:33 AM Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csatari at nokia.com> wrote:

> Hi,
>
> There was a one hour discussion with Julia from Ironic with the Edge
> Computing Group [1]. In this mail I try to conclude what was discussed and
> ask some clarification questions.
>
> Current Ironic uses DHCP for hardware provisioning, therefore it requires
> DHCP relay enabled on the whole path to the edge cloud instances. There are
> two alternatives to solve this:
> 1) Virtual media support [2] where the ip configuration is embedded into a
> virtual image what is booted via the board management interface
> 2) Redfish support, however the state and support of redfish for host
> management is not clear. Is there already a specification has been added
> for redfish support?
>
> Upgrade of edge cloud infrastructures:
>   - Firmware upgrade should be supported by Ironic. Is this something on
> its way or is this a new need?
>   - Operating system and infra update can be solved using Fenix [3],
> however handling several edge cloud instances from a central location needs
> new features.
>
> Handling of failed servers:
>   - A monitoring system or the operator should provide the input to mark a
> server as failed
>   - Ironic can power down the failed servers and have the definition of a
> maintenance state
>   - Discussed in [4]
>
> Additional ideas what we half discussed:
>   - Running Ironic containers in a switch with the images hosted by Swift
> somewhere else. Are there any concerns about this idea? Any missing
> features from somewhere?
>
> [1]: https://etherpad.openstack.org/p/edge-wg-ptg-preparation-denver-2019
> [2]:
> https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/L3-based-deployment.html
> [3]: https://wiki.openstack.org/wiki/Fenix
> [4]:
> http://lists.openstack.org/pipermail/edge-computing/2019-May/000582.html
>
> Br,
> Gerg0
>

I have researched putting Ironic into a container on a switch. However,
Ironic has historically required DHCP services, which would also be running
inside the same container. In order to respond to DHCP requests, the
container must be able to listen on the network for DHCP requests. Not all
switches will allow a container which is attached directly to the VLAN
interfaces and can receive traffic to the broadcast MAC address. If you
have a switch which allows you to listen to MAC broadcasts inside a
container then this should be feasible.

Also note that Ironic is not monolithic. There are separate functions for
API (which would not live on the switch), Ironic Inspector, and Ironic
Conductor. When using DHCP for Ironic Inspection, Ironic provides DHCP
using its own dnsmasq process. When using DHCP for deploying a node, the
DHCP services are provided by Neutron. It would be best to avoid DHCP in
this scenario so that neither inspection nor deployment required a DHCP
server.

However, as you note we are working on booting without DHCP, which will
make it much easier to host an Ironic service inside a container on a
switch or router. Without DHCP, the Ironic container must still be
reachable from the outside, but only by its IP address.

-- 
Dan Sneddon         |  Senior Principal Software Engineer
dsneddon at redhat.com |  redhat.com/cloud
dsneddon:irc        |  @dxs:twitter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/edge-computing/attachments/20190528/21421760/attachment.html>