On Thu, 5 Dec 2013 22:13:18 -0600 Christopher Armstrong <[email protected]> wrote:
> On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt > <[email protected]>wrote: > > > On Dec 5, 2013, at 6:25 PM, Christopher Armstrong < > > [email protected]> > > wrote: > > > > On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita < > > [email protected]> 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. Nova's status of in resize is "RESIZE" and "VERITY_RESIZE". This status means "Currently, Instance is ACTIVE and resize in progress". I think Heat can assume resource status is "ACTIVE" in this case. Thus, several status that contain operation status have to map resource(object) status. However in my impression, a status that should assume another status isn't a lot. In my opinion, status mapping table is reasonable in present time. Regards -- Mitsuru Kanabuchi _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
