Re: [openstack-dev] [heat] Resource action API
Thanks so much for your commits. Date: Wed, 4 Jun 2014 14:39:30 -0400 From: zbit...@redhat.com To: openstack-dev@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-stackfor 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. - 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. I registered a bp for it, and you are welcome for discussing it. https://blueprints.launchpad.net/heat/+spec/resource-action-api Please propose blueprints to the heat-specs repo: http://lists.openstack.org/pipermail/openstack-dev/2014-May/036432.html I'm sorry for it, I didn't notice the mail, and I will do it soon. thanks, Zane. Regards.Zhang Yang___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] Resource action API
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Spam] [heat] Resource action API
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
