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
Re: [openstack-dev] [heat] Resource action API
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: 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-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. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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? 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? - 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 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 thanks, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
