Excerpts from yang zhang's message of 2014-06-04 01:14:37 -0700: > > > From: cl...@fewbar.com > > To: openstack-dev@lists.openstack.org > > Date: Wed, 4 Jun 2014 00:09:39 -0700 > > Subject: Re: [openstack-dev] [Spam] [heat] Resource action API > > > > Excerpts from yang zhang's message of 2014-06-04 00:01:41 -0700: > > > > > > > > > > > > > > > > > > > > > Hi all, Now heat only supports suspending/resuming a whole stack, all > > > the resources of the stack will be suspended/resumed,but sometime we just > > > want to suspend or resume only a part of resources in the stack, so I > > > think adding resource-action API for heat isnecessary. this API will be > > > helpful to solve 2 problems: - If we want to suspend/resume the > > > resources of the stack, you need to get the phy_id first and then call > > > the API of other services, and this won't update the statusof the > > > resource in heat, which often cause some unexpected problem. - this > > > API could offer a turn on/off function for some native resources, e.g., > > > we can turn on/off the autoscalinggroup or a single policy with the API, > > > this is like the suspend/resume services feature[1] in AWS. I > > > registered a bp for it, and you are welcome for discussing it. > > > https://blueprints.launchpad.net/heat/+spec/resource-action-api > > > [1] > > > http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/US_SuspendResume.html > > > Regards!Zhang Yang > > > > Hi zhang. I'd rather we model the intended states of each resource, and > > ensure that Heat can assert them. Actions are tricky things to model. > > > > So if you want your nova server to be stopped, how about > > > > resources: > > server1: > > type: OS::Nova::Server > > properties: > > flavor: superbig > > image: TheBestOS > > state: STOPPED> > We don't really need to model "actions" then, just > > the API's we have > > available. > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > At first, I want to do it like this, using a resource parameter, but this > need to update the stack in order to suspend the Resource, It means we can't > stop another resource when a resource is stopping, but it seems not a big > deal, stopping resource usually is soon, compare to API, using resource > parameter is easy to implement as the result of mature code of stack-update, > we could finish it in a short period. > Does anyone else have good ideas? >
It's a bit far off, but the eventual goal of the convergence effort is to make it so you _can_ update two things concurrently, since updates will just be recording intended state in the db, not waiting for all of that to complete. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
