<div><div dir="auto">On Tue, May 28, 2019 at 8:33 AM Csatari, Gergely (Nokia - HU/Budapest) <<a href="mailto:gergely.csatari@nokia.com">gergely.csatari@nokia.com</a>> wrote:<br></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, <br>
<br>
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. <br>
<br>
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: <br>
1) Virtual media support [2] where the ip configuration is embedded into a virtual image what is booted via the board management interface<br>
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?<br>
<br>
Upgrade of edge cloud infrastructures:<br>
- Firmware upgrade should be supported by Ironic. Is this something on its way or is this a new need?<br>
- Operating system and infra update can be solved using Fenix [3], however handling several edge cloud instances from a central location needs new features.<br>
<br>
Handling of failed servers:<br>
- A monitoring system or the operator should provide the input to mark a server as failed<br>
- Ironic can power down the failed servers and have the definition of a maintenance state<br>
- Discussed in [4]<br>
<br>
Additional ideas what we half discussed:<br>
- 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?<br>
<br>
[1]: <a href="https://etherpad.openstack.org/p/edge-wg-ptg-preparation-denver-2019" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/edge-wg-ptg-preparation-denver-2019</a><br>
[2]: <a href="https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/L3-based-deployment.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/L3-based-deployment.html</a><br>
[3]: <a href="https://wiki.openstack.org/wiki/Fenix" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Fenix</a><br>
[4]: <a href="http://lists.openstack.org/pipermail/edge-computing/2019-May/000582.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/edge-computing/2019-May/000582.html</a><br>
<br>
Br, <br>
Gerg0<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.<br></div><div dir="auto"><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="monospace, monospace">Dan Sneddon | Senior Principal Software Engineer<br><a href="mailto:dsneddon@redhat.com" target="_blank">dsneddon@redhat.com</a> | <a href="http://redhat.com/cloud" target="_blank">redhat.com/cloud</a><br>dsneddon:irc | @dxs:twitter</font><br></div></div></div></div></div></div>