rename with _ so that pages build
Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/e16046c3 Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/e16046c3 Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/e16046c3 Branch: refs/heads/master Commit: e16046c30789732a2e5b14041719d8ee3c661fc9 Parents: f88394f Author: Alex Heneveld <[email protected]> Authored: Thu Nov 2 11:23:19 2017 +0000 Committer: Alex Heneveld <[email protected]> Committed: Thu Nov 2 11:23:19 2017 +0000 ---------------------------------------------------------------------- guide/ops/upgrades/_systems-under-mgmt.md | 24 ++++++++++++++++++++++++ guide/ops/upgrades/systems-under-mgmt.md | 24 ------------------------ 2 files changed, 24 insertions(+), 24 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/e16046c3/guide/ops/upgrades/_systems-under-mgmt.md ---------------------------------------------------------------------- diff --git a/guide/ops/upgrades/_systems-under-mgmt.md b/guide/ops/upgrades/_systems-under-mgmt.md new file mode 100644 index 0000000..5a63af5 --- /dev/null +++ b/guide/ops/upgrades/_systems-under-mgmt.md @@ -0,0 +1,24 @@ + +## Upgrading Systems Under Management + +Blueprints can encode update processes for the systems they describe. +The mechanisms for updating systems vary, depending whether it is stateless or stateful, +whether following an immutable pattern (replacing components) +or doing it on box (traditional, possibly taking systems out of action while upgrading), +and whether applying an upgrade to many resources on a rolling fashion (repaving, blue-green). +For this reason there is not a one-size-fits-all upgrade pattern to use in blueprints, +but there are some common patterns that may be applicable: + +* Defining an `upgrade` effector on nodes, and on a cluster to apply to all nodes +* Using a config key such as `version` which can be updated and reapplied +* Exposing a `deploy` effector to pass files that should be run, such as WAR files, + and invoking this effector with newer versions of WAR files to install + +There are many more, and if you've written some good pieces to share, +please consider contributing them so others can take advantage of them! + + + + + + http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/e16046c3/guide/ops/upgrades/systems-under-mgmt.md ---------------------------------------------------------------------- diff --git a/guide/ops/upgrades/systems-under-mgmt.md b/guide/ops/upgrades/systems-under-mgmt.md deleted file mode 100644 index 5a63af5..0000000 --- a/guide/ops/upgrades/systems-under-mgmt.md +++ /dev/null @@ -1,24 +0,0 @@ - -## Upgrading Systems Under Management - -Blueprints can encode update processes for the systems they describe. -The mechanisms for updating systems vary, depending whether it is stateless or stateful, -whether following an immutable pattern (replacing components) -or doing it on box (traditional, possibly taking systems out of action while upgrading), -and whether applying an upgrade to many resources on a rolling fashion (repaving, blue-green). -For this reason there is not a one-size-fits-all upgrade pattern to use in blueprints, -but there are some common patterns that may be applicable: - -* Defining an `upgrade` effector on nodes, and on a cluster to apply to all nodes -* Using a config key such as `version` which can be updated and reapplied -* Exposing a `deploy` effector to pass files that should be run, such as WAR files, - and invoking this effector with newer versions of WAR files to install - -There are many more, and if you've written some good pieces to share, -please consider contributing them so others can take advantage of them! - - - - - -
