<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi, Xu Jun, please find some answers inline. Thanks.<br><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-11-20 16:06 GMT+08:00 <a href="mailto:xujun@cmss.chinamobile.com" target="_blank">xujun@cmss.chinamobile.com</a> <span dir="ltr"><<a href="mailto:xujun@cmss.chinamobile.com" target="_blank">xujun@cmss.chinamobile.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div><span></span></div><blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div><div dir="ltr"><div><div><div><font color="#ff0000">Thanks yanyan!</font></div><span><div><br></div>Xu Jun is a contributor from CMCC. He asked a very interesting question about cluster scaling support in Senlin. To make the discussion more thorough, I just post the question and my answer here.<br><br></span></div><span>The question from Jun is as following:<br><br>For an action, senlin will check all according polices, like if a cluster attach two scaling-in polices, <br>the two scaling-in polices will be checked when doing a scaling-action on this cluster. This is not same as OS::Heat::ScalingPolicy in heat?<br>How should I use senlin for following cases?<br>1. 15% < cpu_util < 30%, scaling_in 1 instance<br>2. cpu_util < 15%, scaling_in 2 instances<br><br>This is a very interesting question and you're right about the difference between Senlin ScalingPolicy and OS::Heat::ScalingPolicy. In Heat, OS::Heat::ScalingPolicy is actually not just a policy. It is a combination of a webhook and a rule about how ASG respond to the webhook triggering(resource signal). So you can define two different OS::Heat::ScalingPolicy instances to make them deal with two cases you described respectively.<br><br>But in Senlin, ScalingPolicy is a REAL policy, it only describes how a Senlin cluster react to an action triggered by Senlin webhook which is defined separately. The problem is when an cluster action e.g. CLUSTER_SCALE_IN is triggered, all policies attached to it will be checked in sequence based on policies priority definition.<strike> </strike><u><font color="#ff9900">So if you create two Senlin ScalingPolicy and attach them to the same cluster, only one of them will take effect actually.</font></u></span></div><div><u><font color="#ff9900"><br></font></u></div><div><font color="#0000ff"># 1. But in policy_check function, all the policies will be checked in priority-based order for a CLUSTER_SCALING_IN action if the cluster attached with SCALING multiple policies. </font></div><div><font color="#0000ff"> is this a bug? or what <span style="font-size:10.5pt;line-height:1.5;background-color:window"> is the </span><span style="font-family:"";font-size:10.5pt;line-height:1.5;background-color:window">significance</span><font style="font-size:10.5pt;line-height:1.5;background-color:window"><span style="font-size:10.5pt;line-height:1.5;background-color:window"> of prority</span></font></font><span style="font-size:10.5pt;line-height:1.5;background-color:window;color:rgb(0,0,255)">). </span></div></div></div></blockquote></div></blockquote></span><div> <span style="color:rgb(255,0,0)"><span style="background-color:rgb(255,255,255)"> <i>Sorry, I didn't describe it clearly. I mean although both scaling policies will be checked before CLUSTER_SCALING_IN action is executed, count result from one ScalingPolicy will actually be overridden by the result from another ScalingPolicy which has higher priority. </i></span></span><br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div><div dir="ltr"><div><font color="#0000ff"> 2. if a cluster attached a scaling policy with event = <span style="font-family:"";font-size:10.5pt;line-height:1.5;background-color:window">CLUSTER_SCALE_IN, when a</span><font style="font-size:10.5pt;line-height:1.5;background-color:window"> </font><span style="font-size:10.5pt;line-height:1.5;background-color:window">CLUSTER_SCALING_OUT </span><span style="font-size:10.5pt;line-height:1.5;background-color:window">action is triggered, the policy also will be checked, is this reasonable?</span></font></div></div></div></blockquote></div></blockquote></span><div><span style="color:rgb(255,0,0)"><i> When a ScalingPolicy is defined, you can use 'event' property to specify the action type you want the policy to take effect on, like:<br> <a href="http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5" target="_blank">http://git.openstack.org/cgit/openstack/senlin/tree/examples/policies/scaling_policy.yaml#n5</a><br><br> 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. <br> <a href="http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133" target="_blank">http://git.openstack.org/cgit/openstack/senlin/tree/senlin/policies/scaling_policy.py#n133</a></i></span><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div><div dir="ltr"><span><div><br><br>Currently, you can use the following way to support your use case in Senlin:<br>1. Define two Senlin webhooks which target on the CLUSTER_SCALE_OUT action of the cluster and specify the 'param' as {'count': 1} for webhook1 and {'count': 2 } for webhook2;<br>1. Define two ceilometer/aodh alarms with the first one matching case1 and second one matching case2. Then define webhook1 url as alarm1's alarm-action and webhook2 url as alarm2's alarm-action.</div><div><br></div></span><div><font color="#0000ff"># </font></div><div><font color="#0000ff">Your suggestion has a problem when I want different cooldown for each <span style="font-size:10.5pt;line-height:1.5;background-color:window">ceilometer/aodh </span><span style="font-size:10.5pt;line-height:1.5;background-color:window">alarms, for following cases, how should I do?</span></font></div><div><font color="#0000ff">1. 15% < cpu_util < 30%, scaling_in 1 instance with 300s cooldown time<br>2. cpu_util < 15%, scaling_in 2 instances with 600s cooldown time</font></div></div></div></blockquote></div></blockquote></span><div><span style="color:rgb(255,0,0)"><i> You can define the cooldown by specifying it when creating the policy or attaching it to a cluster. The cooldown check logic will prevent a policy taking effect if cooldown is still in progress.<br> <a href="http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431" target="_blank">http://git.openstack.org/cgit/openstack/senlin/tree/senlin/engine/actions/base.py#n431</a><br></i></span> </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div><div dir="ltr"><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">For a senlin webhook, could we assign a policy which will be checked ?</font></div></div></div></blockquote></div></blockquote></span><div> <i><span style="color:rgb(255,0,0)"> 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.</span></i><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote style="margin-top:0px;margin-bottom:0px;margin-left:0.5em"><div><div dir="ltr"><span><div><br>Then each time alarm1 is triggered, cluster will be scaled out with count 1 which means one new node will be created and added to cluster. When alarm2 is triggered, cluster will be scaled out with count 2 that two new nodes will be created and added to cluster.<br><br>The question you asked is really interesting and we did consider to support this kind of requirement using a 'complex' ScalingPolicy which defined both trigger(alarm), webhook and some rules for scaling. But after some discussion, we felt that maybe we should let some high level service/enduser to define this kind of 'POLICY' since it's more like a workflow definition rather than a description of the rule cluster scaling. So currently, we only provide atomic operation(e.g. webhook, 'simple' ScalingPolicy) in Senlin while leaving the work of combining these operations to support a use case to enduser/high-level service.<br><br>Thanks a lot for throwing this interesting question and I do agree that we should make more discussion about it to think whether we need to adjust our policy design to support this kind of scenario more smoothly.<br><br>--</div><div><div><div><div><div><div><div>Best regards,<div><br></div><div>Yanyan</div></div>
</div></div></div></div></div></div></span></div>
</div></blockquote>
</div></blockquote></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"></font></span><br></div></div></div>-- <br><div class="gmail_signature">Best regards,<div><br></div><div>Yanyan</div></div>
</div>