To try and keep this conversation moving forward, is it safe to say that we at least need to change the current status attribute to something like action_status? And the same with status_reason being changed to action_status_reason? Does anybody see a reason why we shouldn't go this way, since it's really what status currently refers to?
2013/12/8 Mitsuru Kanabuchi <[email protected]> > > 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 >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
