<div dir="ltr"><span style="font-size:12.8000001907349px">>As Andrew said already, in such case LVM meta data will remain on the hard drive. So if you remove partition table, reboot the node (env reset), then configure exactly the same partition table (like when you use the same >default disk allocation in Fuel), then Linux will find LVM info on the same sectors of HDD on re-created partitions and re-assemble old LVM devices automatically.</span><br><div><br></div><div>><span style="font-size:12.8000001907349px">Alex is right, wiping partition table is not enough. User can create partition table with exact the same sizes of partition as was before. In this case lvm may detect metadata on untouched partitions to assemble a logical >volume. We should remove lvm metadata from every partition (or wipe 1st megabyte of every partition).</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>Fuel-agent can deal with it [0].</div><div><br></div><div>[0] <a href="https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L205-L221">https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L205-L221</a><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><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>
<br><div class="gmail_quote">On Thu, Jan 7, 2016 at 7:07 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.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"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Tue, Dec 29, 2015 at 5:35 AM Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>Let me comment inline.</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><br></div></div></div><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 28, 2015 at 7:06 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">In order to ensure that LVM can be configured as desired, its necessary to purge them and then reboot the node, otherwise the partitioning commands will most likely fail on the next attempt as they will be initialized before we can start partitioning the node. Hence, when a node is removed from the environment, it is supposed to have this data destroyed. Since it's a running system, the most effective way was to blast the first 1Mb of each partition. (with out many more reboots)<div><br></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>As to the fallback to SSH, there are two times we use this process, with the node reboot (after cobbler/IBP finishes), and with the wipe as we are discussing here. These are for the odd occurrences of the nodes failing to restart after the MCO command. I don't think anyone has had much success trying to figure out why this occurs, but I've seen nodes get stuck in provisioning and remove in multiple environments using 6.1 where they managed to break the SSH Fallback. It would occur around 1/20 nodes seemingly randomly. So with the SSH fallback I nearly never see the failure in node reboot.</div></div></blockquote><div><br></div><div>If we talk about 6.1-7.0 release there shouldn't be any problems with mco reboot. SSH fallback must be deprecated at all.</div></div></div></div></blockquote><div><br></div></span><div>As I noted, I've see several 6.1 deployments where it was needed, I'd consider it still very much in use. In other cases it might be necessary to attempt to deal with a node who's MCO agent is dead, IMO they should be kept.</div><div><div class="h5"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 24, 2015 at 6:28 AM Alex Schultz <<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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></blockquote></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Disks must be wiped as boot flag doesn't guarantee anything. If bootlag is not set, BIOS will ignore ignore the device in boot-order. More over, 2 partitions may have bootflag or operator may set to skip boot-order in BIOS.</div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="color:rgb(37,37,37);font-family:sans-serif;font-size:14px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
><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>
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></blockquote></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Since we do not use classical provision anymore, we have mco connection all the time. During IBP we have it as part of bootstrap, after reboot, mco is still present so all actions should be done via mco.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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>
<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>
</blockquote></div></div></div></div><span><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p>
</div>
</font></span><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></div></div>
__________________________________________________________________________<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>
</blockquote></div></div></div></div><div class="HOEnZb"><div class="h5"><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p>
</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>