upgrade-transforms.asciidoc 2.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
  1. [role="xpack"]
  2. [[upgrade-transforms]]
  3. = Upgrade {transforms} API
  4. [subs="attributes"]
  5. ++++
  6. <titleabbrev>Upgrade {transforms}</titleabbrev>
  7. ++++
  8. Upgrades all {transforms}.
  9. [[upgrade-transforms-request]]
  10. == {api-request-title}
  11. `POST _transform/_upgrade`
  12. [[upgrade-transforms-prereqs]]
  13. == {api-prereq-title}
  14. Requires the following privileges:
  15. * cluster: `manage_transform` (the `transform_admin` built-in role grants this
  16. privilege)
  17. [[upgrade-transforms-desc]]
  18. == {api-description-title}
  19. {transforms-cap} are compatible across minor versions and between supported
  20. major versions. However, over time, the format of {transform} configuration
  21. information may change. This API identifies {transforms} which have a legacy
  22. configuration format and upgrades them to the latest version; including clean up
  23. of the internal data structures that store {transform} state and checkpoints.
  24. {transform-cap} upgrade does not affect the source and destination indices.
  25. If a {transform} upgrade step fails, the upgrade stops, and an error is returned
  26. about the underlying issue. Resolve the issue then re-run the process again. A
  27. summary is returned when the upgrade is finished.
  28. To ensure {ctransforms} remain running during a major version upgrade of the
  29. cluster – for example, from 7.16 to 8.0 – it is recommended to upgrade
  30. {transforms} before upgrading the cluster. You may want to perform a recent
  31. cluster backup prior to the upgrade.
  32. [IMPORTANT]
  33. ====
  34. * When {es} {security-features} are enabled, your {transform} remembers the
  35. roles of the user who created or updated it last. In contrast to
  36. <<update-transform,update transform>>, a {transform} upgrade does not change the
  37. stored roles, therefore the role used to read source data and write to the
  38. destination index remains unchanged.
  39. ====
  40. [[upgrade-transforms-query-parms]]
  41. == {api-query-parms-title}
  42. `dry_run`::
  43. (Optional, Boolean) When `true`, only checks for updates but does not execute
  44. them. Defaults to `false`.
  45. `timeout`::
  46. (Optional, time)
  47. Period to wait for a response. If no response is received before the timeout
  48. expires, the request fails and returns an error. Defaults to `30s`.
  49. [[upgrade-transforms-response-body]]
  50. == {api-response-body-title}
  51. `needs_update`::
  52. (integer) The number of {transforms} that need to be upgraded.
  53. `no_action`::
  54. (integer) The number of {transforms} that don't require upgrading.
  55. `updated`::
  56. (integer) The number of {transforms} that have been upgraded.
  57. [[upgrade-transforms-example]]
  58. == {api-examples-title}
  59. To upgrade the legacy {transforms} to the latest configuration format, perform
  60. the following API call:
  61. [source,console]
  62. --------------------------------------------------
  63. POST _transform/_upgrade
  64. --------------------------------------------------
  65. // TEST[setup:simple_kibana_continuous_pivot]
  66. When all {transforms} are upgraded, you receive a summary:
  67. [source,console-result]
  68. ----
  69. {
  70. "needs_update": 0,
  71. "updated": 2,
  72. "no_action": 1
  73. }
  74. ----
  75. // TESTRESPONSE[skip:TBD]