[openstack-dev] [heat] Stack convergence first steps

Anderson Mesquita andersonvom at thoughtworks.com
Tue Dec 10 19:03:41 UTC 2013


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 <kanabuchi.mitsuru at po.ntts.co.jp>

>
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/1f95a721/attachment.html>


More information about the OpenStack-dev mailing list