+1 On Tue, Apr 7, 2015 at 12:59 PM, Suman Karumuri < [email protected]> wrote:
> +1 for scale command. > > On Tue, Apr 7, 2015 at 12:45 PM, Kevin Sweeney > <[email protected] > > wrote: > > > How about a scale command somewhere that will check that the only > operation > > it's doing is "scaling" and not introducing new code. This could be > > accomplished by diffing the config for the new instances with that of the > > old instances. For cases where it's not a pure scale operation, maybe > have > > an override flag like --allow-heterogenous. Also, the existing updater > > should handle this case fine if the config hasn't changed - it won't > > attempt to modify unchanged instances. Maybe we need to update diff to > give > > an easy way to ensure that a proposed change is a pure scale operation > and > > not a combination of scaling and a code deploy. > > > > On Tuesday, April 7, 2015, Joe Smith (JIRA) <[email protected]> wrote: > > > > > Joe Smith created AURORA-1258: > > > --------------------------------- > > > > > > Summary: Improve procedure for adding instances to a job > > > Key: AURORA-1258 > > > URL: > https://issues.apache.org/jira/browse/AURORA-1258 > > > Project: Aurora > > > Issue Type: Story > > > Components: Reliability, Usability > > > Reporter: Joe Smith > > > > > > > > > The current process for adding instances to a job is highly manual, and > > > potentially dangerous. > > > > > > 1. Take a config for a job with 10 instances, update it to 20 > instances. > > > 2. The batch size will be increased, and users will need to specify > > shards > > > 10 to 19. > > > 3. After this update is complete, users will need to manually update > > > shards 0-9 again. > > > > > > There may be other changes pulled in as part of this update other than > > > just increasing the number of instances, which could further complicate > > > things. > > > > > > One possible improvement would be to change the updater from > > > 'under-provision' where it kills instances first, then schedules new > > > instances, to an 'over-provision' where it adds on new instances, then > > > backpedals and kills the old instances. > > > > > > Overall, a single command or process for a user to take an > > > already-existing job and increase the number of instances would reduce > > > overhead and fat-fingering. > > > > > > > > > > > > -- > > > This message was sent by Atlassian JIRA > > > (v6.3.4#6332) > > > > > > > > > -- > > Sent from Gmail Mobile > > >
