Update bootstrapping-spinnaker-deployment-services.adoc

bootstrapping-spinnaker-deployment-services.adoc

@@ -25,7 +25,7 @@ Spinnaker's deployment engine, Kato, provides all write-to operations to the clo
 
 === Building Kato
 
-Following a fresh checkout of Kato from source control, the project can be built using the provided Gradle wrapper. Java 7 or higher is required to build the project. There is a known bug with Java 7u65 and Java 8u11 that affect Kato, so as of the time of this writing, Java 7u60 is the recommended JDK version. The project can be built simply by invoking the +build+ task, in the form of `./gradlew build`, which will compile the project and all submodules. The Spring Boot repackaging task, which generates the 'fat jar' is presently disabled, so generating a distribution needs to occur through the +distTar+ or +distZip+ task. The resulting artifact of consequence can be found in the +kato-web/build/distributions+ directory. 
+Following a fresh checkout of Kato from source control, the project can be built using the provided Gradle wrapper. Java 7 or higher is required to build the project. There is a known bug with Java 7u65 and Java 8u11 that affect Kato, so as of the time of this writing, Java 7u72 or higher is the recommended JDK version. The project can be built simply by invoking the +build+ task, in the form of `./gradlew build`, which will compile the project and all submodules. The Spring Boot repackaging task, which generates the 'fat jar' is presently disabled, so generating a distribution needs to occur through the +distTar+ or +distZip+ task. The resulting artifact of consequence can be found in the +kato-web/build/distributions+ directory. 
 
 NOTE: Kato's web module is what ties the submodules together and provides the RESTful API and the project's +Main+ class. 
 
@@ -33,7 +33,7 @@ NOTE: Kato's web module is what ties the submodules together and provides the RE
 
 From a development position, Kato can be started either through invoking the +bootRun+ task on the +kato-web+ module, or through an IDE by creating a Java Application run configuration for the +com.netflix.spinnaker.kato.Main+ class, which resides in the +kato-web+ module. There is no preference to either approach; the choice is the discretion of the developer.
 
-For Kato to run in a deployment, a distribution artifact must be generated, as outlined in the prior section. Once the +kato-web+ tarball or zip file is generated, it can be copied to a server and extracted. From the extracted contents, there exists a +bin+ directory, and within it a +kato-web+ executable script, which can be used to start Kato on the server. To visualize this, consider that the Kato +distTar+ task generated a tarball named +kato-web-1.3.6-SNAPSHOT.tar+. If you copied this to the +/opt+ directory of a server named +kato+ using the command +scp kato-web-1.3.6-SNAPSHOT.tar user@kato:/opt+, then SSH'd to the +kato+ server and cd'd to the +/opt+ directory and executed +tar xvf kato-web-1.3.6-SNAPSHOT.tar+, you'd have a resulting directory +/opt/kato-web-1.3.6-SNAPSHOT+. Within that directory would be a +bin+ subdirectory, and therein the +kato-web+ executable. Executing +./kato-web+ will start Kato from the command line.
+For Kato to run in a deployment, a distribution artifact must be generated, as outlined in the prior section. Once the +kato-web+ tarball or zip file is generated, it can be copied to a server and extracted. From the extracted contents, there exists a +bin+ directory, and within it a +kato+ executable script, which can be used to start Kato on the server. To visualize this, consider that the Kato +distTar+ task generated a tarball named +kato-web-1.3.6-SNAPSHOT.tar+. If you copied this to the +/opt+ directory of a server named +kato+ using the command +scp kato-web-1.3.6-SNAPSHOT.tar user@kato:/opt+, then SSH'd to the +kato+ server and cd'd to the +/opt+ directory and executed +tar xvf kato-web-1.3.6-SNAPSHOT.tar+, you'd have a resulting directory +/opt/kato-web-1.3.6-SNAPSHOT+. Within that directory would be a +bin+ subdirectory, and therein the +kato+ executable. Executing +./kato+ will start Kato from the command line.
 
 NOTE: Once Kato is deployed, its API and manual is accessible through the URI +/manual/index.html+.
 
@@ -41,7 +41,7 @@ NOTE: Once Kato is deployed, its API and manual is accessible through the URI +/
 
 Basic AWS configuration is required to have Kato be able to affect changes for a given account at Amazon, which is covered in detail in the <<CONF>> section of this document.
 
-Kato's additional configuration can be supplied as either Java properties file, YAML configuration file, or as system properties to the JVM. If the former two options are chosen, their location can be made known to Kato by supplying their location as part of the +spring.config.locations+ system property. For example, if you wanted Kato to resolve its configuration from +/etc/kato/system.yml+, you should pass the +-Dspring.config.locations=/etc/kato/system.yml+ system property to the JVM on startup. This can be accomplished by exporting the +JAVA_OPTS+ variable as part of starting the +kato-web+ executable, in the form of: +JAVA_OPTS='-Dspring.config.locations=/etc/kato/system.yml' ./kato-web+. Alternatively, the system property can be placed directly into the +kato-web+ startup script as part of the +JVM_OPTS+ variable at the beginning of the script. The +kato-web+ buildscript (+kato-web.gradle+) could also be modified to include the `applicationDefaultJvmArgs = ["-Dspring.config.locations=/etc/kato/system.yml"]` directive, which would allow the distribution to be packaged automatically with these parameters.
+Kato's additional configuration can be supplied as either Java properties file, YAML configuration file, or as system properties to the JVM. The binary distribtion comes with a +config+ directory containing a +kato.yml+ that is added to the configuration path by default, you can make customizations directly to that file. You can customize the location of the YAML configuration file by setting the system property +spring.config.location+. By default +spring.config.location+ is set to +~/.spinnaker/+ for all Spinnaker services but if you wanted Kato to resolve its configuration from +/etc/kato/system.yml+, you should pass the +-Dspring.config.location=/etc/kato/system.yml+ system property to the JVM on startup. This can be accomplished by exporting the +JAVA_OPTS+ variable as part of starting the +kato+ executable, in the form of: +JAVA_OPTS='-Dspring.config.location=/etc/kato/system.yml' ./kato+. Alternatively, the system property can be placed directly into the +kato+ startup script as part of the +JVM_OPTS+ variable at the beginning of the script. The +kato-web+ buildscript (+kato-web.gradle+) could also be modified to include the `applicationDefaultJvmArgs = ["-Dspring.config.locations=/etc/kato/system.yml"]` directive, which would allow the distribution to be packaged automatically with these parameters.
 
 Default configurations for +iamRole+ and +keyPair+ can be overridden for your specific environment. The +iamRole+ configuration describes what http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html[IAM Role] new launch configurations should be shipped with. The +keyPair+ directive can be configured to default new deployments to a specific http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html[AWS EC2 Key Pair], which is necessary to access your servers via ssh.