Open Stack

Excerpts from yang zhang's message of 2014-06-04 01:14:37 -0700:
> 
> > 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?
> 

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.