Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Thanks Angus for feedback. Best, Dani On Mon, Apr 6, 2015 at 11:30 PM, Angus Salkeld wrote: > > On Fri, Apr 3, 2015 at 8:51 PM, Daniel Comnea > wrote: > >> Hi all, >> >> Does anyone know if the above use case has made it into the convergence >> project and in which release was/ is going to be merged? >> >> > Hi > > Phase one of convergence should be merged in early L (we have some of the > patches merged now). > Phase two is to separate the "checking" of actual state into a new RPC > service within Heat. > Then you *could* run that checker periodically (or receive RPC > notifications) to learn of changes > to the stack's state during the lifetime of the stack. That *might* get > done in L - we will just have to see > how things go. > > -Angus > > >> Thanks, >> Dani >> >> On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea >> wrote: >> >>> Thanks all for reply. >>> >>> I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed >>> this is not possible as of today. Someone else - sorry i forgot his nicname >>> on IRC suggested to write a Ceilometer query to count the number of >>> instances but what @ZhiQiang said is true and this is what we have seen via >>> the instance sample >>> >>> *@Clint - *that is the case indeed >>> >>> *@ZhiQiang* - what do you mean by "*count of resource should be queried >>> from specific service's API*"? Is it related to Ceilometer's event >>> types configuration? >>> >>> *@Mike - *my use case is very simple: i have a group of instances and >>> in case the # of instances reach the minimum number i set, i would like a >>> new instance to be spun up - think like a cluster where i want to maintain >>> a minimum number of members >>> >>> With regards to the proposal you made - >>> https://review.openstack.org/#/c/127884/ that works but only in a >>> specific use case hence is not generic because the assumption is that my >>> instances are hooked behind a LBaaS which is not always the case. >>> >>> Looking forward to see the 'convergence' in action. >>> >>> >>> Cheers, >>> Dani >>> >>> On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer >>> wrote: >>> Daniel Comnea wrote on 10/27/2014 07:16:32 AM: > Yes i did but if you look at this example > > https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml > > the flow is simple: > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" > which then triggers the "type: OS::Heat::AutoScalingGroup" Actually the ScalingPolicy does not "trigger" the ASG. BTW, "ScalingPolicy" is mis-named; it is not a full policy, it is only an action (the condition part is missing --- as you noted, that is in the Ceilometer alarm). The so-called ScalingPolicy does the action itself when triggered. But it respects your configured min and max size. What are you concerned about making your scaling group smaller than your configured minimum? Just checking here that there is not a misunderstanding. As Clint noted, there is a large-scale effort underway to make Heat maintain what it creates despite deletion of the underlying resources. There is also a small-scale effort underway to make ASGs recover from members stopping proper functioning for whatever reason. See https://review.openstack.org/#/c/127884/ for a proposed interface and initial implementation. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
On Fri, Apr 3, 2015 at 8:51 PM, Daniel Comnea wrote: > Hi all, > > Does anyone know if the above use case has made it into the convergence > project and in which release was/ is going to be merged? > > Hi Phase one of convergence should be merged in early L (we have some of the patches merged now). Phase two is to separate the "checking" of actual state into a new RPC service within Heat. Then you *could* run that checker periodically (or receive RPC notifications) to learn of changes to the stack's state during the lifetime of the stack. That *might* get done in L - we will just have to see how things go. -Angus > Thanks, > Dani > > On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea > wrote: > >> Thanks all for reply. >> >> I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed >> this is not possible as of today. Someone else - sorry i forgot his nicname >> on IRC suggested to write a Ceilometer query to count the number of >> instances but what @ZhiQiang said is true and this is what we have seen via >> the instance sample >> >> *@Clint - *that is the case indeed >> >> *@ZhiQiang* - what do you mean by "*count of resource should be queried >> from specific service's API*"? Is it related to Ceilometer's event types >> configuration? >> >> *@Mike - *my use case is very simple: i have a group of instances and in >> case the # of instances reach the minimum number i set, i would like a new >> instance to be spun up - think like a cluster where i want to maintain a >> minimum number of members >> >> With regards to the proposal you made - >> https://review.openstack.org/#/c/127884/ that works but only in a >> specific use case hence is not generic because the assumption is that my >> instances are hooked behind a LBaaS which is not always the case. >> >> Looking forward to see the 'convergence' in action. >> >> >> Cheers, >> Dani >> >> On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer >> wrote: >> >>> Daniel Comnea wrote on 10/27/2014 07:16:32 AM: >>> >>> > Yes i did but if you look at this example >>> > >>> > >>> https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml >>> > >>> >>> > the flow is simple: >>> >>> > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" >>> > which then triggers the "type: OS::Heat::AutoScalingGroup" >>> >>> Actually the ScalingPolicy does not "trigger" the ASG. BTW, >>> "ScalingPolicy" is mis-named; it is not a full policy, it is only an action >>> (the condition part is missing --- as you noted, that is in the Ceilometer >>> alarm). The so-called ScalingPolicy does the action itself when >>> triggered. But it respects your configured min and max size. >>> >>> What are you concerned about making your scaling group smaller than your >>> configured minimum? Just checking here that there is not a >>> misunderstanding. >>> >>> As Clint noted, there is a large-scale effort underway to make Heat >>> maintain what it creates despite deletion of the underlying resources. >>> >>> There is also a small-scale effort underway to make ASGs recover from >>> members stopping proper functioning for whatever reason. See >>> https://review.openstack.org/#/c/127884/ for a proposed interface and >>> initial implementation. >>> >>> Regards, >>> Mike >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Hi all, Does anyone know if the above use case has made it into the convergence project and in which release was/ is going to be merged? Thanks, Dani On Tue, Oct 28, 2014 at 5:40 PM, Daniel Comnea wrote: > Thanks all for reply. > > I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed > this is not possible as of today. Someone else - sorry i forgot his nicname > on IRC suggested to write a Ceilometer query to count the number of > instances but what @ZhiQiang said is true and this is what we have seen via > the instance sample > > *@Clint - *that is the case indeed > > *@ZhiQiang* - what do you mean by "*count of resource should be queried > from specific service's API*"? Is it related to Ceilometer's event types > configuration? > > *@Mike - *my use case is very simple: i have a group of instances and in > case the # of instances reach the minimum number i set, i would like a new > instance to be spun up - think like a cluster where i want to maintain a > minimum number of members > > With regards to the proposal you made - > https://review.openstack.org/#/c/127884/ that works but only in a > specific use case hence is not generic because the assumption is that my > instances are hooked behind a LBaaS which is not always the case. > > Looking forward to see the 'convergence' in action. > > > Cheers, > Dani > > On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer > wrote: > >> Daniel Comnea wrote on 10/27/2014 07:16:32 AM: >> >> > Yes i did but if you look at this example >> > >> > >> https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml >> > >> >> > the flow is simple: >> >> > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" >> > which then triggers the "type: OS::Heat::AutoScalingGroup" >> >> Actually the ScalingPolicy does not "trigger" the ASG. BTW, >> "ScalingPolicy" is mis-named; it is not a full policy, it is only an action >> (the condition part is missing --- as you noted, that is in the Ceilometer >> alarm). The so-called ScalingPolicy does the action itself when >> triggered. But it respects your configured min and max size. >> >> What are you concerned about making your scaling group smaller than your >> configured minimum? Just checking here that there is not a >> misunderstanding. >> >> As Clint noted, there is a large-scale effort underway to make Heat >> maintain what it creates despite deletion of the underlying resources. >> >> There is also a small-scale effort underway to make ASGs recover from >> members stopping proper functioning for whatever reason. See >> https://review.openstack.org/#/c/127884/ for a proposed interface and >> initial implementation. >> >> Regards, >> Mike >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Thanks all for reply. I have spoke with Qiming and @Shardy (IRC nickname) and they confirmed this is not possible as of today. Someone else - sorry i forgot his nicname on IRC suggested to write a Ceilometer query to count the number of instances but what @ZhiQiang said is true and this is what we have seen via the instance sample *@Clint - *that is the case indeed *@ZhiQiang* - what do you mean by "*count of resource should be queried from specific service's API*"? Is it related to Ceilometer's event types configuration? *@Mike - *my use case is very simple: i have a group of instances and in case the # of instances reach the minimum number i set, i would like a new instance to be spun up - think like a cluster where i want to maintain a minimum number of members With regards to the proposal you made - https://review.openstack.org/#/c/127884/ that works but only in a specific use case hence is not generic because the assumption is that my instances are hooked behind a LBaaS which is not always the case. Looking forward to see the 'convergence' in action. Cheers, Dani On Tue, Oct 28, 2014 at 3:06 AM, Mike Spreitzer wrote: > Daniel Comnea wrote on 10/27/2014 07:16:32 AM: > > > Yes i did but if you look at this example > > > > > https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml > > > > > the flow is simple: > > > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" > > which then triggers the "type: OS::Heat::AutoScalingGroup" > > Actually the ScalingPolicy does not "trigger" the ASG. BTW, > "ScalingPolicy" is mis-named; it is not a full policy, it is only an action > (the condition part is missing --- as you noted, that is in the Ceilometer > alarm). The so-called ScalingPolicy does the action itself when > triggered. But it respects your configured min and max size. > > What are you concerned about making your scaling group smaller than your > configured minimum? Just checking here that there is not a > misunderstanding. > > As Clint noted, there is a large-scale effort underway to make Heat > maintain what it creates despite deletion of the underlying resources. > > There is also a small-scale effort underway to make ASGs recover from > members stopping proper functioning for whatever reason. See > https://review.openstack.org/#/c/127884/ for a proposed interface and > initial implementation. > > Regards, > Mike > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Daniel Comnea wrote on 10/27/2014 07:16:32 AM: > Yes i did but if you look at this example > > https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml > > the flow is simple: > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" > which then triggers the "type: OS::Heat::AutoScalingGroup" Actually the ScalingPolicy does not "trigger" the ASG. BTW, "ScalingPolicy" is mis-named; it is not a full policy, it is only an action (the condition part is missing --- as you noted, that is in the Ceilometer alarm). The so-called ScalingPolicy does the action itself when triggered. But it respects your configured min and max size. What are you concerned about making your scaling group smaller than your configured minimum? Just checking here that there is not a misunderstanding. As Clint noted, there is a large-scale effort underway to make Heat maintain what it creates despite deletion of the underlying resources. There is also a small-scale effort underway to make ASGs recover from members stopping proper functioning for whatever reason. See https://review.openstack.org/#/c/127884/ for a proposed interface and initial implementation. Regards, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Ceilometer mixes notifications and pollsters, so instance sample cannot represents how many instances (sample-list nor statistics), when we specify a time range in API query, the count of samples is not precise to real situation, it is ether less (due to potential lag when time range is precise) or more (due to redundant when time range has been extended a bit to avoid lag) IMHO, count of resource should be queried from specific service's API On Tue, Oct 28, 2014 at 12:00 AM, Clint Byrum wrote: > Excerpts from Daniel Comnea's message of 2014-10-27 04:16:32 -0700: > > Yes i did but if you look at this example > > > > > https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml > > > > > > the flow is simple: > > > > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" > which > > then triggers the "type: OS::Heat::AutoScalingGroup" > > > > > > > > Now what i want is to be able to always maintain a min number of > instances > > in my Group, if is min_size been reached than trigger HEAT to spun a new > > one to be min_size + n > > > > Sounds like you're expecting Heat to respond to the stop/delete of one > of the instances in the group. > > It doesn't do that.. yet. There's a very large scale effort under way > called 'convergence' that will add such a capability to Heat (by having > Heat try to assert that reality should match intention). Until then it > doesn't support this use case very well. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Excerpts from Daniel Comnea's message of 2014-10-27 04:16:32 -0700: > Yes i did but if you look at this example > > https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml > > > the flow is simple: > > CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" which > then triggers the "type: OS::Heat::AutoScalingGroup" > > > > Now what i want is to be able to always maintain a min number of instances > in my Group, if is min_size been reached than trigger HEAT to spun a new > one to be min_size + n > Sounds like you're expecting Heat to respond to the stop/delete of one of the instances in the group. It doesn't do that.. yet. There's a very large scale effort under way called 'convergence' that will add such a capability to Heat (by having Heat try to assert that reality should match intention). Until then it doesn't support this use case very well. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
Yes i did but if you look at this example https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml the flow is simple: CPU alarm in Ceilometer triggers the "type: OS::Heat::ScalingPolicy" which then triggers the "type: OS::Heat::AutoScalingGroup" Now what i want is to be able to always maintain a min number of instances in my Group, if is min_size been reached than trigger HEAT to spun a new one to be min_size + n On Sat, Oct 25, 2014 at 5:23 PM, Qiming Teng wrote: > On Sat, Oct 25, 2014 at 07:58:28AM +0100, Daniel Comnea wrote: > > HI all, > > > > > > Unfortunately i couldn't find any resource - blueprint/ document/ > examples/ > > presentations about my below use case, hence the question i'm raising now > > (if this is not the best place to ask, please let me know). > > > > > > Having a group of 5 instances, i'd like to always maintain a minimum of 2 > > instances by using the HEAT autoscaling feature and Ceilometer? > > Did you try set the 'min_size' property of your auto-scaling group? > > Qiming > > > I've seen the Wordpress autoscalling examples based on cpu_util metric > but > > my use case is more on the number of instances. > > > > > > Cheers, > > Dani > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
On Sat, Oct 25, 2014 at 07:58:28AM +0100, Daniel Comnea wrote: > HI all, > > > Unfortunately i couldn't find any resource - blueprint/ document/ examples/ > presentations about my below use case, hence the question i'm raising now > (if this is not the best place to ask, please let me know). > > > Having a group of 5 instances, i'd like to always maintain a minimum of 2 > instances by using the HEAT autoscaling feature and Ceilometer? Did you try set the 'min_size' property of your auto-scaling group? Qiming > I've seen the Wordpress autoscalling examples based on cpu_util metric but > my use case is more on the number of instances. > > > Cheers, > Dani > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group
HI all, Unfortunately i couldn't find any resource - blueprint/ document/ examples/ presentations about my below use case, hence the question i'm raising now (if this is not the best place to ask, please let me know). Having a group of 5 instances, i'd like to always maintain a minimum of 2 instances by using the HEAT autoscaling feature and Ceilometer? I've seen the Wordpress autoscalling examples based on cpu_util metric but my use case is more on the number of instances. Cheers, Dani ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
