Open Stack

On Thu, 5 Dec 2013 22:13:18 -0600
Christopher Armstrong <chris.armstrong at rackspace.com> wrote:

> On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt <randall.burt at rackspace.com>wrote:
> 
> >  On Dec 5, 2013, at 6:25 PM, Christopher Armstrong <
> > chris.armstrong at rackspace.com>
> >  wrote:
> >
> >   On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita <
> > andersonvom at 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.

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