Open Stack

On 05/06/14 03:32, yang zhang wrote:
>
> Thanks so much for your commits.
>
>  > Date: Wed, 4 Jun 2014 14:39:30 -0400
>  > From: zbitter at redhat.com
>  > To: openstack-dev at lists.openstack.org
>  > Subject: Re: [openstack-dev] [heat] Resource action API
>  >
>  > On 04/06/14 03:01, yang zhang wrote:
>  > > 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
>  >
>  > Any reason you wouldn't put that subset of resources into a nested stack
>  > and suspend/resume that?
>
>     I think that using nested-stack is a little complicated, and we
> can't build a nested-stack
> for each resource, hope this bp could make it easier.
>  >
>  > > in the stack, so I think adding resource-action API for heat is
>  > > necessary. this API will be helpful to solve 2 problems:
>  >
>  > I'm sceptical of this idea because the whole justification for having
>  > suspend/resume in Heat is that it's something that needs to follow the
>  > same dependency tree as stack delete/create.
>  >
>  > Are you suggesting that if you suspend an individual resource, all of
>  > the resources dependent on it will also be suspended?
>
>      I thought about this, and I think just suspending an individual
> resource without dependent
> is ok, now the resources that can be suspended are very few, and almost
> all of those resources
> (Server, alarm, user, etc) could be suspended individually.

Then just suspend them individually using their own APIs. If there's no 
orchestration involved then it doesn't belong in Heat.

>  > > - 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 status
>  > > of the resource in heat, which often cause some unexpected problem.
>  >
>  > This is true, except for stack resources, which obviously _do_ store the
>  > state.
>  >
>  > > - 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.
>  >
>  > Which, I notice, is not exposed in CloudFormation.
>
>   I found it on AWS web, It seems a auotscalinggroup feature, this may
> be not
>   exposed in CloudFormation, but I think it's really a good idea.

Sure, but the solution here is to have a separate Autoscaling API (this 
is a long-term goal for us already) that exposes this feature.

cheers,
Zane.