anchor.diff:  non-ignored profile uses the extension. Ignoring an extension requires
   explicit configuration. Perhaps in a future release extensions will be
   explicitly ignored.
  -* If a change is made to the slave host's configuration or to the domain
  +* If a change is made to the secondary Host Controller host's configuration or to the domain
   wide configuration that reduces the set of ignored resources, then as
  -part of handling that change the slave will contact the master to pull
  +part of handling that change the secondary Host Controller will contact the Domain Controller to pull
   down the missing pieces of configuration and will integrate those pieces
   in its local copy of the management model. Examples of such changes
   include adding a new server-config that references a previously ignored
  
positive.code: 
  Starting with WildFly 10, this kind of detailed configuration is no
  longer required. Instead, with the standard versions of `host.xml`, the
  slave will behave as follows:
  
  * If the slave was started with the `--backup` command line parameter,
  the behavior will be the same as releases prior to 10; i.e. only
  resources specifically configured to be ignored will be ignored.
  * Otherwise, the slave will "ignore unused resources".
  
  What does "ignoring unused resources" mean?
  
  
negative.code: with `/host=*`, i.e. those that are persisted in `domain.xml`. Having
  that local copy allows a user to do the following things:
  
  * Ask the secondary Host Controller to launch its already configured servers, even if the
  Domain Controller is not running.
  * Configured new servers, using different server groups from those
  current running, and ask the secondary Host Controller to launch them, even if the Domain
  Controller is not running.
  * Reconfigure the secondary Host Controller to act as the Domain Controller, allowing it to
  take over as the Domain Controller if the previous Domain Controller has failed or been shut
  down.
  
  However, of these three things only the latter two require that the
  secondary Host Controller maintain a _complete_ copy of the domain wide configuration. The
  first only requires the secondary Host Controller to have the _portion_ of the domain wide
  configuration that is relevant to its current servers. And the first use
  case is the most common one. A secondary Host Controller that is only meant to support the
  first use case can safely "ignore" portions of the domain wide
  configuration. And there are benefits to ignoring some resources:
  
  * If a server group is ignored, and the deployments mapped to that
  server group aren't mapped to other non-ignored groups, then the secondary Host Controller
  does not need to pull down a copy of the deployment content from the
  Domain Controller. That can save disk space on the secondary Host Controller, improve the speed of
  starting new hosts and reduce network traffic.
  * WildFly supports "mixed domains" where a later version Domain
  Controller can manage secondary Host Controllers running previous versions. But those
  "legacy" secondary Host Controllers cannot understand configuration resources, attributes
  and operations introduced in newer versions. So any attempt to use newer
  things in the domain wide configuration will fail unless the legacy
  secondary Host Controllers are ignoring the relevant resources. But ignoring resources will
  allow the legacy secondary Host Controllers to work fine managing servers using profiles
  without new concepts, while other hosts can run servers with profiles
  that take advantage of the latest features.
  
  Prior to WildFly 10, a secondary Host Controller could be configured to ignore some
  resources, but the mechanism was not particularly user friendly:
  
  * The resources to be ignored had to be listed in a fair amount of
  