Incremental deploys

[ssalinas]

Still needs plenty of work, but opening up early for feedback.

Right now I am adding a field to the SingularityPendingDeploy object that will track the progress of an incremental deploy as it goes along. This new field is an object that holds information about the current target number of instances and rate at which the deploy should proceed.

Still to-do:

• Better scheduling of upcoming tasks. Right now it's just keying off of numMissingInstances, but since we know the time between deploy steps, we can go ahead and schedule them
• Make it play nice with load balancer add/remove. Regular deploys add everything all at once when the deploy succeeds, this will need to do it per-task
• Surface more information about what is happening in the deploy, if you aren't watching the logs it's kind of mysterious right now
• Option to manually move the deploy forward or backward a step (should be fairly straightforward since we have the info in the SingularityPendingDeploy object)
• Tests, tests, tests, tests, tests....
• UI

/cc @tpetr @wsorenson

[tpetr]

I don't want to overcomplicate things, but I wonder about the merits of an enum vs. being able to define a batch size for the deploy that defaults to the total instance count (i.e. a "normal" deploy)

[ssalinas]

Yeah, that's fair, might keep it simpler in the end, move towards all deploys working the same, but 'regular' deploys are just everything at once

[ssalinas]

The basics are working now. All deploys now use a similar system where progress is tracked in the pending deploy object, incrementing a target number of instances for each step of the deploy. By default the number of instances per deploy step is the total instances (i.e. everything at once like before) unless a deployRate is set that then determines how many instances to deploy in each 'step'. Load balancer actions are triggered at the end of each step.

Some info is surfaced in the ui now on the request page, but the wording/design could probably still be a bit cleaner.

[tpetr]

^ can you remove the newline? can get confusing in a builder block

[ssalinas]

@tpetr was debating making the default wait time 0, would that make more sense? i.e. move on to the next step as soon as the previous is finished 'rolling deploy', by default

[tpetr]

yeah i think that jives with the incremental deploy idea

[ssalinas]

@tpetr @wsorenson finished a bunch of refactoring on this to slim down the methods. Also added more tests for canceled/failed deploy scenarios. Let me know if you see anything else in here that's needs updating

[tpetr]

this is a recent intellij thing that started happening, might not be a setting that the eclipse formatter file sets. i think it'd be good to keep all our @Override's on their own line