Currently, when Marathon restarts an app and evaluates constraints for
placement of new instances, it only considers placed instances with the
same configVersion. For example, if you have a hostname:UNIQUE
constraint and perform a rolling upgrading, Marathon will allow two
instances to be placed on the same node as long as their configVersion
is different.
When a Marathon app is restarted, however, the version is updated, but
the configVersion remains the same. This means that Marathon will
consider to-be-killed instances as part of the input for placements in
constraints. For things like GROUP_BY, this is leading to the constraint
ultimately being invalid.
This change seeks to change that behaviour by separating ScaleChanges
and RestartChanges and letting the latter modify lastConfigChangeAt.
… (#7251)
Currently, when Marathon restarts an app and evaluates constraints for placement of new instances, it only considers placed instances with the same configVersion. For example, if you have a hostname:UNIQUE constraint and perform a rolling upgrading, Marathon will allow two instances to be placed on the same node as long as their configVersion is different. When a Marathon app is restarted, however, the version is updated, but the configVersion remains the same. This means that Marathon will consider to-be-killed instances as part of the input for placements in constraints. For things like GROUP_BY, this is leading to the constraint ultimately being invalid.
This change seeks to change that behaviour by separating ScaleChanges and RestartChanges and letting the latter modify
lastConfigChangeAt.JIRA issues: