Docs improvement for rolloutOptions

[walles]

Hi!

Have a look here:
https://github.com/spotify/helios/blob/master/docs/user_manual.md#rolloutoptions

I would like to know details about these rolloutOptions fields:

• migrate: what does this do?
• parallelism: number of nodes that will be updated in parallel I assume, pretty certain about this one
• timeout: is this in seconds? Is it per node or for the whole rollout job?
• overlap: what does this do?
• token: where is this token used? why is it "insecure"?
• ignoreFailures: what happens on failures with this on? Is the rollout marked as success in spite of the failures?

[walles]

Found this, should probably be part of the user manual document:

walles@gew1-preprodbuildfarmworker-k-rzvm:~$ helios rolling-update -h
usage: helios rolling-update [-h] [-z MASTER] [-d DOMAINS] [--srv-name SRV_NAME] [-u USERNAME] [--google-credentials GOOGLE_CREDENTIALS] [-v] [--version] [--json] [-k] [--http-timeout HTTP_TIMEOUT]
              [--retry-timeout RETRY_TIMEOUT] [-t TIMEOUT] [-p PARALLELISM] [--async] [-T ROLLOUT_TIMEOUT] [--migrate] [--overlap] [--token [TOKEN]] [--ignore-failures] job deployment-group-name

positional arguments:
  job                    Job id.
  deployment-group-name  Deployment group name

optional arguments:
  -h, --help             show this help message and exit
  -t TIMEOUT, --timeout TIMEOUT
                         Fail rollout if a job takes longer than this to reach RUNNING (seconds)
  -p PARALLELISM, --par PARALLELISM
                         Number of hosts to deploy to concurrently
  --async                Don't block until rolling-update is complete (default: false)
  -T ROLLOUT_TIMEOUT, --rollout-timeout ROLLOUT_TIMEOUT
                         Exit if rolling-update takes longer than the given value (minutes). Note that this will NOT abort the rolling update, it will just cause this command to exit. (default: 60)
  --migrate              When specified a rolling-update will undeploy not only jobs previously deployed by the deployment-group but  also  jobs  with the same job id. Use it ONCE when migrating a service to using
                         deployment-groups
  --overlap              When specified a rolling-update will, for every host, first deploy the new version of a job before  undeploying the old one. Note that the command will fail if the job contains static port
                         assignments.
  --token [TOKEN]        Insecure access token meant to prevent accidental changes to your job (e.g. undeploys).
  --ignore-failures      When specified, the rolling-update will ignore *all* failures and will proceed to deploying  the  job  to  all  hosts in the deployment group. The rolling-update will go through the normal
                         rollout plan (respecting the --par and --overlap settings), and will wait for the job to reach  RUNNING on each host as normal; however, any failure that would otherwise cause the rolling-
                         update to abort and set the deployment group's status to FAILED is *ignored*. Be *VERY*  careful  about  using  this option, as it has the potential to completely take down your service by
                         rolling out a broken job to all of the hosts in your group.