Open Stack

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