<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 2015/11/24 16:41, Qiming Teng wrote:<br>
    </div>
    <blockquote cite="mid:20151124084116.GA9016@qiming-ThinkCentre-M58p"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">After debugging,  I found that former result is not overridden by
another policy.
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n441">http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n441</a>
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    If a cluster attached two scaling_in policies(policy1 with priority
    20 and policy2 with priority 40), <br>
    when  policy_check function is called, it will do policy1 checking
    first and then check policy2.<br>
    If any policy failed, it will return with CHECK_ERROR.  Is this
    conform to your original design?<br>
    <br>
    <blockquote cite="mid:20151124084116.GA9016@qiming-ThinkCentre-M58p"
      type="cite">
      <pre wrap="">
 
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">
           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:
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5">http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5</a>

        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.
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133/">http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133/</a>
</pre>
        </blockquote>
        <pre wrap="">
Yes  it's not checked in pre_op,  but all ScalingPolicies still will
be checked whether in cooldown.
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431*">http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431*</a>
</pre>
      </blockquote>
      <pre wrap="">
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.
</pre>
    </blockquote>
    Fo following case:<br>
    A cluster is attached with two policies as follow.<br>
        policy1:  type=senlin.policy.scaling, cooldown=60s,   event:
    CLUSTER_SCALE_IN<br>
        policy2:  type=senlin.policy.scaling, cooldown=300s, event: <font
      color="#ff0000">CLUSTER_SCALE_OUT</font><br>
    <br>
    Then I do following actions<br>
        1) senlin cluster-scale-in -c 1  mycluster                      
    ----------------------  scale-in  ok<br>
        2) after 70s,  senlin cluster-scale-in -c 1  mycluster     
    -----------------------  scale-in failed, because of policy2 is
    still in cooldown.<br>
    <br>
    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.<br>
    <br>
    <blockquote cite="mid:20151124084116.GA9016@qiming-ThinkCentre-M58p"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">       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./
</pre>
        </blockquote>
        <pre wrap="">
    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.
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    <br>
    I got they are different, I want to know how combine these
    operations(e.g. webhook, <br>
    ScalePolicy, cluster, ceilometer alarms) to realize the autoscaling
    functions like in Heat? <br>
    Hu yanyan has given an combinatorial method,  but I think this
    method doesn't  resolve the case.<br>
    <blockquote cite="mid:20151124084116.GA9016@qiming-ThinkCentre-M58p"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">    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?
</pre>
      </blockquote>
      <pre wrap="">
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.</pre>
    </blockquote>
    I really want to discuss the cooldown checking for multiple polices
    of same type. <br>
    Following is the different for autoscaling in Senlin and Heat.<br>
    In Senlin:<br>
        policy1:  type=senlin.policy.scaling, cooldown=60s,   event:
    CLUSTER_SCALE_IN<br>
        policy2:  type=senlin.policy.scaling, cooldown=300s, event:
    CLUSTER_SCALE_IN<br>
        webhook1: count=1, action=CLUSTER_SCALE_IN<br>
        webhook2: count=2, action=CLUSTER_SCALE_IN<br>
    <br>
       trigger webhook1, all policy1's cooldown and policy2's cooldown
    will be checked.<br>
       trigger webhook2, all policy1's cooldown and policy2's coolddow
    will be checked.<br>
    <br>
    <br>
    In Heat<br>
       policy1: type=OS::Heat::ScalingPolicy, cooldown=60s,
    scaling_adjustment=1    <br>
       policy2: type=OS::Heat::ScalingPolicy, cooldown=300s,
    scaling_adjustment=2  <br>
       policy1 will return a webhook as webhook1.<br>
       policy2 will return a webhook as webhook2.<br>
    <br>
       trigger webhook1, only policy1's cooldown will be checked.<br>
       trigger webhook1, only policy1's cooldown will be checked.<br>
    <br>
    <blockquote cite="mid:20151124084116.GA9016@qiming-ThinkCentre-M58p"
      type="cite">
      <pre wrap="">

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: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Best regards,

Jun Xu</pre>
  </body>
</html>