set-upgrade-mode.asciidoc 3.2 KB

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