[
https://issues.apache.org/jira/browse/BROOKLYN-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066319#comment-15066319
]
ASF GitHub Bot commented on BROOKLYN-207:
-----------------------------------------
Github user sjcorbett commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/1109#issuecomment-166270746
See https://issues.apache.org/jira/browse/BROOKLYN-207.
> Cluster policy robustness
> -------------------------
>
> Key: BROOKLYN-207
> URL: https://issues.apache.org/jira/browse/BROOKLYN-207
> Project: Brooklyn
> Issue Type: Improvement
> Reporter: Sam Corbett
>
> Policies applied to clusters and groups must take the state of their members
> into account. If they do not they risk taking decisions based on stale data.
> See https://github.com/apache/incubator-brooklyn/pull/1109 for more context.
> @aledsage said:
> {quote}
> I think that long-term the right philosophy is that the service-down should
> trigger the removal of this node from the calculations. Until that point, we
> don't have enough info to know if it's still working away at its previous
> load (in which case we don't want to zero the requests-per-second by
> publishing the same total-request-count again), or if it is not doing
> anything.
> If it were genuinely not doing anything, then we should mark it as
> service-down.
> This is obviously a fiddly thing to get right, particularly as there are
> several failure scenarios and there are different ways the metrics are being
> used.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
