Open Stack

> From: clint at fewbar.com
> To: openstack-dev at 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 at 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?



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140604/12b9b881/attachment.html>