<div dir="ltr">To try and keep this conversation moving forward, is it safe to say that we at least need to change the current <font face="courier new, monospace">status</font> attribute to something like <font face="courier new, monospace">action_status</font>? And the same with <font face="courier new, monospace">status_reason</font> being changed to <font face="courier new, monospace">action_status_reason</font>? Does anybody see a reason why we shouldn't go this way, since it's really what <font face="courier new, monospace">status</font> currently refers to?</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/8 Mitsuru Kanabuchi <span dir="ltr"><<a href="mailto:kanabuchi.mitsuru@po.ntts.co.jp" target="_blank">kanabuchi.mitsuru@po.ntts.co.jp</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Thu, 5 Dec 2013 22:13:18 -0600<br>
<div><div class="h5">Christopher Armstrong <<a href="mailto:chris.armstrong@rackspace.com">chris.armstrong@rackspace.com</a>> wrote:<br>
<br>
> On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt <<a href="mailto:randall.burt@rackspace.com">randall.burt@rackspace.com</a>>wrote:<br>
><br>
> >  On Dec 5, 2013, at 6:25 PM, Christopher Armstrong <<br>
> > <a href="mailto:chris.armstrong@rackspace.com">chris.armstrong@rackspace.com</a>><br>
> >  wrote:<br>
> ><br>
> >   On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita <<br>
> > <a href="mailto:andersonvom@thoughtworks.com">andersonvom@thoughtworks.com</a>> wrote:<br>
> ><br>
> >> Hey stackers,<br>
> >><br>
> >> We've been working towards making stack convergence (<br>
> >> <a href="https://blueprints.launchpad.net/heat/+spec/stack-convergence" target="_blank">https://blueprints.launchpad.net/heat/+spec/stack-convergence</a>) one step<br>
> >> closer to being ready at a time.  After the first patch was submitted we<br>
> >> got positive feedback on it as well as some good suggestions as to how to<br>
> >> 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>)<br>
> >> is to get all the statuses back from the real world resources and update<br>
> >> our stacks accordingly so that we'll be able to move on to the next step:<br>
> >> 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<br>
> >> questions were raised and we'd like to get everybody's input on them. Our<br>
> >> main concern is around the use and purpose of the `status` of a<br>
> >> stack/resource.  `status` currently appears to represent the status of the<br>
> >> last action taken, and it seems that we may need to repurpose it or<br>
> >> possibly create something else to represent a stack's "health" (i.e.<br>
> >> everything is up and running as expected, something smells fishy, something<br>
> >> broke, stack's is doomed).  We described this thoroughly here:<br>
> >> <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>
> >><br>
> >><br>
> >  I think a lot of OpenStack projects use "status" fields as "status of<br>
> > the most recent operation", and I think it's totally wrong. "status" should<br>
> > be a known state of the _object_, not an action, and if we need statuses<br>
> > for operations, then those operations should be addressable REST objects.<br>
> > Of course there are cases where object status should be updated to reflect<br>
> > an operating status if it's a completely exclusive operation (BUILDING and<br>
> > DELETING make sense, for example).<br>
> ><br>
> >  Actually, I think most projects are the opposite where "status" means<br>
> > "what's the state of the resource" (Nova, Trove, Cinder, etc), whereas Heat<br>
> > uses status as the state of the last operation. Probably wouldn't be too<br>
> > terrible to have a new "state" for stacks and their resources then perhaps<br>
> > deprecate and use "status" in the accepted way in the v2 API?<br>
><br>
> Well, my point is that it's done inconsistently. Yes, it's mostly used as<br>
> an object status, but nova for example uses it as an operation status for<br>
> things like resize.<br>
<br>
</div></div>Nova's status of in resize is "RESIZE" and "VERITY_RESIZE".<br>
This status means "Currently, Instance is ACTIVE and resize in progress".<br>
I think Heat can assume resource status is "ACTIVE" in this case.<br>
<br>
Thus, several status that contain operation status have to map resource(object)<br>
status. However in my impression, a status that should assume another status<br>
isn't a lot.<br>
<br>
In my opinion, status mapping table is reasonable in present time.<br>
<br>
Regards<br>
<br>
--<br>
Mitsuru Kanabuchi<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>