Re: [openstack-dev] [heat] Stack convergence first steps
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.mits...@po.ntts.co.jp On Thu, 5 Dec 2013 22:13:18 -0600 Christopher Armstrong chris.armstr...@rackspace.com wrote: On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt randall.b...@rackspace.com wrote: On Dec 5, 2013, at 6:25 PM, Christopher Armstrong chris.armstr...@rackspace.com wrote: On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita anderson...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Stack convergence first steps
On Dec 10, 2013, at 1:03 PM, Anderson Mesquita anderson...@thoughtworks.commailto:anderson...@thoughtworks.com wrote: 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? IMO, this sort of change should be proposed for the v2 api, since there are already expectations in the v1 api as to what these things mean. For v1, I wouldn't be opposed to adding a synthetic resource_state attribute that reflects the actual status of the underlying resource (ACTIVE, RESIZE, etc). 2013/12/8 Mitsuru Kanabuchi kanabuchi.mits...@po.ntts.co.jpmailto:kanabuchi.mits...@po.ntts.co.jp On Thu, 5 Dec 2013 22:13:18 -0600 Christopher Armstrong chris.armstr...@rackspace.commailto:chris.armstr...@rackspace.com wrote: On Thu, Dec 5, 2013 at 7:25 PM, Randall Burt randall.b...@rackspace.commailto:randall.b...@rackspace.comwrote: On Dec 5, 2013, at 6:25 PM, Christopher Armstrong chris.armstr...@rackspace.commailto:chris.armstr...@rackspace.com wrote: On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita anderson...@thoughtworks.commailto:anderson...@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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Stack convergence first steps
On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita anderson...@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). -- IRC: radix Christopher Armstrong Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Stack convergence first steps
On Dec 5, 2013, at 6:25 PM, Christopher Armstrong chris.armstr...@rackspace.commailto:chris.armstr...@rackspace.com wrote: On Thu, Dec 5, 2013 at 3:50 PM, Anderson Mesquita anderson...@thoughtworks.commailto:anderson...@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? -- IRC: radix Christopher Armstrong Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
