<div dir="ltr"><div><div><div>Hi,<br><br>> I want to propose not to wipe disks and simply unset bootable flag from node disks.<br><br></div>AFAIK, removing bootable flag does not guarantee that system won't be booted from the local drive. This is why erase_node is needed.<br><br></div>Regards,<br></div>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 25, 2015 at 8:59 AM, Artur Svechnikov <span dir="ltr"><<a href="mailto:asvechnikov@mirantis.com" target="_blank">asvechnikov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span style="font-size:12.8000001907349px">> When </span><span style="font-size:12.8000001907349px">do we use the ssh_erase_nodes?  </span><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">It's used in stop_deployment provision stage [0] and for control reboot [1].</span></div><span class=""><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">Is it a fall back mechanism if the </span><span style="font-size:12.8000001907349px">mcollective fails?</span></div></span><div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Yes it's like fall back mechanism, but it's used always [2].</span></div></div><span class=""><div><br></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">That </span><span style="font-size:12.8000001907349px">might have been a side effect of cobbler and we should test if it's</span></div><span style="font-size:12.8000001907349px">> still an issue for IBP.</span><div><span style="font-size:12.8000001907349px"><br></span></div></span><div><span style="font-size:12.8000001907349px">As I can see from the code partition table always is wiped before provision [3].</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">[0] <a href="https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L387-L396" target="_blank">https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L387-L396</a></span></div><div><span style="font-size:12.8000001907349px">[1] <a href="https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L417-L425" target="_blank">https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L417-L425</a></span></div><div><span style="font-size:12.8000001907349px">[2] <a href="https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L202-L208" target="_blank">https://github.com/openstack/fuel-astute/blob/master/lib/astute/provision.rb#L202-L208</a></span></div><div><span style="font-size:12.8000001907349px">[3] <a href="https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L194-L197" target="_blank">https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L194-L197</a></span></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;line-height:21.503999710083px;white-space:pre-wrap;background-color:rgb(255,255,255)"><font size="2">Best regards,</font></span></div><div><span style="color:rgb(0,0,0);font-family:Arial,sans-serif;line-height:21.503999710083px;white-space:pre-wrap;background-color:rgb(255,255,255)"><font size="2">Svechnikov Artur</font></span></div></div></div></div></div></div></div></div></div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Thu, Dec 24, 2015 at 5:27 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov<br>
<<a href="mailto:asvechnikov@mirantis.com" target="_blank">asvechnikov@mirantis.com</a>> wrote:<br>
> Hi,<br>
> We have faced the issue that nodes' disks are wiped after stop deployment.<br>
> It occurs due to the logic of nodes removing (this is old logic and it's not<br>
> actual already as I understand). This logic contains step which calls<br>
> erase_node[0], also there is another method with wipe of disks [1]. AFAIK it<br>
> was needed for smooth cobbler provision and ensure that nodes will not be<br>
> booted from disk when it shouldn't. Instead of cobbler we use IBP from<br>
> fuel-agent where current partition table is wiped before provision stage.<br>
> And use disks wiping for insurance that nodes will not booted from disk<br>
> doesn't seem good solution. I want to propose not to wipe disks and simply<br>
> unset bootable flag from node disks.<br>
><br>
> Please share your thoughts. Perhaps some other components use the fact that<br>
> disks are wiped after node removing or stop deployment. If it's so, then<br>
> please tell about it.<br>
><br>
> [0]<br>
> <a href="https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137</a><br>
> [1]<br>
> <a href="https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb</a><br>
><br>
<br>
</span>I thought the erase_node[0] mcollective action was the process that<br>
cleared a node's disks after their removal from an environment. When<br>
do we use the ssh_erase_nodes?  Is it a fall back mechanism if the<br>
mcollective fails?  My understanding on the history is based around<br>
needing to have the partitions and data wiped so that the LVM groups<br>
and other partition information does not interfere with the<br>
installation process the next time the node is provisioned.  That<br>
might have been a side effect of cobbler and we should test if it's<br>
still an issue for IBP.<br>
<br>
<br>
Thanks,<br>
-Alex<br>
<br>
[0] <a href="https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb</a><br>
<div><div><br>
> Best regards,<br>
> Svechnikov Artur<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>