Thanks Angus for feedback. Best, Dani
On Mon, Apr 6, 2015 at 11:30 PM, Angus Salkeld <[email protected]> wrote: > > On Fri, Apr 3, 2015 at 8:51 PM, Daniel Comnea <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> wrote: >>> >>>> Daniel Comnea <[email protected]> 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 >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
