(In reply to comment #0)
> Description of problem:
> Add to Overview:
> The three components communicate over AMQP, so an AMQP broker needs to be
> accessible by all three components in order for the feature to operate.  The
> AMQP broker does not need to be on a machine that is part of the remote
> configuration system, but all three components must be configured to talk to
> the same broker.
> 
> The configuration store maintains individual configuration entities and any
> configurations applied to nodes it knows about.  The tools configure entities
> in the store and apply those entities to nodes.  The node check in with the
> store and retrieve configuration updates.

<variablelist>
	<varlistentry>
		<term>Configuration store</term>
		<listitem>
			<para>
				The <firstterm>configuration store</firstterm> is a central repository for configuration data. It maintains individual configuration entities and any configurations applied to the nodes it knows about.
			</para>

		</listitem>

	</varlistentry>
	<varlistentry>
		<term>Managed nodes</term>
		<listitem>
			<para>
				The <firstterm>nodes</firstterm> managed by the configuration store. Each node in the store represents a physical machine to be managed. They check in with the store to retrieve configuration updates.
			</para>

		</listitem>

	</varlistentry>
	<varlistentry>
		<term>Tools</term>
		<listitem>
			<para>
				There are a number of tools that can be used to interact with the configuration store. The tools are used to configure entities in the store which are then applied to the nodes.
			</para>

		</listitem>

	</varlistentry>

</variablelist>
<para>
	The three components communicate using AMQP (advanced message queueing protocol). To facilitate this, an AMQP broker needs to be provided in a location that is available to all three components. Without this, remote configuration will not work correctly.
</para>

> 
>  - Need information about how this fits into configuration system
>  4.1. The Configuration Store
>   - Introduces the notion of "subsystem" which should exist in the general
> overview chapter, and is useful elsewhere

Added to BZ #633589

>   - "a another"

Fixed.

>   - "so it is be inspected"

Fixed.

>  4.2. Nodes
>   - Add a section detailing how the condor-wallaby-client works:
>     The condor-wallaby-client will install a configuration file in MRG Grid's
> local configuration directory that will enable it to control the configuration
> for the node.  The condor-wallaby-client package contains a daemon that will
> check in with the store and listen for configuration change notifications.  The
> daemon will write the configuration it receives from the configuration store
> into the local configuration file as defined by the configuration file
> installed by the condor-wallaby-client package.

<section id="sect-Grid_User_Guide-Remote_configuration-Nodes">
	<title>Nodes</title>
	<para>
		The <command>condor-wallaby-client</command> is installed on each node and is used to manage configurations for that node. It installs a configuration file in the &GRID; local configuration directory, which enables it to control configuration for the node. The <command>condor-wallaby-client</command> package contains a service that will check in with the store and listen for configuration change notifications. When it receives a new configuration from the store, the service will write it into the local configuration file for the node. The location of the local configuration file is defined in the configuration file installed by the <command>condor-wallaby-client</command> package.
	</para>

> 
>  4.2. Tools
>   - Needs updating to use wallaby shell syntax

Added to BZ #633589

>  4.4. Remote configuration example
>   - AccessNode sets ALLOW_WRITE = *, which we previously recommend against. 
> Set *.example.com (or something similar)

Do we need to specify anything at all there? Removed this sentence:

"In this example, they are both set to <parameter>*</parameter>."

LKB