You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@slider.apache.org by st...@apache.org on 2016/01/04 23:55:22 UTC

svn commit: r1722976 - in /incubator/slider/site/trunk/content: developing/releasing.md docs/client-configuration.md docs/configuration/core.md docs/security.md docs/slider_specs/specifying_exports.md

Author: stevel
Date: Mon Jan  4 22:55:22 2016
New Revision: 1722976

URL: http://svn.apache.org/viewvc?rev=1722976&view=rev
Log:
SLIDER-1014 full rework of releasing.md to match release.xml process

Modified:
    incubator/slider/site/trunk/content/developing/releasing.md
    incubator/slider/site/trunk/content/docs/client-configuration.md
    incubator/slider/site/trunk/content/docs/configuration/core.md
    incubator/slider/site/trunk/content/docs/security.md
    incubator/slider/site/trunk/content/docs/slider_specs/specifying_exports.md

Modified: incubator/slider/site/trunk/content/developing/releasing.md
URL: http://svn.apache.org/viewvc/incubator/slider/site/trunk/content/developing/releasing.md?rev=1722976&r1=1722975&r2=1722976&view=diff
==============================================================================
--- incubator/slider/site/trunk/content/developing/releasing.md (original)
+++ incubator/slider/site/trunk/content/developing/releasing.md Mon Jan  4 22:55:22 2016
@@ -15,27 +15,88 @@
    limitations under the License.
 -->
 
-
 # Apache Slider Release Process
 
-Here is our release process from Slider 0.61-incubating onwards (January 2015)
+This is the current release process. It uses the Apache Ant build file
+`bin/release.xml`, and attempts to automate nearly all the process, including
 
+1. Building the source and JAR packaging.
+1. Validating the source packaging.
+1. Uploading the JAR artifacts to a Nexus staging repository
+1. Copying the RC source artifacts to a local subversion repository -then committing
+1. Generating template voting, result and announcement messages.
+1. Downloading the RC artifacts from the apache distribution repository.
+
+It also adds some extra checks to verify past problems have not re-occurred.
+In particular, the release process will fail if the source tree has any uncommitted
+files, or if the commit checksum of the `HEAD` commit is not found on github.
+
+The core release process, then, is one of preparing the source tree
+and a configuration properties file to manage the release, issuing an
+`ant release` command, then, after its completion, following a sequence
+of operations, some manual.
+
+## Release Workflow
+
+1. Prepare the build
+1. Build and publish a Release Candidate (RC)
+1. Get RC voted in as a release in the slider-dev list
+   If the vote fails: fix the issues then repeat
+1. Report the successful vote to the incubator list and ask for a vote there.
+
+This workflow is designed to be as automated as possible. In order to do
+so, all aspects of the automation which require configuration must be configured
+by a set of ant properties. These should all be defined in the file
+`../release.properties` —that is, a file one directory above the SCM managed source
+tree(s). Placing the file there guarantees that it will not be unintentionally
+included in the release, and allows it to be shared across local copies of
+the source tree, specifically any live local repository in which you have been
+developing, and a read-only release repository.
+
+When this documentation says "set the release property X to Y", it means
+"add an entry `X=Y` to the file `../release.properties`
+
+
+## Preparing the build
+
+Preparing the build means getting the tools ready, checking out the relevant
+repositories, making sure the tests are working, and other actions
+which can be done before even starting the core release process.
 
+ 
 ### Tooling
 
 As well as everything needed to build slider, there are some extra requirements
 for releasing:
 
 1. Shell: `bash`
