On Wed, Nov 25, 2015 at 03:58:35PM +0800, Jun Xu wrote: > > If a cluster attached two scaling_in policies(policy1 with priority > 20 and policy2 with priority 40), > when policy_check function is called, it will do policy1 checking > first and then check policy2. > If any policy failed, it will return with CHECK_ERROR. Is this > conform to your original design?
yes, any policy check failure would mean the action was not supposed to be executed. ... > >Each policy instances creates its own policy-binding on a cluster. The > >cooldown is recorded and then checked there. I can sense something is > >wrong, but so far I'm not quite sure I understand the specific use case > >that the current logic fails to support. > Fo following case: > A cluster is attached with two policies as follow. > policy1: type=senlin.policy.scaling, cooldown=60s, event: > CLUSTER_SCALE_IN > policy2: type=senlin.policy.scaling, cooldown=300s, event: > CLUSTER_SCALE_OUT > > Then I do following actions > 1) senlin cluster-scale-in -c 1 mycluster > ---------------------- scale-in ok > 2) after 70s, senlin cluster-scale-in -c 1 mycluster > ----------------------- scale-in failed, because of policy2 is > still in cooldown. This sounds more like a bug in policy checking. Please help raise a bug, we can jump onto it later. > Now 'cooldown' is a common property for any kind of policy, I think > this property maybe not necessary for all kind of policy like > LB_POLICY. This is actually a good point. Will bring this to the team for a discussion. Thanks. > >This is a misconcept because a Senlin policy is not a Heat > >ScalingPolicy. A Senlin policy is checked before and/or after a > >specified action is performed. > > I got they are different, I want to know how combine these > operations(e.g. webhook, > ScalePolicy, cluster, ceilometer alarms) to realize the autoscaling > functions like in Heat? > Hu yanyan has given an combinatorial method, but I think this > method doesn't resolve the case. Emm, I think we need to provide a tutorial document in tree. > I really want to discuss the cooldown checking for multiple polices > of same type. > Following is the different for autoscaling in Senlin and Heat. > In Senlin: > policy1: type=senlin.policy.scaling, cooldown=60s, event: > CLUSTER_SCALE_IN > policy2: type=senlin.policy.scaling, cooldown=300s, event: > CLUSTER_SCALE_IN > webhook1: count=1, action=CLUSTER_SCALE_IN > webhook2: count=2, action=CLUSTER_SCALE_IN > > trigger webhook1, all policy1's cooldown and policy2's cooldown > will be checked. > trigger webhook2, all policy1's cooldown and policy2's coolddow > will be checked. > > > In Heat > policy1: type=OS::Heat::ScalingPolicy, cooldown=60s, > scaling_adjustment=1 > policy2: type=OS::Heat::ScalingPolicy, cooldown=300s, > scaling_adjustment=2 > policy1 will return a webhook as webhook1. > policy2 will return a webhook as webhook2. > > trigger webhook1, only policy1's cooldown will be checked. > trigger webhook1, only policy1's cooldown will be checked. > Think about this, why do you have 'cooldown' property? It is mainly designed to avoid thrashing behavior of a cluster/group, right? It doesn't make a lot senses to me having each webhook specifying a different 'cooldown' value. In other words, 'cooldown' could be set to be a property of the cluster/group. The cooldown checking logic you outlined above hit the point -- should we shield the cluster from any scaling requests during a 'cooldown' phase? My answer would be yes. It is the cluster you want to protect, not the policy or action. With that, we will discuss whether it makes sense to make 'cooldown' a cluster property instead of a policy property. Thanks, Qiming __________________________________________________________________________ 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
