Bug 619588

In 4.2 Nodes, change:

Open the condor local configuration file condor_config.local and add the following parameter with the name of the broker

To something like:

Create a file in /etc/condor/config.d called 40QMF

(In reply to comment #0)
> Description of problem:
> The chapter should be renamed as the feature is not really a "tool" any more
> but an entire system/infrastructure.  Something like "Remove Configuration
> System", "Remote Configuration Infrastructure', or just "Remote Configuration". 

<title>Remote configuration</title>

> 
> "The remote configuration tool has three components: " -> The remove
> configuration feature has three components (?) (Again, moving away from calling
> it a "tool" since it is comprised of many parts, one of which is a set of
> tools)

<para>
	The remote configuration feature has three components:
</para>

> 
> "If no value is given, then this value will be used when the parameter is
> applied to a feature or node" -> If no value is given when the parameter is
> applied to a node, group, or feature, then this value may be given. (It's not
> definitive because the user has the option to not use the default value and
> instead give the parameter an empty value)

<term><parameter>default</parameter></term>
	 <listitem>
		<para>
			The default value of the parameter. If no value is specified when the parameter is applied to a feature or node, this value can be used.
		</para>

	</listitem>

> 
> "Values can be explicitly set, or left empty. If left empty, the value will be
> obtained from elsewhere in the configuration. " -> Values can be explicitly set
> or a parameter's default (obtained from the metadata on the parameter) can be
> used.

<term><parameter>params</parameter></term>
	<listitem>
		<para>
			Maps parameter names to the values that the feature contains. Values can be explicitly set, or left empty. If left empty, a default value will be obtained from the metadata of the parameter.
		</para>

	</listitem>

> 
> "Values for explicity-set parameters will take priority over values ..." ->
> Values for explicitly-set parameters on the group will take priority over
> values ..."
> 

<para>
	A <firstterm>group</firstterm> is a group of nodes that will have parameters and features applied to it. Values for explicity-set group parameters will take priority over values for feature parameters. The configuration store has a built-in group: the <filename>Internal Default Group</filename>, which will always exist and be applied to all nodes within the store at the lowest priority.
</para>

> "... the remote configuration tool will ask if the parameter should use a value
> defined elsewhere in the configuration ..." -> condor_configure_store will ask
> if the parameter should use the default value
> 
> "... or if the value should be allowed to be obtained from other configurations
> on the node, feature, or group ..." -> or if the value should be obtained from
> the default value defined in the parameter's metadata.
> 
> "This includes using the default value of the parameter as defined in the
> parameter's metadata" -> Remove

<para>
	If an empty value is given for a parameter when it is added to a feature, <command>condor_configure_store</command> will ask if the parameter should use the default value. The <command>condor_configure_store</command> tool needs to know if the parameter is intended to have a blank value, or if the value should be allowed to be obtained from the default value defined in the metadata of the parameter.
</para>

> 
> The paragraph starting "If an empty value is given for a parameter when it is
> added ..." needs to be moved.  It is currently in no-mans land and doesn't
> connect to anything.  It should be moved to where condor_configure_store is
> discussed, as that is the tool that does the prompting.

Done.

> 
> "...if the configuration is valid." -> ... for the configuration to be valid.

<term>Conflict</term>
	<listitem>
		<para>
			A conflict can not exist anywhere in the configuration for the configuration to be valid.
		</para>

> 
> " Install the following package with the yum command" -> Grid machines that are
> to be managed with Remote Configuration must be installed with the following
> packages (or something to that effect)

<para>
	To allow a machine to be managed with remote configuration, install the following package with the <command>yum</command> command:
</para>

> 
> "The remote configuration client needs to be told that the broker is
> communicating with the configuration store" -> The remote configuration client
> need to be told the location of the broker that is communicating with the
> configuration store.
> 
> "... with the name of the broker" -> ... with the ip address or hostname of the
> machine running the broker

<para>
	The remote configuration client needs to be told the location of the broker that is communicating with the configuration store. Open the condor local configuration file <filename>condor_config.local</filename> and add the following parameter with the IP address or hostname of the machine running the broker:
</para>

> 
> "the tool will being to make " -> the tool will begin to make
> 
> "willnotify" -> will notify

I have fixed both these typos, but these sections are unedited and require proper instructions.

> 
> "The tool will automatically create a named snapshot when a configuration is
> successfully activated in this way." -> The tool will automatically create a
> named snapshot when a configuration is successfully activated in this way if a
> snapshot was not created previously.

This is in an unedited section. I have not made any changes

> 
> YAML Map: VERY IMPORTANT to indent the key-value pairs in the map otherwise the
> input isn't valid.  Must mention this, and change the example to:
> 
> a_map:
>   value1: This is a string
>   value2: '4'

<programlisting>
a_map:
	value1: This is a string
	value2: &#39;4&#39;
</programlisting>

LKB

> 3.3 Tools - Should mention condor_configure_pool and condor_configure_store
> here as well.  Honestly, I like the mentioning of the tools at their current
> locations (ccs when discussing the store, ccp when discussing nodes), but it
> also kind of muddies the waters in the distribution of functionality.  Suggest
> maybe mentioning the tools in the store/node sections and moving the paragraphs
> about the tool specifics to the Tools section.

The individual processes around ccp and ccs are unedited, and require proper process information. I have added the following entries to the tools section:

<varlistentry>
	<term><command>condor_configure_store</command></term>
	<listitem>
		<para>
			The <command>condor_configure_store</command> tool is used to configure parameters, features, groups, subsystems, and nodes in the store. Only one action can be performed at a time with this tool.
		</para>

	</listitem>

</varlistentry>
<varlistentry>
	<term><command>condor_configure_pool</command></term>
	<listitem>
		<para>
			The <command>condor_configure_pool</command> tool is used to apply configurations to a specific node or group of nodes. It uses the parameters, features, groups, and nodes stored in the configuration store by the <command>condor_configure_store</command> tool. Only one node or group can be acted upon at a time, but multiple features and parameters can by be added at once.
		</para>

	</listitem>

</varlistentry>

LKB

> > 
> > "the tool will being to make " -> the tool will begin to make
> > 
> > "willnotify" -> will notify
> 
> I have fixed both these typos, but these sections are unedited and require
> proper instructions.
> 
> > 
> > "The tool will automatically create a named snapshot when a configuration is
> > successfully activated in this way." -> The tool will automatically create a
> > named snapshot when a configuration is successfully activated in this way if a
> > snapshot was not created previously.
> 
> This is in an unedited section. I have not made any changes

This is a clarification from the source material.  Automatic snapshots are only performed if the activation is successful and the user chose not to create a named snapshot.

"Editing metadata " section needs to move to where condor_configure_store is discussed as that is the tool that uses it.

Rob - waiting on the updated info for these processes, as per our phone call last week.

LKB

Processes documented in 618885

Thanks.

LKB