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.
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?
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.
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.
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.
--
Best regards,
Yanyan
--
Best regards,
Yanyan
__
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