-1. [git flow](http://danielkummer.github.io/git-flow-cheatsheet/)
+1. Ant 1.8+. The release process is too sophisticated for Maven. 
 1. OS/X and windows: [Atlassian SourceTree](http://www.sourcetreeapp.com/).
 This can perform the git flow operations, as well as show the state of your
 git graph.
 
- 
-### Before you begin
+### Create/Start a JIRA issue for the release
+
+Create a JIRA for the release, estimate 12h
+
+This seems pessimistic, but there may be surprises. Sometimes it has taken
+days. 
+
+### Choose your versions
 
-Read the [ASF incubator release manual](http://incubator.apache.org/guides/releasemanagement.html)
+Choose the version number for the release and its successor for the development branch.
+The development branch must have a `-SNAPSHOT` suffix and be greater than
+the release; the release must not have a `-SNAPSHOT` suffix.
+
+Example:
+
+```
+release: 0.61.0-incubating
+development: 0.62.0-incubating-SNAPSHOT
+
+```
+
+### Make sure the tests are working
 
 Make sure that you are building with the JDK of the minimum supported version
 for Slider. Code compiled with later major versions of Java don't work
@@ -61,6 +122,10 @@ create HBase and Accumulo clusters in th
 *Make sure that the integration tests are passing (and not being skipped) before
 starting to make a release*
 
+```
+mvn clean test integration-test -Dslider.conf.dir=${your-config-dir} 
+```
+
 A good test matrix is:
 
 * Insecure, Secure
@@ -69,65 +134,11 @@ A good test matrix is:
 
 A pair of VMs are sufficient to cover this.
 
-Make sure there are no uncommitted files in your local repo. 
-
-If you are not building against a stable Hadoop release
-
-  1. Check out the Hadoop branch you intend to build and test against —and include in
-     the redistributable artifacts.
-  1. Build it via `mvn clean install -DskipTests`
-  1. Note the git revision number of this build —for documentation.
-  1. Maybe: tag that revision so you can easily revert to it
-
-Unstable Hadoop versions MUST NOT be used for anything declared as a stable
-Slider release.
-
-
-*5.* Check ASF headers dependencies
-
-Ensure the rat check is clean. This rejects files which lack ASF headers
-
-```
-mvn clean
-mvn apache-rat:check -Prat
-```
-
-(if you've got packages that aren't linked off the main POM, they don't get cleaned up; you'll need to `rm` those directories.
-If you are using `fish`, then `rm -rf  */target` should do it.)
-
-### Checking licenses
-
-Maven can check that all dependent artifacts have valid licenses
-
-For modules which publish JARs (`slider-core` and `slider-funtest`),
-run the third party check for JARs. If you run this at the top level project
-it will do it for the relevant sub projects.
-
-Do this after building everything
-
-```
-# in slider toplevel dir
-mvn license:add-third-party -Dlicense.useMissingFile
-```
-
-This will generate license files under each module in
-`target/generated-sources/license/THIRD-PARTY.txt`. Inspect it and make sure
-there are no GPL or LGPL dependencies which do not also have a license option
-which is permitted by the ASF.
-
-You also need to verify that the slider-assembly and slider-agent modules are compliant
-
-```
-# in slider-assembly and slider-agent
-mvn license:aggregate-add-third-party  -Dlicense.useMissingFile
-```
-
-This generates the metadata for licenses. Dependencies without a license are warned about.
-To fix this, make sure that the (generated or updated) file `src/license/THIRD-PARTY.properties`
-has an entry for every dependency without a license, declaring what their license is.
+It is wise to restart all YARN services in the VMs before running the tests,
+for better independence of test runs.
 
 
-### Signing keys
+### Prepare Signing keys
 
 Verify your GPG key is provided to Apache. 
 
@@ -145,739 +156,533 @@ A new key will not be trusted by anyone
 Apache web of trust by getting other developers to sign it. This can be done
 in person, or perhaps over a video conference in which key details can be confirmed.
 
-##### Note: Selecting Hadoop versions
-
-The slider POMs offer different profiles of Hadoop versions to build against. The instructions 
-below use the default. If a profile is needed, append it to all the maven commands.
-
-e.g. `mvn clean install -Prelease-2.7`
-
-
-##  Prepare
-
-
-### Check everything in
-
-This and other other commands assume that `origin` maps
-to `https://git-wip-us.apache.org/repos/asf/incubator-slider.git`;
-you can check this with `git remote -v`
-
-
-* Verify that there's nothing not yet checked in
-
-```
-git status
-```
-
-Everything must be checked in at this point.
-
-*  Sync up with the ASF repo. You do not want to release the wrong code.
-
-```
-git checkout develop
-git pull origin
-git push origin
-```
+### Setup Maven Publishing settings
+ 
+You need to provide credentials to the ASF maven repositories for publishing/releasing
+artifacts, using your ASF username and password.
 
-### Start the JIRA
+The ASF docs say use the maven encryption feature. 
+Our policy is: encrypt your HDD in its entirety —you should be doing that
+anyway.
 
-Create a JIRA for the release, estimate 12h
+In `~/.m2/settings.xml`:
 
 ```
-export SLIDER_RELEASE_JIRA=SLIDER-544
+<settings>
+    ...
+    <servers>
+        <!-- To publish a snapshot-->
+        <server>
+            <id>apache.snapshots.https</id>
+        <username>YOUR_ASF_USERNAME</username>
+        <password>YOUR_SECRET_PASSWORD</password>
+      <server>
+        <id>apache.snapshots.https</id>
+        <username>YOUR_ASF_USERNAME</username>
+        <password>YOUR_SECRET_PASSWORD</password>
+      </server>
+      <!-- To stage a release -->
+      <server>
+        <id>apache.staging.https</id>
+        <username>YOUR_ASF_USERNAME</username>
+        <password>YOUR_SECRET_PASSWORD</password>
+      </server>
+      <!-- To finalise the release-->
+      <server>
+        <id>apache.releases.https</id>
+        <username>YOUR_ASF_USERNAME</username>
+        <password>YOUR_SECRET_PASSWORD</password>
+      </server>
+    </servers>
+        ...
+    </settings>
 ```
 
-This seems pessimistic, but there may be surprises.
-
-  
-### Choose your versions
-
-Choose the version number for the release and its successor for the development branch
-
-Example:
-
-```
-0.61.0-incubating
-0.62.0-incubating-SNAPSHOT
+### Create the `../release.properties` file
 
+Create a file `../release.properties` -that is, one directory 
+above the source tree you are using. This file will be shared
+across two cloned copies of the apache git repository.
 
-export SLIDER_RELEASE=0.61.0-incubating
-export SLIDER_DEV=0.62.0-incubating-SNAPSHOT
-```
 
-### Test that everything works
+### Check out the Apache SVN-based distribution project
 
-Do a final test run to make sure nothing is broken
+RCs are copied to the SVN distribution repository and published for distribution.
+Once an RC is voted in, it can be renamed.
 
-In the `slider` directory, run:
+To begin, you need to check out the SVN repository somewhere
 
 ```
-mvn clean install -DskipTests
+https://dist.apache.org/repos/dist/release/incubator/slider
 ```
 
-(Make sure the build isn't trying to pull down its JARs from the Apache Staging
-repo)
-
-Once everything is built- including `.tar` files, run the tests
+Set the release property `svn.publish.dir` to this value
 
 ```
-mvn test
+svn.publish.dir=/Users/stevel/Java/Apache/slider-dist
 ```
 
-Then the integration tests
+### Make sure your PGP signature is in `slider-dist/KEYS`
 
-```
-mvn integration-test -Dslider.conf.dir=${your-config-dir} 
-```
+Look for your public key in the `KEYS` file in the `slider-dist` directory.
+If it is not there, append it it to the file
 
-This will run the functional tests as well as the `slider-core` tests.
+### Make sure there are no open staging repositories
 
-It is wise to reset any VMs here, and on live clusters kill all running jobs.
-This stops functional tests failing because the job doesn't get started before
-the tests time out.
+This causes Nexus-related confusion., one in which
+it's not obvious where newly-staged artifacts have been published.
 
-As the test run takes 60+ minutes, now is a good time to consider
-finalizing the release notes.
+Log in to: 
+[https://repository.apache.org/index.html#stagingRepositories](https://repository.apache.org/index.html#stagingRepositories)
+and close+drop all staging slider repositories.
 
+Wait until there are none shown in the UI before proceeding.
 
 
-### Create a release branch  
+### Configure the build in `../release.properties`
 
-Create or check out a release branch,
-
-Example of creation then push to the origin
+Create a file `../release.properties` —that is, one directory 
+above the source tree you are using. (That's to keep the source tree uncontaminated)
 
 ```
-git checkout -b branches/branch-0.6
-git push origin branches/branch-0.6
+slider.release.branch=branches/branch-0.9
+slider.release.version=0.90.2-incubating
+slider.develop.version=0.91.0-incubating-SNAPSHOT
+release.jira=SLIDER-1014
+release.rc.suffix=-RC0
+svn.publish.dir=~/svn/slider-dist
 ```
 
-This branch is where all the release work will take place. That can include patching and cherry picking from the development branch.
+## Create the release in JIRA
+
+Tell JIRA there's a new release. This moves it from "unreleased" to "released", creating a URL listing all issues fixed. 
 
+This URL is be used in the vote emails to highlight changes.
 
-### Update the version numbers on the main branch
+*Important:* To perform this task, you must be registered as an admin for the
+Slider project on JIRA. If you are not: ask someone who is to do it for you.
 
+1. Go to the [Slider Versions page](https://issues.apache.org/jira/plugins/servlet/project-config/SLIDER/versions)
+1. Locate the pending release. Make sure it is in the correct order of releases: all previous releases MUST be below it; future releases above it. The immediate next release MUST be directly above the pending release.
+1. On the pending release
+    i. Set the release date to the current day.
+    i. Select the drop down "gear-cog" menu to the right of the page,  then the "Release" option.
+    i. Carrying all forward issues that haven't been completed *except the JIRA covering the release itself.
+1. Go to the [Slider versions page](https://issues.apache.org/jira/browse/SLIDER/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel)
+1. Locate the release just issued and click through it.
+1. Get from the page link, work out the "version" of the release artifact
 
 
-Get back to the develop branch and patch its versions
+set the release property `release.jira.version` to the version field
 
 ```
-git checkout develop
-mvn versions:set -DnewVersion=$SLIDER_DEV
-git commit -a -m "$SLIDER_RELEASE_JIRA updating development POMs to $SLIDER_DEV"
-
-git push origin
+release.jira.version=12334370
 ```
 
-You may want to hold back from pushing things up if you are doing a dry run
-
-# Automated releases via maven
- 
-The Slider project uses Maven to automatically publish all the slider artifacts —source and binary— to the ASF repositories
-
-Core sequence
-
-1. Dry Run
-1. Deploy to staging
-1. Publish the real release
-1. Get the votes in
-
-If the vote fails: fix the issues then repeat
-
- 
-Recommended Reading
-
-* [ASF release guidelines](http://www.apache.org/dev/release.html)
-* [Maven release plugin](http://maven.apache.org/maven-release/maven-release-plugin/index.html)
-* [ASF guide to publishing maven artifacts](http://www.apache.org/dev/publishing-maven-artifacts.html)
-* [Publishing Maven Artifacts](http://www.apache.org/dev/publishing-maven-artifacts.html)
-* [https://wiki.apache.org/commons/UsingNexus](https://wiki.apache.org/commons/UsingNexus)
-* [Apache Parent Pom](http://repo.maven.apache.org/maven2/org/apache/apache/10/apache-10.pom) for a template POM containing the release plugins. This is not used in the slider release —it was used as a source of some of the actions; the remainder being from the hadoop project.
-
-
-## Preparation
+It may seem premature to mark the release as complete, 
+but our process closes it early so that the changes page is generated.
+It also forces all outstanding issues into the next version —which is where
+they will have to be fixed.
 
-### Maven Publishing settings
- 
+### Build the release notes
 
+Create a markdown release note which will be used for summarizing
+changes. 
 
-You need to provide credentials to the ASF maven repos for publishing/releasing
-artifacts, using your ASF username and password.
+Include
 
-The ASF docs say use the maven encryption feature. 
-Our policy is: encrypt your HDD in its entirety —you should be doing that
-anyway.
+1. A quick summary
+1. The Hadoop version against which this release was built
+1. The URL to the JIRA release
 
-In `~/.m2/settings.xml`:
+The multi-line release notes should go into the slider SVN repo under
+`site/trunk/content/release_notes`.
 
-    <settings>
-        ...
-        <servers>
-            <!-- To publish a snapshot-->
-            <server>
-                <id>apache.snapshots.https</id>
-                <username />
-                <password />
-            </server>
-            <!-- To stage a release -->
-            <server>
-                <id>apache.staging.https</id>
-                <username />
-                <password />
-            </server>
-            <!-- To finalise the release-->
-            <server>
-                <id>apache.releases.https</id>
-                <username />
-                <password />
-            </server>
-        </servers>
-        ...
-    </settings>
+(this is yet to be automated —it should be possible)
 
+## Building a Release Candidate
 
-### Environment variable setup
+### Review your release settings
 
-It's handy to set up an environment with the arguments needed for releases.
+The `init` target loads in the properties, builds up some new values
+and displays them.
 
 ```
-export RELARGS="-DskipTests -DskipITs -Papache-release"
-echo $RELARGS
+ant -f bin/release.xml init
 ```
 
-The profile `apache-release` is used to select a subset of the app packages,
-because the default builds of these weren't usable and had odd version numbers
-too.
-
-## Git preparation
-
-The maven automated release adds its own git tags and pushes things up to a branch.
-All work must be done on a branch created for the release process, so as to
-not interfere with the rest of the development.
-You are likely to end up rolling back the branch, force-pushing changes etc.,
-so cannot actively share the branch with anyone.
-
-### Clone the repo.
+### Verify the license of dependent artifacts
 
-Don't release from your development dir; do it somewhere clean. Why so? Easier to clean up and guaranteed isolation.
+Maven can check that all dependent artifacts have valid licenses
 
-In a directory of your choice
+For modules which publish JARs (`slider-core` and `slider-funtest`),
+run the third party check for JARs. If you run this at the top level project
+it will do it for the relevant sub projects.
 
 ```
-git clone https://git-wip-us.apache.org/repos/asf/incubator-slider.git slider-$SLIDER_RELEASE
-cd slider-$SLIDER_RELEASE
+ant -f bin/release.xml license-check
 ```
 
-### Check out the branch you plan to release on; tag it
+This will build everything then generate license files under each module in
+`target/generated-sources/license/THIRD-PARTY.txt`. Inspect it and make sure
+there are no GPL or LGPL dependencies which do not also have a license option
+which is permitted by the ASF.
 
-The tag is so that if things go wrong you know what you have to roll back to.
+Dependencies without a license are warned about.
+To fix this, make sure that the (generated or updated) file `src/license/THIRD-PARTY.properties`
+has an entry for every dependency without a license, declaring what their license is.
 
-```
-git checkout -t origin/branches/branch-0.6
-```
 
-In the new clone, tag the head of the branch you plan to to work from. You don't need to push the tag to the repo.
+### Update the maven artifact version to that of the new release
 
 ```
-git tag -a tag_2015-12-18-$SLIDER_RELEASE -m "starting release of $SLIDER_RELEASE"
+ant -f bin/release.xml set-to-release-version
+ant -f bin/release.xml git-commit git-push -Dgit.commit.text="updating to release version"
 ```
 
-### Clean build it
+### Create the release branch
 
-Maybe: purge your entire repository of slider artifacts
+Create the release branch and push it to the apache repository:
 
 ```
-rm -rf ~/.m2/repository/org/apache/slider
+ant -f bin/release.xml git-create-release-branch
 ```
 
-## Maven Release plugin
-
-The maven release plugin tries to do everything: update versions, 
-tag repositories, push up artifacts.
+This branch is where all the release work will take place. That can include
+patching and cherry-picking from the development branch.
 
-### Test Deploy a snapshot
-
-Create the -SNAPSHOT artifacts
+### Return to the develop branch and increment its version
 
 ```
-mvn clean install -DskipTests
+ant -f bin/release.xml git-switch-develop-branch set-to-new-develop-version
+ant -f bin/release.xml git-commit -Dgit.commit.text="updating to new develop version"
+ant -f bin/release.xml git-push
 ```
 
+At this point the slider version in `develop/` is that for ongoing development;
+that in the new release branch set to the release version. The git history
+is such that if you merge all changes in the release branch back into `develop/`,
+the slider artifact version in the POM files will remain unchanged —the switch
+to the release version is a commit shared across both branches.
 
-Then push up a `-SNAPSHOT` version to the ASF snapshot repo.
-This dry-run verifies that you have the basic upload settings, signing keys etc.
 
-```
-mvn clean deploy $RELARGS -Darguments="$RELARGS"
-```
+### Check out a clean source tree for the build.
 
-After the upload has completed, the complete archives will be in the version-specific subdirectory of
+Adjacent to your normal development directory, check out a new copy of slider
 
 ```
-https://repository.apache.org/content/repositories/snapshots/org/apache/slider/slider-assembly/
+git clone https://git-wip-us.apache.org/repos/asf/incubator-slider.git slider-release
 ```
 
-(there may be older versions there from previous dry runs: look for the one with the date of your run on it)
-
-Download the uploaded `.tar.gz`, expand it and verify that it is complete. That includes
+This ensures that there are no .git-ignored files in the source tree,
+files which may end up in the source distribution.
 
-1. Download the associate `.asc` file with the PGP signature.
-1. Validate the signature: `gpg --verify slider-assembly-*.asc`
-1. untar the assembly file: `tar -xz slider-assembly*.tar.gz`
-1. Verify that the file `slider-agent.tar.gz` exists.
-1. Execute `bin/slider version`
-1. Assuming you have an existing installation for testing, set `SLIDER_CONF_DIR` to the configuration directory, then
-`./slider diagnostics --yarn --client --credentials --verbose` 
+This source tree should be viewed as read-only: all changes to the branch
+must be done in your development directory, committed and pushed to the ASF
+repository, then retrieved by updating the branch in the release directory.
 
+Assuming the two source trees are adjacent, the existing `../release.properties`
+file is now loaded by the new version.
 
-### Perform a dry run of the release
+In `slider-release`, Check out the specific branch for the release.
 
-Perform a dry run. This will prompt you for new versions —and commit changes to your local branch.
+Example
 
 ```
-mvn release:prepare -DdryRun=true -DautoVersionSubmodules=true -Darguments="$RELARGS"
+cd slider-release
+git checkout -t origin/branches/branch-0.9
 ```
 
-1. This prompts for the version numbers for the slider version to release: use
- the `slider-0.61.0-incubating` or equivalent
-1. go with them unless you have specific choices of
-versions. 
-1. Look at the output to verify the versions are what you want.
-1. Roll back to the commit tagged earlier: `git reset --hard`
+*For the test of this document, all instructions are to be executed in the this `slider-release`
+directory, in the release branch.*
 
 
-## Perform the Maven release
+### Build and Release to Nexus and SVN
 
 ```
-mvn release:clean
- 
-mvn -B release:prepare -DautoVersionSubmodules=true -Dtag=slider-$SLIDER_RELEASE \
-  -DreleaseVersion=$SLIDER_RELEASE \
-  -DdevelopmentVersion=$SLIDER_DEV \
-  -Darguments="$RELARGS" -Dresume=false 
-
-mvn release:perform -Darguments="$RELARGS"
- 
-
+ant -f bin/release.xml clean release
 ```
 
-1. The `release:prepare` command will trigger the local commit of changes to POMs, tagging this and pushing up the branch.
-2. Only skip those test runs if you have been running the tests in advance.
-3. The funtests work by explicitly invoking `bin\slider` in the expanded tar directory under
-`../slider-assembly/target` —that is, it doesn't download and test any `.tar.gz` artifacts uploaded during
-the staging process.
-
-
-You may be asked for your ASF git password repeatedly.
-Consult [StackOverflow](http://stackoverflow.com/questions/5343068/is-there-a-way-to-skip-password-typing-when-using-https-github)
-
-*rolling back*
-After this phase (or when you cancel it), you'll need to roll back git,
-
+Follow the instructions printed for the manual steps
 
-
-### Tip: reverting changes
-
-Try
+To see them again:
 
 ```
-mvn release:rollback
+ant -f bin/release.xml print-nexus-instructions
 ```
 
-It *may* work. Then
+The [Nexus UI](https://repository.apache.org/content/repositories/)
+gives the name of the repository, such as `orgapacheslider-1010`
 
-1. Via GUI/CLI Roll back the git branch to where it was before the release actions started
-changing things. That should be the revision which you tagged.
-1. Force push that rolled back branch back to the git repository
-1. Delete any newly created `slider-XY-incubating` tag locally *and* remotely.
-1. Run `mvn clean`
+In `release.properties` set `nexus.staging.repository` to this value 
 
+```
+nexus.staging.repository=orgapacheslider-1010
+```
 
-If you are in a specific release-only directory (as recommended):
+### Begin the slider-dev vote
 
 ```
-git clean -d -f -x
-git reset --hard
+ant -f bin/release.xml generate-vote-text
 ```
 
-### Tip: branching instead of preparing
+This saves the vote file to `target/vote.txt`
 
-The `mvn release:branch` goal can be used instead of `mvn release:prepare`,
-which creates a branch explicitly for the release. We haven't used this yet.
+The git checksum in this message is automatically calculated (the `git-version`) target.
+You *must not* make a release from a repository which has modified files,
+as the source archive and the checksummed version will differ.
 
+Load this and use it as the text for an email to send to the vote. The
+address and subject line are included in the text.
+
+Don't forget to you vote yourself!
 
 
 ### Tip: Validating the artifacts
 
-There's a small projects [slider-dependency-check](https://github.com/steveloughran/slider-dependency-check)
+There's a small project [slider-dependency-check](https://github.com/steveloughran/slider-dependency-check)
 which verifies that slider artifacts can be downloaded from the public or staging repositories.
 Clone this project and read its instructions to verify that everything went up to the staging repo.
 
-### Tip: isolating the release process from the ASF repo
 
-While trying to get the release out, the maven release plugin likes to commit things
-to git, create tags and push them out. You can isolate your work from the ASF repository
-by (temporarily) unhooking your release source tree from the ASF one.
+### Await the slider-dev vote 
 
-You also need to isolate the repository settings in the build
+Await the declared time for the slider vote to complete
 
-Add these options to the build commands, using a URL to a repository to
-which you do have access
+Add all the results as release properties
 
 ```
--Pprivate-git-repo -Dgit.repo=https://github.com/steveloughran/incubator-slider.git 
+vote.result.positive.binding=0
+vote.result.zero.binding=0
+vote.result.negative.binding=0
+vote.result.negative=0
+vote.result.positive=0
+vote.result.zero=0
 ```
 
-After creating a release to put up for a vote, you will need to push the
-relevant (final) tag out to the ASF repository.
-
-## Close the release in Nexus
+### Generate the result message
 
-1. Log in to [https://repository.apache.org/index.html](https://repository.apache.org/index.html)
-with your ASF username and LDAP password
-1. Go to [Staging Repositories](https://repository.apache.org/index.html#stagingRepositories)
-1. Find the latest slider repository in the list
-1. Select it; 
-1. Browse the content, verify the version number is what you want.
-1. Hit the "close" button. This will fail if it doesn't meet the ASF criteria
-1. Wait for the close process to complete.
-1. Get the URL of the closed staging repository. This is needed for the next step —the votes.
+Generate the email to send to the developer list
 
+```
+ant -f bin/release.xml generate-result-message
+```
 
+Load the text for this message from the generated file (`target/vote-results.txt`)
+and send it out.
 
-## Tell  JIRA of the  releases
+If the vote was a failure, the text will indicate this and the build will will fail.
 
-Tell JIRA there's a new release. This moves it from "unreleased" to "released", creating a URL listing all issues fixed. 
+Follow the instructions in *How to clean up after a failed/cancelled vote*
+to clean up.
 
-This URL can be used in the vote emails to highlight changes.
+You now have to fix the build. Do this in your R/W source tree, not `slider-release`, and
+propagate the changes to the release source tree via git commit, pushes and pulls.
 
-*Important:* To perform this task, you must be registered as an admin for the
-Slider project on JIRA.
+Then repeat the entire release process from *Build and Release to Nexus and SVN*.
 
-1. Go to the [Slider Versions page](https://issues.apache.org/jira/plugins/servlet/project-config/SLIDER/versions)
-1. Locate the pending release. Make sure it is in the correct order of releases: all previous releases MUST be below it; future releases above it. The immediate next release MUST be directly above the pending release.
-1. On the pending release
-    i. Set the release date to the current day.
-    i. Select the drop down "gear-cog" menu to the right of the page,  then the "Release" option.
-    i. Carrying all forward issues that haven't been completed *except the JIRA covering the release itself.
-1. Go to the [Slider versions page](https://issues.apache.org/jira/browse/SLIDER/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel)
-1. Locate the release just issued and click through it.
-1. Get the page link
-1. Ideally, shorten it via the [ASF Link shortener](https://s.apache.org/)
 
-If the vote is cancelled, the release can be "unreleased". 
+### Call for an incubator vote
 
+If the slider-dev vote passes, call for (the binding) vote on the incubator
+general list. This vote tends to be a review of artifacts and licensing, rather
+than at the build and test level.
 
-## Get the Votes In
+The incubator vote email must include references to the VOTE and RESULT threads
+ from the developer mailing list.
 
-### Set up your env vars for email templates
+1. Go to the [Slider mail archives](http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/).
+1. Locate the email thread of the vote, and get the permanent link to the email at the start of the vote.
+Save this in the property `mail.vote.thread`
+1. Repeat for the email of the results, setting the release property `mail.vote.result.thread`
 
-set up the environment with the git release tag, URL to the staging repository, and your ASF username:
+Example:
 
 ```
-export RELEASE_TAG=
-export STAGING_REPO=
-export ASF_USER=
-export SOURCE_ZIP
-export SOURCE_TAR_GZ
+mail.vote.thread=http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201512.mbox/%3C7EBD312A-E115-4A99-AAE7-1BF553E3B28D%40hortonworks.com%3E
+mail.vote.result.thread=http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201601.mbox/%3CC28233B7-9016-44F4-9A6B-1EBC8BFCDF08%40hortonworks.com%3E
 ```
 
-example
+Build the incubator vote into the text file, `target/vote-incubator.txt`
 
 ```
-export RELEASE_TAG=64a8bac068e6801748fb973dbfb590bc62c60935
-export ASF_USER=stevel
-
-export STAGING_REPO=https://repository.apache.org/content/repositories/orgapacheslider-1003
-curl --head $STAGING_REPO
-
-export SOURCE_ZIP=$STAGING_REPO/org/apache/slider/slider/$SLIDER_RELEASE/slider-$SLIDER_RELEASE-source-release.tar.gz
-echo $SOURCE_ZIP
-curl --head $SOURCE_ZIP
-
-export SOURCE_TAR_GZ=$STAGING_REPO/org/apache/slider/slider/$SLIDER_RELEASE/slider-$SLIDER_RELEASE-source-release.zip
-echo $SOURCE_TAR_GZ
-
-
-export APACHE_VERSION_PAGE=(shorten this via s.apache.org)https://issues.apache.org/jira/browse/SLIDER/fixforversion/12327198
+ant -f bin/release.xml generate-incubator-vote
 ```
 
-### Call for a release vote on the dev@slider list
-
-Call for a release VOTE to the dev mailing list (`dev@slider.incubator.apache.org`).
-
-To build the URLs, echo them then verify in your browser that they are present.
-
-**Subject:**
-<pre>
-echo "[VOTE] Apache Slider Incubating Release $SLIDER_RELEASE"
-</pre>
-
-**Body:**
-<pre>
-echo "Hello,"
-echo "This is a call for a vote on Apache Slider $SLIDER_RELEASE release"
-
-echo "This is a source release."
-
-echo "The list of all issues fixed: $APACHE_VERSION_PAGE
-
-echo "Staged artifacts: $STAGING_REPO" 
-echo "Source zip: $SOURCE_ZIP" 
-echo "Source tar.gz: $SOURCE_TAR_GZ" 
-
-echo "Git source:"
-echo "https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=commit;h=$RELEASE_TAG "
-echo "SHA1: $RELEASE_TAG "
-echo "Tag: $SLIDER_RELEASE"
-
-echo "PGP key:"
-echo "http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=$ASF_USER@apache.org"
-
-Build/test instructions at:
-http://slider.incubator.apache.org/developing/building.html
-
-Vote will be open for 72 hours 
-
-[ ] +1 approve 
-[ ] +0 no opinion 
-[ ] -1 disapprove (and reason why) 
-
-</pre>    
-    
- 
-* CHECK ALL THE URLS  *
+Use this file as the basis of an email to the incubator general list.
 
-### Wait for the dev@slider result
+### Process the results of the incubator vote
 
-When it comes in, post the results in another email, with Subject -
-<br>
-[RESULT] [VOTE] Apache Slider Incubating Release $SLIDER_RELEASE
+Await 72h for the results of the incubator vote —you can of course finish early
+if a binding Incubator PMC (IPMC) member votes against it.
 
+Record the vote into `vote.incubator.result.` release properties:
 
-### Call for an incubator vote
-
-If the VOTE passes, call for (the binding) VOTE from IPMC. Include the VOTE and RESULT threads from the developer mailing list.
-
-1. Go to the [Slider mail archives](http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/).
-1. Locate the email thread of the vote
-    i. get the permanent link to the email at the start of the vote
-    i. shorten it via the [ASF Link Shortener](https://s.apache.org/). You must be signed in with your ASF LDAP password. 
-    i. Use this as the URL for the voting thread
-1. Repeat for the email of the results
-
-Note: This is a sample email. Please replace all versions and links for the current release.
-
-**Subject:**
-<pre>
-[VOTE] Release Apache Slider 0.80.0-incubating
-</pre>
-
-**Body:**
-<pre>
-Hello,
-
-This is a call for a vote for releasing Apache Slider 0.80.0-incubating. 
-
-This is a source release.
-
-Summary of fixes: (shorten this via s.apache.org)https://issues.apache.org/jira/browse/SLIDER/fixforversion/12329384
-Release notes: (shorten this via s.apache.org)https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315422&version=12329384
-Vote thread: (shorten this via s.apache.org)http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201505.mbox/%3CD17220E0.D0AD%25gsaha%40hortonworks.com%3E
-Results: (shorten this via s.apache.org)http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201505.mbox/%3CD177A7D8.D521%25gsaha%40hortonworks.com%3E
-
-Staged artifacts:
-https://repository.apache.org/content/repositories/orgapacheslider-1006/org/apache/slider
-Source zip: https://repository.apache.org/content/repositories/orgapacheslider-1006/org/apache/slider/slider/0.80.0-incubating/slider-0.80.0-incubating-source-release.zip
-Source tar.gz: https://repository.apache.org/content/repositories/orgapacheslider-1006/org/apache/slider/slider/0.80.0-incubating/slider-0.80.0-incubating-source-release.tar.gz
-
-Git Source:
-https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=commit;h=d7e3449fa649dbb88388329724334f2d1aac2869
-SHA1: d7e3449fa649dbb88388329724334f2d1aac2869
-Tag: slider-0.80.0-incubating
-
-PGP key:
-http://pgp.mit.edu/pks/lookup?op=vindex&search=gourksaha@apache.org
-
-Basic build/test instructions:
-http://slider.incubator.apache.org/developing/building.html
-
-Please vote on releasing this package as Apache Slider 0.80.0-incubating.
-
-This vote will be open for 72 hours.
-
-[ ] +1 approve
-[ ] +0 no opinion
-[ ] -1 disapprove (and reason why)
-
-Thank You,
-The Apache Slider Team
-</pre>
-
-### Await the general@incubator results; publish them
-
-After 72 hours, publish the results
-
-Sample:
-
+```
+vote.incubator.result.positive.binding=0
+vote.incubator.result.zero.binding=0
+vote.incubator.result.negative.binding=0
+```
 
-    Title: [RESULT][VOTE] Apache Slider $SLIDER_RELEASE $RELEASE_RC
-   
-    Thanks for the votes.
-    The VOTE passes with X, +1 votes from IPMC.
+Then create the release message
 
-    List any IPMC votes.
+```
+ant -f bin/release.xml generate-incubator-result-message
+```
 
-    Other +1 votes:
+This build target will fail if there were any binding -1 votes or not
+enough positive votes.
 
-    List all non-IPMC votes.
+If the vote failed, 
 
-If the vote has been successful —you may now release the artifacts.
+1. Follow the instructions in *How to clean up after a failed/cancelled vote*
+   to clean up.
+1. address the issues.
+1. repeat the entire release process from *Build and Release to Nexus and SVN*.
 
+### Commit the final svn release
+Assuming the vote succeeded, you can now commit the artifacts
 
+```
+ant -f bin/release.xml svn-release-final-artifacts
+```
 
-## Publishing the Nexus staging repository
+### Release the staged Nexus artifacts
 
-Once —and only once— the incubator vote is successful, you may release the nexus-staged artifacts.
+Now release the nexus-staged artifacts to the central repository.
 
 1. Log in to [the ASF Nexus server](https://repository.apache.org/index.html#stagingRepositories)
 1. Locate and select the staged Slider repository
-1. In the toolbar above, press the **release** button
+1. In the toolbar above, press the **Release** button
 
 Releasing "can take time", as the web site will inform you.
 
-## Publishing the source and binary tar/zip files
-
-The ASF distribution system mirrors the source and binary files across all
-apache mirror sites.
- 
-This the standard way which the archives are distributed.
-
-Publish the release as below:
+### Await the artifacts to propagate
 
+The released artifacts may take up to 24 hours to replicate to the mirrors.
 
-### Grab the released artifacts from Nexus
+The probe for these artifacts is:
 
-1. Fetch the files from where released
- (e.g. [slider-assembly 0.61](https://repository.apache.org/content/groups/public/org/apache/slider/slider-assembly/0.61.0-incubating/)
-1. Create a temp directory somewhere
+```
+ant -f bin/release.xml check-release-urls
+```
 
-        mkdir publishing
-        cd publishing
-1. create a directory under it: `artifacts`
+Only once it has succeeded can the announcement be made
 
-        mkdir artifacts
-        cd artifacts
+### Announce the release
 
+The released artifacts may take up to 24 hours to replicate to the mirrors.
 
-1. From  `slider-assembly/$SLIDER_RELEASE` download all the `-all` files:
-the zip and tar files and their checksums into `artifacts`
-1. Repeat for the source files `org/apache/slider/slider/$SLIDER_RELEASE`
+Generate the release message:
 
-### Check out the distribution dir under `publishing`
+```
+ant -f bin/release.xml generate-announcement-message
+```
 
-    svn co https://dist.apache.org/repos/dist/release/incubator/slider slider-dist
+Then follow the instructions on where to email it.
  
-    cd slider-dist
-
-Make sure your PGP keys is in the `KEYS` file. The instructions to add a key 
-are at the top of that file
-
-
-Then...
+### Update Slider Web site
 
-    mv ../artifacts $SLIDER_RELEASE 
-    svn add $SLIDER_RELEASE
-    svn commit -m "$SLIDER_RELEASE_JIRA Committing Release $SLIDER_RELEASE"
-
-The commit can take time. In the past it has been rejected due to the size of
-the patch...this has now been addressed and should remain so.
-
-### Web site updates
-
-Update the Slider website as needed. Most of the documents would have been
+Update the Slider website as needed. Most of the documents should have been
 updated by now to reflect the released version.
 *The remaining changes should really be modifying the references to the latest release to the new version.*
 
 The download details for the latest release needs to be updated after mirrors are updated in . 
 
-Verify the download links at [Slider Page](http://slider.incubator.apache.org).
+In particular, review `content/downloads/index.md`
 
+After any changes, [trigger a site rebuild](https://cms.apache.org/slider/publish).
 
 
-## Announcing
+### Finish the JIRA
 
-Send an announcement:
+Log the time, close the issue. 
 
-The released artifacts may take up to 24 hours to replicate to the mirrors.
+### Example `../release.properties`
 
-Send an announcement to the Slider dev, Slider user, and the general Apache announcement (`announce@apache.org`) list after the bits have replicated.
-To send the message to `announce@apache.org`, you will need to send the message from your `apache.org` email address.
+Here is the final `release.properties` file from the 0.90.2 release
 
-Sample:
+```
+slider.release.version=0.90.2-incubating
+slider.develop.version=0.91.0-incubating-SNAPSHOT
+release.jira=SLIDER-1014
+release.jira.version=12334370
+release.rc.suffix=-RC1
+svn.publish.dir=/Users/stevel/Java/Apache/slider-dist
 
-    Title: [ANNOUNCE] Apache Slider x.y.z-incubating.
-    
-    The Apache Slider team is proud to announce Apache Slider incubation release version x.y.z.
+nexus.staging.repository=orgapacheslider-1013
+git.release.branch=branches/branch-0.90
 
-    Apache Slider (incubating) is a YARN application which deploys existing distributed applications on YARN,
-    monitors them, and makes them larger or smaller as desired - even while the application is running.
-    
-    The release artifacts are available at: 
-    http://www.apache.org/dyn/closer.cgi/incubator/slider/x.y.z-incubating/
-    
-    To use the artifacts, please use the following documentation: 
-    http://slider.incubator.apache.org/docs/getting_started.html
-    
-    Release notes available at:
-    https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315422&version=12329384
+vote.result.positive.binding=3
+vote.result.zero.binding=0
+vote.result.negative.binding=0
 
-    We would like to thank all the contributors that made the release possible.
+mail.vote.thread=http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201512.mbox/%3C7EBD312A-E115-4A99-AAE7-1BF553E3B28D%40hortonworks.com%3E
+mail.vote.result.thread=http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201601.mbox/%3CC28233B7-9016-44F4-9A6B-1EBC8BFCDF08%40hortonworks.com%3E
+```
 
-    Regards,
-    The Slider Team
-    
-    -----
+### How to clean up after a failed/cancelled vote
 
-    DISCLAIMER
+If a vote fails you must:
 
-    Apache Slider is an effort undergoing incubation at The Apache Software Foundation (ASF),
-    sponsored by the Apache Incubator PMC. Incubation is required of all newly accepted projects
-    until a further review indicates that the infrastructure, communications, and decision making
-    process have stabilized in a manner consistent with other successful ASF projects. While incubation
-    status is not necessarily a reflection of the completeness or stability of the code, it does indicate
-    that the project has yet to be fully endorsed by the ASF.
+1. Clean up the release artifacts in the svn distribution directory
 
+        ant -f bin/release.xml svn-delete-rc-artifacts
 
+1. Log in to [the ASF Nexus server](https://repository.apache.org/index.html#stagingRepositories)
+1. Locate and select the staged Slider repository
+1. In the toolbar above, press the **Drop** button
 
+### Notes
 
-## Update the site
+1. The maven `package` and `deploy` operations both rebuild their artifacts;
+if you re-run them between stages they may produce different artifacts.
 
-1. Update documentation in the svn site repo. In particular, review
-`content/downloads/index.md`
-2. [trigger a site rebuild](https://cms.apache.org/slider/publish).
+1. (you can set the property `git.version` if you wish to build a vote message
+from a different git version from the current build, but as you must
+be calling for a vote on the version released, only do this if you are modifying
+the `release.xml` release file)`
 
-## Finish the JIRA
+1. You can create the `release.properties` file elsewhere and point to it via the
+ant `release.properties` property option. 
+This would need to be set in `build.properties` or on the command line
 
-Log the time, close the issue. This should normally be the end of a 
-sprint —so wrap that up too.
+```
+ant -f bin/release.xml -Drelease.properties=~/release.properties
+```
 
+It's easier to use a symbolic link here.
 
+1. The slider POMs offer different profiles of Hadoop versions to build against. The instructions 
+below use the default. If a profile is needed, append it to all the maven commands.
 
-## Get back to developing!
+```
+mvn.extra.args=-Prelease-2.8
+```
 
-Check out the develop branch and purge all release artifacts
+1. If you are not building against a stable Hadoop release
 
-    git checkout develop
-    git pull origin
-    mvn clean
+    1. Check out the Hadoop branch you intend to build and test against —and include in
+       the redistributable artifacts.
+    1. Build it via its own `mvn clean install -DskipTests`
+    1. Note the git revision number of this build —for documentation.
+    1. Maybe: tag that revision so you can easily revert to it.
+    1. set the `-Dhadoop.version` property to the targeted Hadoop version in
+    the `mvn.extra.args` release property
 
+          mvn.extra.args=-Dhadoop.version=hadoop-2.8.12
 
- 
-## Manual "we don't trust `mvn release` strategy
+Unstable Hadoop versions MUST NOT be used for anything declared as a stable
+Slider release.
 
 
-```
-mvn versions:set -DnewVersion=$SLIDER_RELEASE
+## Links
+
+* [ASF incubator release manual](http://incubator.apache.org/guides/releasemanagement.html)
+* [ASF release guidelines](http://www.apache.org/dev/release.html)
+* [Publishing Releases](http://www.apache.org/dev/release-publishing.html)
+* [ASF guide to publishing maven artifacts](http://www.apache.org/dev/publishing-maven-artifacts.html)
+* [https://wiki.apache.org/commons/UsingNexus](https://wiki.apache.org/commons/UsingNexus)
+* [git flow](http://danielkummer.github.io/git-flow-cheatsheet/)
+
 
-```

Modified: incubator/slider/site/trunk/content/docs/client-configuration.md
URL: http://svn.apache.org/viewvc/incubator/slider/site/trunk/content/docs/client-configuration.md?rev=1722976&r1=1722975&r2=1722976&view=diff
==============================================================================
--- incubator/slider/site/trunk/content/docs/client-configuration.md (original)
+++ incubator/slider/site/trunk/content/docs/client-configuration.md Mon Jan  4 22:55:22 2016
@@ -159,7 +159,7 @@ Here is an example file:
     </property>
 
 
-This defines both the filesystem and the YARN RM, and so obviates the need
+This defines both the filesystem and the YARN RM, and so avoids the need
 to declare either on the command line.
 
 If an option is defined in the `slider-client.xml` file and on the command line
@@ -345,17 +345,24 @@ file, details on properties will be part
 
 ## How client options are passed down to created clusters.
 
-Most cient configuration options are
-not passed down to the XML site specification of the created cluster.
-
+Most client configuration options are not passed down to the XML site
+specification of the created cluster. It's expected that the various `-site.xml`
+files which are automatically added to the classpath and hence AM configuration
+contain everything that is needed.
+
+That said, one problem which does re-occur is that the `-site.xml` files have
+an address for a service such as the RM of `0.0.0.0`, which is precisely
+what the RM needs to be given when expected to bind to all IP
+addresses/network cards on its host. It is precisely what is not needed
+for a client to actually locate the RM. This is why the bindings of the
+RM and HDFS are always passed in.
 
 Exceptions:
 
 1. the HDFS bindings: `fs.defaultFS`,
 which is passed down both as that property and as `fs.default.name`,
-and, 
 
-2. in a secure cluster, the security flag (`slider.security.enabled`)
-and the HDFS Kerberos principal.
+1. The YARN registry options. 
+
+1. The YARN RM bindings.
 
-3. The YARN registry options. 

Modified: incubator/slider/site/trunk/content/docs/configuration/core.md
URL: http://svn.apache.org/viewvc/incubator/slider/site/trunk/content/docs/configuration/core.md?rev=1722976&r1=1722975&r2=1722976&view=diff
==============================================================================
--- incubator/slider/site/trunk/content/docs/configuration/core.md (original)
+++ incubator/slider/site/trunk/content/docs/configuration/core.md Mon Jan  4 22:55:22 2016
@@ -298,7 +298,7 @@ each using one vcore and 512 MB of RAM.
 
 This defines parameters that are to be used when creating the instance of the
 application, and instances of the individual components.
-    
+
     {
       "schema": "http://example.org/specification/v2.0.0",
 
@@ -315,7 +315,7 @@ application, and instances of the indivi
         "site.hbase.regionserver.info.port": "0"
       },
       "components": {
-    
+
         "worker": {
           "jvm.heapsize": "512M"
         },
@@ -374,7 +374,7 @@ different components.
       "credentials" {
       }
     }
-    
+
 The `site.` properties have been passed down to each component, components
 whose templates may generate local site configurations. The override model
 does not prevent any component from overriding global configuration so as

Modified: incubator/slider/site/trunk/content/docs/security.md
URL: http://svn.apache.org/viewvc/incubator/slider/site/trunk/content/docs/security.md?rev=1722976&r1=1722975&r2=1722976&view=diff
==============================================================================
--- incubator/slider/site/trunk/content/docs/security.md (original)
+++ incubator/slider/site/trunk/content/docs/security.md Mon Jan  4 22:55:22 2016
@@ -324,8 +324,20 @@ If you specify a list of aliases and are
         
 At runtime, Slider will read the credential mapped to the alias (in this case, ``"app_component.keystore.password.alias"``), and leverage the password stored to secure the generated keystore.
 
-## Important: Java Cryptography Package  
 
+## Zookeeper binding
+
+Sometimes problems authenticating with Zookeeper have surfaced, with the error
+being about an unknown JAAS Config
+
+```
+2015-12-15 13:01:29,247 [main] ERROR zk.RegistrySecurity (validateContext(703)) - Entry "Client" not found; JAAS config = ; java.security.auth.login.config=(undefined)
+2015-12-15 13:01:31,066 [main-SendThread(devix:2181)] WARN  zookeeper.ClientCnxn (startConnect(957)) - SASL configuration failed: javax.security.auth.login.LoginException: Client cannot SASL-authenticate because the specified JAAS configuration section 'Client' could not be found. Will continue connection to Zookeeper server without SASL authentication, if Zookeeper server allows it.
+2015-12-15 13:01:31,069 [main-EventThread] ERROR curator.ConnectionState (checkState(244)) - Authentication failed
+```
+
+
+## Important: Java Cryptography Package  
 
 When trying to talk to a secure cluster you may see the message:
 

Modified: incubator/slider/site/trunk/content/docs/slider_specs/specifying_exports.md
URL: http://svn.apache.org/viewvc/incubator/slider/site/trunk/content/docs/slider_specs/specifying_exports.md?rev=1722976&r1=1722975&r2=1722976&view=diff
==============================================================================
--- incubator/slider/site/trunk/content/docs/slider_specs/specifying_exports.md (original)
+++ incubator/slider/site/trunk/content/docs/slider_specs/specifying_exports.md Mon Jan  4 22:55:22 2016
@@ -20,7 +20,7 @@
 Slider app package allows an application instance to export data about itself, usually to be discoverable by the clients and IT admins. The main classes of export specified via the application package are as follows:
 
 * Exporting configurations
-* Exporting URLs, host:ports, or other information constructed based on the deployemnt context and applied configuration
+* Exporting URLs, host:ports, or other information constructed based on the deployment context and applied configuration
 
 All exports are specified in the metadata file, `metainfo.xml`. An export can be at the level of the application - it means there is only one copy of this data or at the level of a component instance - there is one copy of the data per component instance.
 
@@ -107,7 +107,7 @@ When any component instance comes up the
        "container_1407354284611_0059_01_000006.log_viewer_port": "host2:60515"
     }
 
-A structured JOSN for component exports are available @ `.../ws/v1/slider/publisher/exports`. The container log and work directories are automatically made available.
+A structured JSON for component exports is available at `.../ws/v1/slider/publisher/exports`. The container log and work directories are automatically made available.
 
 Sample:
 
@@ -161,4 +161,4 @@ Sample:
       "empty": false
     }
     
- 
\ No newline at end of file
+