Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131205/b20ea450/attachment.html>