
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div> </div>

<div> </div>

<div> </div>

<div>On Wed, Jun 1, 2016, at 06:06 AM, Timofei Durakov wrote:<br></div>

<blockquote type="cite"><div dir="ltr"><div>From my sight, I concerned proposed transition from option #1 to option #2.<br></div>

<div>because it would be quite big change. So I wonder, has any component team<br></div>

<div>implemented such transition. Open questions:<br></div>

<div><ul><li>upgrades story potential issues<br></li><li>dealing with clients(?)<br></li><li>promoting state machine from verification of states to conductor of the task(success stories)<br></li></ul></div>

</div>

</blockquote><div> </div>

<div>I would also be interested in hearing post mortems from projects that have done this.<br></div>

<div> </div>

<div>It would be a big change to transition from #1 to #2 but I don't think there's any less work involved to just do #2 first. Formalizing the states we want and adding logic around that has to take place in either option. I see option 1 as a small chunk of option 2, not an alternative.<br></div>

<div> </div>

<div> </div>

<blockquote type="cite"><div dir="ltr"><div><div>Timofey<br></div>

<div><div> </div>

<div defang_data-gmailquote="yes"><div>On Wed, Jun 1, 2016 at 12:51 PM, Miles Gould <span dir="ltr"><<a href="mailto:mgould@redhat.com">mgould@redhat.com</a>></span> wrote:<br></div>

<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes"><div><span>On 31/05/16 21:03, Timofei Durakov wrote:<br> </span></div>

<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes"><span>there is blueprint[1] that was approved during Liberty and resubmitted<br> to Newton(with spec[2]).<br> The idea is to define state machines for operations as live-migration,<br> resize, etc. and to deal with them operation states.</span></blockquote><div><span><br></span>+1 to introducing an explicit state machine - IME they make complex logic much easier to reason about. However, think carefully about how you'll make changes to that state machine later. In Ironic, this is an ongoing problem: every time we change the state machine, we have to decide whether to lie to older clients (and if so, what lie to tell them), or whether to present them with the truth (and if so, how badly they'll break). AIUI this would be a much smaller problem if we'd considered this possibility carefully at the beginning.<span><span class="colour" style="color:rgb(136, 136, 136)"><br> <br> Miles</span></span></div>

<div><div><div> </div>

<div> </div>

<div>__________________________________________________________________________<br></div>

<div> OpenStack Development Mailing List (not for usage questions)<br></div>

<div> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" defang_rel="noreferrer">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div>

<div> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" defang_rel="noreferrer">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>

</div>

</div>

</blockquote></div>

</div>

</div>

</div>

<div><u>__________________________________________________________________________</u><br></div>

<div>OpenStack Development Mailing List (not for usage questions)<br></div>

<div>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></div>

<div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" defang_rel="noreferrer">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>

</blockquote><div> </div>

</body>

</html>