On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt <randall.b...@rackspace.com>wrote:
> On Dec 5, 2013, at 6:25 PM, Christopher Armstrong < > chris.armstr...@rackspace.com> > wrote: > > On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita < > anderson...@thoughtworks.com> wrote: > >> Hey stackers, >> >> We've been working towards making stack convergence ( >> https://blueprints.launchpad.net/heat/+spec/stack-convergence) 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. >> >> The first step (https://blueprints.launchpad.net/heat/+spec/stack-check) >> 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. >> >> 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: >> https://etherpad.openstack.org/p/heat-convergence >> >> Any thoughts? >> >> Cheers, >> >> > 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). > > > 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? > > 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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
