<div dir="ltr"><div>Lucas, Andrew<br><br></div>Thanks for fast response.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 4:53 PM, Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
On Fri, May 27, 2016, at 09:25 AM, Lucas Alvares Gomes wrote:<br>
> Hi,<br>
><br>
> Thanks for bringing this up Vasyl!<br>
><br>
> > At the moment Nova with ironic virt_driver consider instance as deleted,<br>
> > while on Ironic side server goes to cleaning which can take a while. As<br>
> > result current implementation of Nova tempest tests doesn't work for case<br>
> > when Ironic is enabled.<br>
<br>
</span>What is the actual failure? Is it a capacity issue because nodes do not<br>
become available again quickly enough?<br>
<span class=""><br></span></blockquote><div> </div><div>The actual failure is that temepest community doesn't want to accept 1 option.<br><a href="https://review.openstack.org/315422/">https://review.openstack.org/315422/</a><br></div><div>And I'm not sure that it is the right way.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
> ><br>
> > There are two possible options how to fix it:<br>
> ><br>
> >  Update Nova tempest test scenarios for Ironic case to wait when cleaning is<br>
> > finished and Ironic node goes to 'available' state.<br>
> ><br>
> > Mark instance as deleted in Nova only after cleaning is finished on Ironic<br>
> > side.<br>
> ><br>
> > I'm personally incline to 2 option. From user side successful instance<br>
> > termination means that no instance data is available any more, and nobody<br>
> > can access/restore that data. Current implementation breaks this rule.<br>
> > Instance is marked as successfully deleted while in fact it may be not<br>
> > cleaned, it may fail to clean and user will not know anything about it.<br>
> ></span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
><br>
> I don't really like option #2, cleaning can take several hours<br>
> depending on the configuration of the node. I think that it would be a<br>
> really bad experience if the user of the cloud had to wait a really<br>
> long time before his resources are available again once he deletes an<br>
> instance. The idea of marking the instance as deleted in Nova quickly<br>
> is aligned with our idea of making bare metal deployments<br>
> look-and-feel like VMs for the end user. And also (one of) the<br>
> reason(s) why we do have a separated state in Ironic for DELETING and<br>
> CLEANING.<br></span></blockquote><div> </div><div>The resources will be available only if there are other available baremetal nodes in the cloud.<br></div><div>User doesn't have ability to track for status of available resources without admin access.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
</span>I agree. From a user perspective once they've issued a delete their<br>
instance should be gone. Any delay in that actually happening is purely<br>
an internal implementation detail that they should not care about.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div></div><div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
><br>
> I think we should go with #1, but instead of erasing the whole disk<br>
> for real maybe we should have a "fake" clean step that runs quickly<br>
> for tests purposes only?<br>
><br></div></div></blockquote><div> </div><div>At the gates we just waiting for bootstrap and callback from node when cleaning starts. All heavy operations are postponed. We can disable automated_clean, which means it is not tested.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">
> Cheers,<br>
> Lucas<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <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>
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>