<div dir="ltr">Hi!<div><br></div><div>I also vote for solution "<span style="font-size:12.8px">mark a cluster 'operational' after successful deployment". It is simple and guarantee that we do not erase main components.</span></div><div><span style="font-size:12.8px">Also it will free resources to support stop/rerun(resume) feature on task based deployment which will works much better (without node destroy as side affect)</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 22, 2016 at 8:09 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dmitry,<br>
<span class=""><br>
> We can mark a cluster 'operational' after successful deployment. And we<br>
> can disable 'stop' button on this kind of clusters.<br>
<br>
</span>I think this is a best solution so far. Moreover, I don't know how to<br>
fix it properly since there could be a lot of questions how this<br>
button should behave at all.<br>
<br>
Taking into account all this, I propose to solve this issue as a<br>
blueprint (so we can think and cover all edge cases in the spec) or<br>
drop stop button functionality at all.<br>
<br>
The latest, perhaps, may be a good solution. I don't know how often<br>
someone use Stop deployment.<br>
<br>
<br>
Bogdan,<br>
<span class=""><br>
> This is the critical issue. The *worst* of possible situations for<br>
> cluster operations. I believe this should be covered by a dedicated<br>
> bulletin issued, the stop action shall be disabled for all releases as<br>
> emergency fix, and fixed by next maintenance updates.<br>
<br>
</span>It wasn't always the case. Some time ago we didn't execute any tasks<br>
on controllers when adding new nodes. It's become a case, I assume,<br>
since Fuel 8.0, when we start executing netconfig and other puppet<br>
task on each deployment run.<br>
<br>
So we need to investigate in which release we have introduced<br>
re-execution some tasks on controllers, and only then thinking about<br>
bulletins.<br>
<br>
<br>
Thanks,<br>
Igor<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Jan 22, 2016 at 1:06 PM, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>> wrote:<br>
> On 22.01.2016 11:45, Dmitry Pyzhov wrote:<br>
>> Guys,<br>
>><br>
>> There is a tricky bug with our 'stop deployment'<br>
>> feature: <a href="https://bugs.launchpad.net/fuel/+bug/1529691" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1529691</a><br>
>><br>
>> It cannot be fixed easily because it is a design flaw. By design we<br>
>> cannot leave a node in unpredictable state. So we move all nodes that<br>
>> are not in ready state back to bootstrap.<br>
>><br>
>> But when user adding a node and deploying cluster system reruns puppet<br>
>> on controllers. If user press 'stop' button controllers will be erased.<br>
>> Cluster will be destroyed. Definitely this is not expected behaviour.<br>
><br>
> This is the critical issue. The *worst* of possible situations for<br>
> cluster operations. I believe this should be covered by a dedicated<br>
> bulletin issued, the stop action shall be disabled for all releases as<br>
> emergency fix, and fixed by next maintenance updates.<br>
><br>
>><br>
>> Taking into account that we are going to rewrite this feature in 9.0 and<br>
>> we are close to HCF there is no value in major changes for this feature<br>
>> in 8.0. Let's do a simple workaround.<br>
>><br>
>> We can mark a cluster 'operational' after successful deployment. And we<br>
>> can disable 'stop' button on this kind of clusters.<br>
>><br>
>> Any concerns or other proposals?<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>
>><br>
><br>
><br>
> --<br>
> Best regards,<br>
> Bogdan Dobrelya,<br>
> Irc #bogdando<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>
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>