set-upgrade-mode.asciidoc 3.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798
  1. [role="xpack"]
  2. [[ml-set-upgrade-mode]]
  3. = Set upgrade mode API
  4. ++++
  5. <titleabbrev>Set upgrade mode</titleabbrev>
  6. ++++
  7. Sets a cluster wide upgrade_mode setting that prepares {ml} indices for an
  8. upgrade.
  9. [[ml-set-upgrade-mode-request]]
  10. == {api-request-title}
  11. //////////////////////////
  12. [source,console]
  13. --------------------------------------------------
  14. POST /_ml/set_upgrade_mode?enabled=false&timeout=10m
  15. --------------------------------------------------
  16. // TEARDOWN
  17. //////////////////////////
  18. `POST _ml/set_upgrade_mode`
  19. [[ml-set-upgrade-mode-prereqs]]
  20. == {api-prereq-title}
  21. Requires the `manage_ml` cluster privilege. This privilege is included in the
  22. `machine_learning_admin` built-in role.
  23. [[ml-set-upgrade-mode-desc]]
  24. == {api-description-title}
  25. When upgrading your cluster, in some circumstances you must restart your nodes and
  26. reindex your {ml} indices. In those circumstances, there must be no {ml} jobs running.
  27. You can close the {ml} jobs, do the upgrade, then open all the jobs again.
  28. Alternatively, you can use this API to temporarily halt tasks associated
  29. with the jobs and {dfeeds} and prevent new jobs from opening. You can also use this
  30. API during upgrades that do not require you to reindex your {ml} indices,
  31. though stopping jobs is not a requirement in that case.
  32. For more information, see {stack-ref}/upgrading-elastic-stack.html[Upgrading the {stack}].
  33. When `enabled=true` this API temporarily halts all job and {dfeed} tasks and
  34. prohibits new job and {dfeed} tasks from starting.
  35. Subsequently, you can call the API with the enabled parameter set to false,
  36. which causes {ml} jobs and {dfeeds} to return to their desired states.
  37. You can see the current value for the `upgrade_mode` setting by using the
  38. <<get-ml-info,get {ml} info API>>.
  39. IMPORTANT: No new {ml} jobs can be opened while the `upgrade_mode` setting is
  40. `true`.
  41. [[ml-set-upgrade-mode-query-parms]]
  42. == {api-query-parms-title}
  43. `enabled`::
  44. (Optional, Boolean) When `true`, this enables `upgrade_mode`. Defaults to
  45. `false`.
  46. `timeout`::
  47. (Optional, time) The time to wait for the request to be completed. The default
  48. value is 30 seconds.
  49. [[ml-set-upgrade-mode-example]]
  50. == {api-examples-title}
  51. The following example enables `upgrade_mode` for the cluster:
  52. [source,console]
  53. --------------------------------------------------
  54. POST _ml/set_upgrade_mode?enabled=true&timeout=10m
  55. --------------------------------------------------
  56. When the call is successful, an acknowledged response is returned. For example:
  57. [source,console-result]
  58. ----
  59. {
  60. "acknowledged": true
  61. }
  62. ----
  63. The acknowledged response will only be returned once all {ml} jobs and {dfeeds} have
  64. finished writing to the {ml} internal indices. This means it is safe to reindex those
  65. internal indices without causing failures. You must wait for the acknowledged
  66. response before reindexing to ensure that all writes are completed.
  67. When the upgrade is complete, you must set `upgrade_mode` to `false` for
  68. {ml} jobs to start running again. For example:
  69. [source,console]
  70. --------------------------------------------------
  71. POST _ml/set_upgrade_mode?enabled=false&timeout=10m
  72. --------------------------------------------------