Open Stack

On 2015/11/24 16:41, Qiming Teng wrote:
>> 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.

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?

>   
>>>             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.
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.

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.

>>>         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.

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.
>
>>      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.
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.

>
> 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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Best regards,

Jun Xu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151125/86b4d46b/attachment.html>