Open Stack

> After debugging,  I found that former result is not overridden by
> another policy.
> http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n441

I think you are not referring to a correct location in the source code.
That line was only about checking whether there are some policies failed
checking.
 
> >
> >            2. if  a cluster attached a scaling policy with event =
> >        CLUSTER_SCALE_IN,  when aCLUSTER_SCALING_OUT action is
> >        triggered,  the policy also will be checked,  is this reasonable?
> >
> >/         When a ScalingPolicy is defined, you can use 'event'
> >property to specify the action type you want the policy to take
> >effect on, like:
> >http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5
> >
> >         Although a ScalingPolicy will be checked for both
> >CLUSTER_SCALE_IN and CLUSTER_SCALE_OUT actions, the check routine
> >will return immediately if the action type is not what it is
> >expecting.
> >http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133/
> 
> Yes  it's not checked in pre_op,  but all ScalingPolicies still will
> be checked whether in cooldown.
> http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431*

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.

> >        Your suggestion has a problem when I want different cooldown
> >        for each ceilometer/aodh alarms, for following cases, how
> >        should I do?
> >        1.  15% < cpu_util  < 30%,  scaling_in 1 instance with 300s
> >        cooldown time
> >        2.   cpu_util < 15%, scaling_in 2 instances with 600s
> >         cooldown time
> >
> >        For a senlin webhook, could we assign a policy which will be
> >        checked ?
> >
> >/   User is not allowed to specify the policy when defining a
> >webhook. The webhook target is decided by target object(cluster or
> >node) and target action type./
> 
>     Yes we can define cooldown for each policy, but my meaning is
> that each cluster_scaling_in action is only checked by specified
> scaling_policy like OS::Heat::ScalingPolicy in heat.

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.

>     1） In heat, we could define two scaling_in actions(via define
> two OS::Heat::ScalingPolicy polices ), each scaling_in action is
> checked by one OS::Heat::ScalingPolicy, so each scaling_in action's
> cooldown is only checked in one OS::Heat::ScalingPolicy.
>      2）But in senlin, each scaling_in action will be checked by all
> attached scaling_policies, so all scaling_polices' cooldown will be
> checked.How does senlin support different cooldown time for each
> scaling_in action?

The built-in policy will check if the action is a 'CLUSTER_SCALE_IN'
action or not. The policy is supposed to help you decide the number of
nodes you want to remove from a cluster. If you have a specific
requirement where you want 2 nodes to be removed under one condition, 1
node to be removed under another condition, you will create two webhooks
to explicitly specify that. A scaling policy will respect the 'count'
parameter you speicifed from the webhook.

Each policy has its default cooldown value when created. However, you
can easily override that default value when attaching such a policy to a
cluster. See 'senlin help cluster-policy-attach' for more info.

Regards,
  Qiming