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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best regards,
Jun Xu
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
