Issue 1:
Forked from #1007 and #1325 .

We want to support management of services via declarative configuration.

The configuration files written by the user may need to undergo multiple transformations before submitting them to the API, as discussed in #1694, but the result of these steps should be concrete objects. These objects may need to be created, updated, and/or deleted.

On an object-by-object basis, it should be possible via kubectl (via a client library) to do the following:

Determine whether or not the specified object already exists

Get the specified object

Create the specified object

Diff the specified object with an existing object in apiserver

Update an existing object in apiserver with the data from the specified object

Delete the specified object

Delete all objects with deployment-specific labels (see #1698)

The configured fields should be recorded in the object via annotations, as discussed in #1178 and #1201. Only the previously and newly configured fields, labels, and annotations should be diff'ed and/or updated. Other fields from the existing object should be ignored/merged, and the set of configured fields should be updated with each update.

We ultimately do want to automate most of the orchestration/workflow involved in deployment. However, this is fairly complex, and we can't necessarily automate all of it in a domain-independent, use-case-independent manner. In general, a full deployment would likely be comprised of multiple files, each containing multiple objects. These objects may have inter-dependencies (e.g., right now services must be created before their clients are created), rolling updates require special treatment (#1353), and application-specific rollout logic may be required. Therefore, I recommend we keep the more general deployment workflow separate from the basic primitive mechanism that reconciles a single object, and ensure that the two are composable. I'll file another issue for the workflow part.

Among other things, composition means that the invoker of the tool and/or library needs to be able to distinguish noop (e.g., object already exists and matches config), success, retryable failure, and permanent failure, so the overall workflow can decide what to do after each step.

/cc @ghodss

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): no

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): testing.md README.md

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version): NA

Environment: NA

Cloud provider or hardware configuration:

OS (e.g. from /etc/os-release):

Kernel (e.g. uname -a):

Install tools:

Others:

What happened: I visited https://github.com/kubernetes/kubernetes/blob/master/docs/devel/README.md and did not find much about testing.

What you expected to happen: I expected more information. A link to https://github.com/kubernetes/kubernetes/blob/master/docs/devel/testing.md would have been great.

How to reproduce it (as minimally and precisely as possible): Visit https://github.com/kubernetes/kubernetes/blob/master/docs/devel/README.md and try to learn all about testing Kubernetes.

Anything else do we need to know: