@jainvipin Thanks for writing this!

I'd much prefer that we bring this stuff into the kubernetes repo instead of referring to an external repo. We'll then be able to both (a) keep it up to date as things change and (b) distribute it as part of our binary install packages.

At the very least, we shouldn't have binaries checked in to github but instead point users at our official binary releases.

Most of our install guides are in the form of:

• Get or build a binary release (https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/binary_release.md)
• Run some scripts/follow some instructions based on things in the stuff that is built.

Is this something you'd be willing to take on?

@jbeda: what you suggest makes sense; I I wasn't sure about things so I let it go for now. Let me update the PR and put all the scripts in kubernetes guides dirs and keep all scripts in there natively.

Building an "official-ish" release tar is pretty easy. Just do a make release (or make quick-release to skip the unit/integration tests). the tar will get dropped in _output/release-tars/kubernetes.tar.gz. The unpacked staging area for that tar is _output/release-stage/full/kubernetes/.

@jainvipin Nice work, I have a couple comments. First the upstart scripts are very nice to have versioned with the project. We have systemd configs but nothing for upstart yet. Second, without network setup included in the guide it feels very similar to the getting started locally guide. Have you tried including networking config into the guide so this could be an ubuntu-cluster getting started guide? Third, after the setup is complete, rather than going into usage specifics, you could refer users to the Kubernetes 101. This separates doc concerns and that doc is more likely to be maintained with new kubernetes releases whereas the setup guides might not change as much.

@jbeda: yes 'make release' is a simple way; I was using 'hack/build-go.sh to get the binaries; thanks for the hint.

I have another question on the directory structure and preference for the docs: 'docs' and 'getting-started-guides' directories contains only '.md' files, What is the best place to keep the ubuntu upstart scripts for the basic config? Would it be best keeping them inline in the doc? Or, put them as checked in files some directory (if so what is the best place to keep those files)?

I will update the PR after your response.

@mikedanese: thanks for your suggestions. Some comments and for my clarification:
First comment: can you please elaborate what you mean by checking version? Do you mean checking kubernetes version to ensure compatibility in the upstart scripts?
Second comment: Yes it looks similar except that when someone wants to try it like that it wouldn't work (the intent is the same, of course!) - so I felt that the need for ubuntu lanuch should be separate. Regarding showing setting up ubuntu cluster, is it okay if I do it after I am done updating the single-host part and incorporate jbeda's comments?
I will incorporate third comment i.e. refer to kubernetes-101.

Okay great. When I said versioned, I meant versioned in git. So if I wanted an upstart script for kubernetes v0.4 or v0.6 I could checkout that git tag and there would be a set of upstart scripts that would work for me. This PR will satisfy that.

If you put the scripts under cluster/ubuntu/... they'll automatically get bundled up with the full release builds. That way the scripts, binaries and instructions will all be grabbed together.

@jbeda: done; hopefully this one looks cleaner; binary check-ins was a bad idea :-)

Some nits, but looks good to me!

also took care of backquotes in the doc; please let me know if you want me to squash my changes into one diff.

Shoot! One more thing that I forgot. Do you mind adding yourself to MAINTAINERS.md? That way we'll know who to reach out to if this breaks and such. You can help folks using this out.

Also, can you rebase/squash these? I can help if you haven't done that with git before.

@jbeda - done with all; let me know if something is amiss

Very nice work. Thank you! Merging now.