<div dir="ltr">Hi Julia,<div><br></div><div>Thanks very much for the detailed answer and pointers, I've done some digging along the lines you suggested, <a href="https://pastebin.com/E14FVuF0">results here</a></div><div><br></div><div>Digging into the Ironic DB, I do see the last_error field for all 3 is " Failed to tear down. Error: IPMI call failed: power status."</div><div><br></div><div>That makes sense, as IPMI-over-LAN was accidentally disabled on those nodes, so these calls would fail. I think that the order of operation was that the failing calls were part of an instance teardown and node cleaning.</div><div><br></div><div>IPMI-over-LAN's been fixed so now manual ipmitool power status calls will succeed, and these correct credentials are in the node ipmi_* driver_info fields. The nodes are also out of maintenance mode.</div><div><br></div><div>We're running Train Ironic, as an extra piece of info if that's relevant at all to how Ironic may periodically check and/or correct node states.</div><div><br></div><div>Perhaps the next thing to try might be manual DB edit of provision_state of these 3 nodes back to 'available'</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 24 Sep 2020 at 05:29, Julia Kreger <<a href="mailto:juliaashleykreger@gmail.com">juliaashleykreger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well, somehow I accidentally clicked send! \o/<br>
<br>
If you can confirm that the provision_state is ERROR, and if you can<br>
identify how the machines got there, it would be helpful. If the<br>
machines are still in working order in the database, you may need to<br>
actually edit the database because we offer no explicit means to force<br>
override the state, mainly to help prevent issues sort of exactly like<br>
this. I suspect you may be encountering issues if the node is marked<br>
in maintenance state. If the power state is None, maintenance is also<br>
set automatically. Newer versions of ironic _do_ periodically check<br>
nodes and reset that state, but again it is something to check and if<br>
there are continued connectivity issues to the BMC then that may not<br>
be happening.<br>
<br>
So: to recap:<br>
<br>
1) Verify the node's provision_state is ERROR. If ERROR is coming from<br>
Nova, that is a different situation.<br>
2) Ensure the node is not set in maintenance mode[3]<br>
3) You may also need to ensure the<br>
ipmi_address/ipmi_username/ipmi_password is also correct for the node<br>
that matches what can be accessed on the motherboard.<br>
<br>
Additionally, you may also want to externally verify that you actually<br>
query the IPMI BMCs. If this somehow started down this path due to<br>
power management being lost due to the BMC, some BMCs can have some<br>
weirdness around IP networking so it is always good just to manually<br>
check using ipmitool.<br>
<br>
One last thing, is target_provision_state set for these nodes?<br>
<br>
[3]: <a href="https://docs.openstack.org/python-ironicclient/latest/cli/osc/v1/index.html#baremetal-node-maintenance-unset" rel="noreferrer" target="_blank">https://docs.openstack.org/python-ironicclient/latest/cli/osc/v1/index.html#baremetal-node-maintenance-unset</a><br>
<br>
On Wed, Sep 23, 2020 at 9:20 PM Julia Kreger<br>
<<a href="mailto:juliaashleykreger@gmail.com" target="_blank">juliaashleykreger@gmail.com</a>> wrote:<br>
><br>
> Greetings Paul,<br>
><br>
> Obviously, deleting and re-enrolling would be an action of last<br>
> resort. The only way that I can think you could have gotten the<br>
> machines into the provision state of ERROR is if they were somehow<br>
> requested to be un-provisioned.<br>
><br>
> The state machine diagram[0], refers to the provision state verb as<br>
> "deleted", but the command line tool command this is undeploy[1].<br>
><br>
><br>
> [0]: <a href="https://docs.openstack.org/ironic/latest/_images/states.svg" rel="noreferrer" target="_blank">https://docs.openstack.org/ironic/latest/_images/states.svg</a><br>
> [1]: <a href="https://docs.openstack.org/python-ironicclient/latest/cli/osc/v1/index.html#baremetal-node-undeploy" rel="noreferrer" target="_blank">https://docs.openstack.org/python-ironicclient/latest/cli/osc/v1/index.html#baremetal-node-undeploy</a><br>
><br>
><br>
><br>
> On Wed, Sep 23, 2020 at 4:58 PM Paul Browne <<a href="mailto:pfb29@cam.ac.uk" target="_blank">pfb29@cam.ac.uk</a>> wrote:<br>
> ><br>
> > Hello all,<br>
> ><br>
> > I have a handful of baremetal nodes enrolled in Ironic that use the IPMI hardware type, whose motherboards were recently replaced in a hardware recall by the vendor.<br>
> ><br>
> > After the replacement, the BMC IPMI-over-LAN feature was accidentally left disabled on the nodes, and future attempts to control them with Ironic has put these nodes into the ERROR provisioning state.<br>
> ><br>
> > The IPMI-over-LAN feature on the boards has been enabled again as expected, but is there now any easy way to get the BM nodes back out of that ERROR state, without first deleting and re-enrolling them?<br>
> ><br>
> > --<br>
> > *******************<br>
> > Paul Browne<br>
> > Research Computing Platforms<br>
> > University Information Services<br>
> > Roger Needham Building<br>
> > JJ Thompson Avenue<br>
> > University of Cambridge<br>
> > Cambridge<br>
> > United Kingdom<br>
> > E-Mail: <a href="mailto:pfb29@cam.ac.uk" target="_blank">pfb29@cam.ac.uk</a><br>
> > Tel: 0044-1223-746548<br>
> > *******************<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:12.8px"><div style="font-size:12.8px"><span style="font-size:12.8px">*******************</span><br></div><div style="font-size:12.8px">Paul Browne</div><div style="font-size:12.8px">Research Computing Platforms</div><div style="font-size:12.8px">University Information Services</div><div style="font-size:12.8px">Roger Needham Building</div><div style="font-size:12.8px">JJ Thompson Avenue</div><div style="font-size:12.8px">University of Cambridge</div><div style="font-size:12.8px">Cambridge</div><div style="font-size:12.8px">United Kingdom</div><div style="font-size:12.8px">E-Mail: <a href="mailto:pfb29@cam.ac.uk" target="_blank">pfb29@cam.ac.uk</a></div><div style="font-size:12.8px">Tel: 0044-1223-746548</div><div style="font-size:12.8px">*******************</div></div></div></div></div></div>