<div dir="ltr"><div><div><div>Hi, guys,<br><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></div>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. So if you create two Senlin ScalingPolicy and attach them to the same cluster, only one of them will take effect actually.<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.<br><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 class="gmail_signature">Best regards,<div><br></div><div>Yanyan</div></div>
</div></div></div></div></div></div></div>