Merge branch 'master' into migration

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,35 @@
+<!-- Thanks for filing an issue! Before hitting the button, please answer these questions. It's helpful to search the existing GitHub issues first. It's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of-->
+
+**Is this a request for help?**:
+
+---
+
+**Is this a BUG REPORT or FEATURE REQUEST?** (choose one):
+
+<!--
+If this is a BUG REPORT, please:
+  - Fill in as much of the template below as you can.  If you leave out
+    information, we can't help you as well.
+
+If this is a FEATURE REQUEST, please:
+  - Describe *in detail* the feature/behavior/change you'd like to see.
+
+In both cases, be ready for followup questions, and please respond in a timely
+manner.  If we can't reproduce a bug or think a feature already exists, we
+might close your issue.  If we're wrong, PLEASE feel free to reopen it and
+explain why.
+-->
+
+**Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)**
+
+
+**What happened**:
+
+
+**What you expected to happen**:
+
+
+**How to reproduce it** (as minimally and precisely as possible):
+
+
+**Anything else we need to know**:

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,17 @@
+<!--  Thanks for sending a pull request!  Here are some tips for you:
+1. If you want *faster* PR reviews, read how: https://github.com/kubernetes/community/blob/master/contributors/devel/pull-requests.md#best-practices-for-faster-reviews
+-->
+
+**What this PR does / why we need it**:
+
+**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
+
+**Special notes for your reviewer**:
+
+**Release note**:
+<!--  Steps to write your release note:
+1. Use the release-note-* labels to set the release note state (if you have access)
+2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`.
+-->
+```release-note
+```

.gitignore

@@ -7,3 +7,5 @@ _input/
 test/user.env
 user.env
 test/acs-engine-test/acs-engine-test
+
+test/acs-engine-test/acs-engine-test.exe

CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# Contributing Guidelines
+
+The Microsoft acs-engine project accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted.
+
+## Contributor License Agreements
+
+We'd love to accept your patches! Before we can take them, we have to jump a
+couple of legal hurdles.
+
+The [Microsoft CLA](https://cla.microsoft.com/) must be signed by all contributors. Please fill out either the individual or corporate Contributor License Agreement (CLA). Once you are CLA'ed, we'll be able to accept your pull requests. Once you are CLA'ed, we'll be able to accept your pull requests.
+
+***NOTE***: Only original source code from you and other people that have
+signed the CLA can be accepted into the repository.
+
+
+## Support Channels
+
+This is an open source project and as such no formal support is available. However, like all good open source projects we do offer "best effort" support through github issues.
+
+GitHub issues:
+- ACS-Engine: https://github.com/Azure/acs-engine/issues - file issues and PRs related to ACS-Engine
+- ACS: https://github.com/Azure/acs/issues - file issues and PRs related to Azure Container Service
+
+Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of.
+
+## Milestones
+We use milestones to track progress of releases.
+
+For example, if the current version is `2.2.0` an issue/PR could fall in to one of 2 different active milestones:
+`2.2.1`, `2.3.0`.  If an issue pertains to a
+specific upcoming bug or minor release, it would go into `2.2.1` or `2.3.0`.
+
+A milestone (and hence release) is considered done when all outstanding issues/PRs have been closed or moved to another milestone.
+
+## Issues
+Issues are used as the primary method for tracking anything to do with the acs-engine project.
+
+### Issue Lifecycle
+The issue lifecycle is mainly driven by the core maintainers, but is good information for those
+contributing to acs-engine. All issue types follow the same general lifecycle. Differences are noted below.
+1. Issue creation
+2. Triage
+    - The maintainer in charge of triaging will apply the proper labels for the issue. This
+    includes labels for priority, type, and metadata (such as "orchestrator/k8s"). If additional
+    levels are needed in the future, we will add them.
+    - (If needed) Clean up the title to succinctly and clearly state the issue. Also ensure
+    that proposals are prefaced with "Proposal".
+    - Add the issue to the correct milestone. If any questions come up, don't worry about
+    adding the issue to a milestone until the questions are answered.
+    - We attempt to do this process at least once per work day.
+3. Discussion
+    - "Feature" and "Bug" issues should be connected to the PR that resolves it.
+    - Whoever is working on a "Feature" or "Bug" issue (whether a maintainer or someone from
+    the community), should either assign the issue to them self or make a comment in the issue
+    saying that they are taking it.
+    - "Proposal" and "Question" issues should stay open until resolved or if they have not been
+    active for more than 30 days. This will help keep the issue queue to a manageable size and
+    reduce noise. Should the issue need to stay open, the `keep open` label can be added.
+4. Issue closure
+
+## How to Contribute a Patch
+
+1. If you haven't already done so, sign a Contributor License Agreement (see details above).
+2. Fork the desired repo, develop and test your code changes.
+3. Submit a pull request.

Makefile

@@ -5,26 +5,37 @@
 VERSION=`git describe --always --long --dirty`
 BUILD=`date +%FT%T%z`
 
+# this isn't particularly pleasant, but it works with the least amount
+# of requirements around $GOPATH. The extra sed is needed because `gofmt`
+# operates on paths, go list returns package names, and `go fmt` always rewrites
+# which is not what we need to do in the `test_fmt` target.
+GOFILES=`go list ./... | grep -v "github.com/Azure/acs-engine/vendor" | sed 's|github.com/Azure/acs-engine|.|g' | grep -v -w '^.$$'`
+
+all: build
+
 prereqs:
+	go get github.com/Masterminds/glide
 	go get github.com/jteeuwen/go-bindata/...
+	glide install
 
-build: prereqs
-	go generate -v ./...
-	go get .
-	go build -v -ldflags="-X main.AcsEngineBuildSHA=${VERSION} -X main.AcsEngineBuildTime=${BUILD}"
+_build:
+	go generate -v $(GOFILES)
+	go build -v -ldflags="-X github.com/Azure/acs-engine/cmd.BuildSHA=${VERSION} -X github.com/Azure/acs-engine/cmd.BuildTime=${BUILD}"
 	cd test/acs-engine-test; go build -v
 
+build: prereqs _build
+
 test: prereqs test_fmt
-	go test -v ./...
+	go test -v $(GOFILES)
 
 test_fmt: prereqs
-	test -z "$$(gofmt -s -l . | tee /dev/stderr)"
+	test -z "$$(gofmt -s -l $(GOFILES) | tee /dev/stderr)"
 
 validate-generated: prereqs
 	./scripts/validate-generated.sh
 
 fmt:
-	gofmt -s -l -w .
+	gofmt -s -l -w $(GOFILES)
 
 lint: prereqs
 	go get -u github.com/golang/lint/golint

OWNERS

@@ -0,0 +1,4 @@
+maintainers:
+  - anhowe
+  - colemickens
+  - seanknox

README.md

@@ -48,7 +48,7 @@ $ vim examples/kubernetes.classic.json
 # insert your preferred, unique DNS prefix
 # insert your SSH public key
 
-$ ./acs-engine examples/kubernetes.classic.json
+$ ./acs-engine generate examples/kubernetes.classic.json
 ```
 
 This produces a new directory inside `_output/` that contains an ARM template

README_zh-CN.md

@@ -44,7 +44,7 @@ $ vim examples/kubernetes.classic.json
 # 修改默认的DNS prefix
 # 修改ssh public key
 
-$ ./acs-engine examples/kubernetes.classic.json
+$ ./acs-engine generate examples/kubernetes.classic.json
 ```
 
 This produces a new directory inside `_output/` that contains an ARM template