Remove overstate documentation

doc/glossary.rst

@@ -130,10 +130,6 @@ Glossary
         A formatter for defining the characteristics of output data from a Salt
         command. *See also*: :ref:`list of outputters <all-salt.output>`.
 
-    Overstate
-        A system by which a Master can issue function calls to minions in a
-        deterministic order. *See also*: :ref:`overstate <states-overstate>`.
-
     Peer Communication
         The ability for minions to communicate directly with other minions
         instead of brokering commands through the Salt master. *See also*:

doc/topics/development/conventions/formulas.rst

@@ -252,7 +252,7 @@ Use ``module.function`` notation
 
 So-called "short-declaration" notation is preferred for referencing state
 modules and state functions. It provides a consistent pattern of
-``module.function`` shared between Salt States, the Reactor, Overstate, Salt
+``module.function`` shared between Salt States, the Reactor, Salt
 Mine, the Scheduler, as well as with the CLI.
 
 .. code-block:: yaml
@@ -880,7 +880,7 @@ When to use lookup tables
 The ``map.jinja`` file is only a convention within Salt Formulas. This greater
 pattern is useful for a wide variety of data in a wide variety of workflows.
 This pattern is not limited to pulling data from a single file or data source.
-This pattern is useful in States, Pillar, the Reactor, and Overstate as well.
+This pattern is useful in States, Pillar and the Reactor, for example.
 
 Working with a data structure instead of, say, a config file allows the data to
 be cobbled together from multiple sources (local files, remote Pillar, database

doc/topics/development/modular_systems.rst

@@ -155,8 +155,7 @@ external job cache. Use the ``redis`` returner as an example.
 Runners
 =======
 
-Runners are purely master-side execution sequences. These range from simple
-reporting to orchestration engines like the overstate.
+Runners are purely master-side execution sequences.
 
 Tops
 ====
@@ -168,4 +167,4 @@ Wheel
 =====
 
 The wheel system is used to manage master side management routines. These
-routines are primarily intended for the API to enable master configuration.
+routines are primarily intended for the API to enable master configuration.

doc/topics/jobs/schedule.rst

@@ -184,13 +184,13 @@ configuration file:
 .. code-block:: yaml
 
     schedule:
-      overstate:
-        function: state.over
+      orchestrate:
+        function: state.orchestrate
         seconds: 35
         minutes: 30
         hours: 3
 
-The above configuration will execute the state.over runner every 3 hours,
+The above configuration will execute the state.orchestrate runner every 3 hours,
 30 minutes and 35 seconds, or every 12,635 seconds.
 
 Scheduler With Returner

doc/topics/reactor/index.rst

@@ -88,13 +88,13 @@ can be called:
 
 .. code-block:: yaml
 
-    {% if data['data']['overstate'] == 'refresh' %}
-    overstate_run:
-      runner.state.over
+    {% if data['data']['orchestrate'] == 'refresh' %}
+    orchestrate_run:
+      runner.state.orchestrate
     {% endif %}
 
-This example will execute the state.overstate runner and initiate an overstate
-execution.
+This example will execute the state.orchestrate runner and initiate an
+orchestrate execution.
 
 Fire an event
 =============
@@ -103,10 +103,10 @@ To fire an event from a minion call ``event.send``
 
 .. code-block:: bash
 
-    salt-call event.send 'foo' '{overstate: refresh}'
+    salt-call event.send 'foo' '{orchestrate: refresh}'
 
 After this is called, any reactor sls files matching event tag ``foo`` will
-execute with ``{{ data['data']['overstate'] }}`` equal to ``'refresh'``.
+execute with ``{{ data['data']['orchestrate'] }}`` equal to ``'refresh'``.
 
 See :py:mod:`salt.modules.event` for more information.
 

doc/topics/tutorials/states_pt5.rst

@@ -13,8 +13,7 @@ Orchestration is accomplished in salt primarily through the :ref:`Orchestrate
 Runner <orchestrate-runner>`. Added in version 0.17.0, this Salt :doc:`Runner
 </ref/runners/index>` can use the full suite of :doc:`requisites
 </ref/states/requisites>` available in states, and can also execute
-states/functions using salt-ssh. This runner replaces the :ref:`OverState
-<states-overstate>`.
+states/functions using salt-ssh.
 
 
 .. _orchestrate-runner:
@@ -24,24 +23,13 @@ The Orchestrate Runner
 
 .. versionadded:: 0.17.0
 
-As noted above in the introduction, the Orchestrate Runner (originally called
-the state.sls runner) offers all the functionality of the OverState, but with a
-couple advantages:
-
 * All :doc:`requisites </ref/states/requisites>` available in states can be
   used.
 * The states/functions can be executed using salt-ssh.
 
-The Orchestrate Runner was added with the intent to eventually deprecate the
-OverState system, however the OverState will still be maintained for the
-foreseeable future.
-
 Configuration Syntax
 ~~~~~~~~~~~~~~~~~~~~
 
-The configuration differs slightly from that of the OverState, and more closely
-resembles the configuration schema used for states.
-
 To execute a state, use :mod:`salt.state <salt.states.saltmod.state>`:
 
 .. code-block:: yaml
@@ -66,10 +54,6 @@ To execute a function, use :mod:`salt.function <salt.states.saltmod.function>`:
 Triggering a Highstate
 ~~~~~~~~~~~~~~~~~~~~~~
 
-Whereas with the OverState, a Highstate is run by simply omitting an ``sls`` or
-``function`` argument, with the Orchestrate Runner the Highstate must
-explicitly be requested by using ``highstate: True``:
-
 .. code-block:: yaml
 
     webserver_setup:
@@ -148,132 +132,6 @@ Given the above setup, the orchestration will be carried out as follows:
    a grain called ``role`` with a value of ``storage``.
 
 
-
-
-
-.. _states-overstate:
-
-The OverState System
---------------------
-
-.. warning::
-
-    The OverState runner is deprecated, and will be removed in the feature
-    release of Salt codenamed Boron. (Three feature releases after 2014.7.0,
-    which is codenamed Helium)
-
-Often, servers need to be set up and configured in a specific order, and systems
-should only be set up if systems earlier in the sequence have been set up
-without any issues.
-
-The OverState system can be used to orchestrate deployment in a smooth and
-reliable way across multiple systems in small to large environments.
-
-The OverState SLS
-~~~~~~~~~~~~~~~~~
-
-The OverState system is managed by an SLS file named ``overstate.sls``, located
-in the root of a Salt fileserver environment.
-
-The overstate.sls configures an unordered list of stages, each stage defines
-the minions on which to execute the state, and can define what sls files to
-run, execute a :mod:`state.highstate <salt.modules.state.highstate>`, or
-execute a function. Here's a sample ``overstate.sls``:
-
-.. code-block:: yaml
-
-    mysql:
-      match: 'db*'
-      sls:
-        - mysql.server
-        - drbd
-    webservers:
-      match: 'web*'
-      require:
-        - mysql
-    all:
-      match: '*'
-      require:
-        - mysql
-        - webservers
-
-.. note::
-   The ``match`` argument uses :ref:`compound matching <targeting-compound>`
-
-Given the above setup, the OverState will be carried out as follows:
-
-1. The ``mysql`` stage will be executed first because it is required by the
-   ``webservers`` and ``all`` stages.  It will execute :mod:`state.sls
-   <salt.modules.state.sls>` once for each of the two listed SLS targets
-   (``mysql.server`` and ``drbd``).  These states will be executed on all
-   minions whose minion ID starts with "db".
-
-2. The ``webservers`` stage will then be executed, but only if the ``mysql``
-   stage executes without any failures. The ``webservers`` stage will execute a
-   :mod:`state.highstate <salt.modules.state.highstate>` on all minions whose
-   minion IDs start with "web".
-
-3. Finally, the ``all`` stage will execute, running :mod:`state.highstate
-   <salt.modules.state.highstate>` on all systems, if, and only if the ``mysql``
-   and ``webservers`` stages completed without any failures.
-
-Any failure in the above steps would cause the requires to fail, preventing the
-dependent stages from executing.
-
-
-Using Functions with OverState
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In the above example, you'll notice that the stages lacking an ``sls`` entry
-run a :mod:`state.highstate <salt.modules.state.highstate>`. As mentioned
-earlier, it is also possible to execute other functions in a stage. This
-functionality was added in version 0.15.0.
-
-Running a function is easy:
-
-.. code-block:: yaml
-
-    http:
-      function:
-        pkg.install:
-          - httpd
-
-
-The list of function arguments are defined after the declared function. So, the
-above stage would run ``pkg.install http``. Requisites only function properly
-if the given function supports returning a custom return code.
-
-Executing an OverState
-~~~~~~~~~~~~~~~~~~~~~~
-
-Since the OverState is a :doc:`Runner </ref/runners/index>`, it is executed
-using the ``salt-run`` command. The runner function for the OverState is
-``state.over``.
-
-.. code-block:: bash
-
-    salt-run state.over
-
-The function will by default look in the root of the ``base`` environment (as
-defined in :conf_master:`file_roots`) for a file called ``overstate.sls``, and
-then execute the stages defined within that file.
-
-Different environments and paths can be used as well, by adding them as
-positional arguments:
-
-.. code-block:: bash
-
-    salt-run state.over dev /root/other-overstate.sls
-
-The above would run an OverState using the ``dev`` fileserver environment, with
-the stages defined in ``/root/other-overstate.sls``.
-
-.. warning::
-
-    Since these are positional arguments, when defining the path to the
-    overstate file the environment must also be specified, even if it is the
-    ``base`` environment.
-
 .. note::
 
     Remember, salt-run is always executed on the master.