> 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?
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
