[openstack-dev] [heat] Resource action API
zbitter at redhat.com
Thu Jun 5 22:03:46 UTC 2014
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 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.
More information about the OpenStack-dev