{section: usage}
 
-In this prototype, the =condor_annex= tool requires a JSON file describing the kind of instances you'd like.  The easiest way to generate this JSON file is using the AWS web console; when you request a Spot Fleet, on the last page before you submit the request, there's a button in the upper-right labelled "JSON config"; click it to download a file.  Save the file (the default name is =config.json=, which is fine).  FIXME: If you're not familiar with Spot Fleet, the prototype includes a reasonable example =config.json= you can use to get started.  It uses an image maintained by HTCondor (Amazon Linux with HTCondor pre-installed).
+In this prototype, the =condor_annex= tool requires a JSON file describing the kind of instances you'd like.  The easiest way to generate this JSON file is using the AWS web console; when you request a Spot Fleet, on the last page before you submit the request, there's a button in the upper-right labelled "JSON config"; click it to download a file.  Save the file (the default name is =config.json=, which is fine).  FIXME: If you're not familiar with Spot Fleet, the prototype includes a reasonable example configuration (=example.json=) you can use to get started.  It uses an image maintained by HTCondor (Amazon Linux with HTCondor pre-installed).
 
 After you save the config, open it in your favorite text editor and remove the two lines containing "ValidFrom" and "ValidUntil".  (FIXME: If =condor_annex= were to just ignore these entries, would it need to support additional CLI flags to set them?)
 
@@ -66,6 +66,17 @@
 
 {section: advanced usage}
 
-The usage above should suffice for the efficient provisioning of many instance using the images you already are.  If you'd like to use the prototype to start annexes, the procedure is somewhat involved.  The basic idea is as follows: when HTCondor starts up (this may be replaced by "when the OS finishes booting" in future releases), it runs a script which looks at the permissions which have been granted to the instance.  (Obviously, this fails if the instance hasn't been granted permission to look at its own permissions.)  If one of those permisssions is read access to a specific file in a specific S3 bucket, the script downloads the file into the HTCondor =config.d= directory, or, if the file is a tarball, untars it there.  Because this mechanism is entirely independent of the usual userdata-dependent contextualization methods, it can be used to dynamically configure HTCondor regardless of an how an instance otherwise might configure itself.  We expect this ability to generally be used to configure HTCondor to join one specific pool or another.
+The usage above should suffice for the efficient provisioning of many instance of the images you're already using.  If you'd like to use the prototype to start annexes, the procedure is somewhat involved.  The basic idea is as follows: when HTCondor starts up (this may be replaced by "when the OS finishes booting" in future releases), it runs a script which looks at the permissions which have been granted to the instance.  (Obviously, this fails if the instance hasn't been granted permission to look at its own permissions.)  If one of those permisssions is read access to a specific file in a specific S3 bucket, the script downloads the file into the HTCondor =config.d= directory, or, if the file is a tarball, untars it there.  Because this mechanism is entirely independent of the usual userdata-dependent contextualization methods, it can be used to dynamically configure HTCondor regardless of an how an instance otherwise might configure itself.  We expect this ability to generally be used to configure HTCondor to join one specific pool or another.
 
-We have provided a second CloudWatch template to help construct this mechanism.  Actually, because it was easier, we have provided a script which -- given the S3 bucket name and file -- outputs a CloudWatch which creates the corresponding IAM role and instance profile. ....
+We have provided a second CloudWatch template to help construct this mechanism.  Actually, because we hope it's easier than editing the template, we have provided a script which -- given the S3 bucket name and file -- outputs a CloudFormation template which creates the corresponding IAM role and instance profile.  Run =generate-role bucketName fileName > role-1.json= and follow the instructions above (under "Lambda function") to create the corresponding stack (you'll have to name it something else).  The _bucketName_ must be a bucket you can write to, and the _fileName_ should probably be something like =config.tar.gz=.  Note -- you don't need to, nor do you probably want to, give the configuration file read permission in S3; the role provides the necessary authorization.  This keeps _fileName_ private.  For this stack, the output will be called "InstanceConfigurationProfile".
+
+You'll need to create some configuration to upload.  For testing purposes, any valid configuration will do; you just want to be able to check that HTCondor is using the configuration.  (For example, you could create a file name =17custom=, with the following contents:
+
+{verbatim}
+isCustomConfig = TRUE
+STARTD_ATTRS = $(STARTD_ATTRS) isCustomConfig
+{endverbatim}
+
+and then =tar -z -c -f config.tar.gz 17custom= in order to generate the file to upload.)
+
+The example AMIs are already configured to take advantage of profiles like the one you just created, so if you start an instance with the profile you just created, you should be able to SSH into it, and if you followed the example, run =condor_config_val -startd isCustomConfig=, and get back 'TRUE'.  (By querying a specific daemon, you ensure that you're checking the live configuration, not any configuration change that happened on disk after HTCondor startup.)