Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/916#discussion_r158298780
--- Diff:
core/src/main/java/org/apache/brooklyn/entity/group/DynamicClusterImpl.java ---
@@ -799,6 +795,14 @@ protected Entity replaceMember(Entity member,
@Nullable Location memberLoc, Map<
/** <strong>Note</strong> for sub-classes; this method can be called
while synchronized on {@link #mutex}. */
protected Collection<Entity> grow(int delta) {
Preconditions.checkArgument(delta > 0, "Must call grow with
positive delta.");
+ Integer maxSize = config().get(MAX_SIZE);
+ if (maxSize != null) {
+ final int desiredSize = getCurrentSize() + delta;
+ if (desiredSize > maxSize) {
+ throw new Resizable.InsufficientCapacityException(
--- End diff --
@tbouron I don't think we want another effector or parameter as we wouldn't
get the "desired default behaviour" in our existing usage, e.g. from the
auto-scaler policy (assuming we can agree what that desired behaviour is).
The reason I think we should resize it to as big as we're allowed is that I
believe that is what will work best with our existing usage. For example, if an
auto-scaler thinks we need to go to size 11 but we're only allowed to go to 10,
then leaving it at the existing much smaller size seems very wrong. The
auto-scaler, as currently written, would never discover that if it asked for 10
then it would get it; the auto-scaler would just keep asking for the bigger
value that it thinks is necessary.
I admit it will slightly confuse users if they say "resize to 11" and it
only goes to 10, without anything but a warn message in the log. However, at
least it's done something; and if they call it again with "11" then they'll get
their exception.
---
