<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt <span dir="ltr"><<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div>
<div>On Dec 5, 2013, at 6:25 PM, Christopher Armstrong <<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a>></div>
<div> wrote:</div><div><div class="h5">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita <span dir="ltr">
<<a href="mailto:andersonvom@thoughtworks.com" target="_blank">andersonvom@thoughtworks.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">Hey stackers,<br>
<br>
We've been working towards making stack convergence (<a href="https://blueprints.launchpad.net/heat/+spec/stack-convergence" target="_blank">https://blueprints.launchpad.net/heat/+spec/stack-convergence</a>) one step closer to being ready at a time.  After
 the first patch was submitted we got positive feedback on it as well as some good suggestions as to how to move it forward.<br>
<br>
The first step (<a href="https://blueprints.launchpad.net/heat/+spec/stack-check" target="_blank">https://blueprints.launchpad.net/heat/+spec/stack-check</a>) is to get all the statuses back from the real world resources and update our stacks accordingly so
 that we'll be able to move on to the next step: converge it to the desired state, fixing any errors that may have happened.<br>
<br>
We just submitted another WiP for review, and as we were doing it, a few questions were raised and we'd like to get everybody's input on them. Our main concern is around the use and purpose of the `status` of a stack/resource.  `status` currently appears to
 represent the status of the last action taken, and it seems that we may need to repurpose it or possibly create something else to represent a stack's "health" (i.e. everything is up and running as expected, something smells fishy, something broke, stack's
 is doomed).  We described this thoroughly here: <a href="https://etherpad.openstack.org/p/heat-convergence" target="_blank">
https://etherpad.openstack.org/p/heat-convergence</a><br>
<br>
Any thoughts?<br>
<br>
Cheers,<br>
</div>
<div dir="ltr"><br>
</div>
</blockquote>
<div><br>
</div>
<div>I think a lot of OpenStack projects use "status" fields as "status of the most recent operation", and I think it's totally wrong. "status" should be a known state of the _object_, not an action, and if we need statuses for operations, then those operations
 should be addressable REST objects. Of course there are cases where object status should be updated to reflect an operating status if it's a completely exclusive operation (BUILDING and DELETING make sense, for example).</div>

</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div>Actually, I think most projects are the opposite where "status" means "what's the state of the resource" (Nova, Trove, Cinder, etc), whereas Heat uses status as the state of the last operation. Probably wouldn't be too terrible to have a new "state" for
 stacks and their resources then perhaps deprecate and use "status" in the accepted way in the v2 API?</div>
<br></div></div></blockquote><div><br></div><div><br></div><div>Well, my point is that it's done inconsistently. Yes, it's mostly used as an object status, but nova for example uses it as an operation status for things like resize.</div>
<div><br></div><div><br></div></div></div></div>