This commit addresses issue #1571, which requests that all internal
Kubernetes links are swapped to relative ones to better facilitate
browsing of documentation on local forks, not to mention make the
documentation have less needless boilerplate.
* Separate metadata from objects
* Treat lists differently from resources
* Add UID and Annotations on Metadata
* Introduce BoundPod(s) as distinct from Pod to represent pods
scheduled onto a host
* Use "spec" instead of "state" and "status" instead of "currentState"
* Identify current status of objects consistently
* Use "condition" as the string label for substatus
* All string constants should be PublicGoCapitalized
* Rename Minion -> Node
* Rename ServerOp -> Operation
* Remove ContainerManifest
* Add api-conventions.md document
* Replace PodTemplateSpec in ReplCtrl with ObjectReference
Move a lot of common error logging into better buckets:
glog.Errorf() - Always an error
glog.Warningf() - Something unexpected, but probably not an error
glog.V(0) - Generally useful for this to ALWAYS be visible
to an operator
* Programmer errors
* Logging extra info about a panic
* CLI argument handling
glog.V(1) - A reasonable default log level if you don't want
verbosity
* Information about config (listening on X, watching Y)
* Errors that repeat frequently that relate to conditions
that can be corrected (pod detected as unhealthy)
glog.V(2) - Useful steady state information about the service
* Logging HTTP requests and their exit code
* System state changing (killing pod)
* Controller state change events (starting pods)
* Scheduler log messages
glog.V(3) - Extended information about changes
* More info about system state changes
glog.V(4) - Debug level verbosity (for now)
* Logging in particularly thorny parts of code where
you may want to come back later and check it
I skip using `go get` as it downloads all of the dependencies. But since we are vendoring using godep without rewriting imports, this means we download a bunch of stuff we don't use. Instead, just clone the repo directly.
Fixes#1360.
v2: Resolve issues from comments, fix bugs in update-demo example, rename files for clarity, add turn-down steps.
v3: Add more set commands, clean up rest of env var checks.
This documentation covers the proposed release process that will improve
support for versioning builds from tarball.
There's also a diagram to explain how versioning works in face of other
commits being merged in parallel and the quirks of intermediate versions
close to the release window.
Addresses Issue #1226.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
We took a hard look at 1.0 and what things ae really REQUIRED to get to a
stable release that is "useful". This required moving some things we thought
were really important but not CRITICAL down the list.
For now they are stricken from this doc, but I expect this doc to start
growing a "post 1.0" list soon.
Things stricken and why:
Using the host network: This is primarily a performance optimization, but it
causes potential problems with other uses of HostPorts. We'd rather focus on
fixing perf problems than dodging them. We can revisit later if there is a
strong case for it.
Representation of Ports in the Manifest structure: We discussed and decided
that, since HostPort semantics have changed, this matters less than before.
Scenarios where IP-per-pod is hard or impossible: We're still game to help
people figure out how to make it work, but we don't see a case for making k8s
1.0 work in a fundamentally different mode. Too much churn and risk. We can
revisit later, if needed.
Auto-scaling controller: We really want this, but it's not critical to making
k8s "useful".
Pluggable authentication: Overlaps with the other identity topic. Having one
topic seems clearer.
Pod spreading: We still want this, but it's not critical for 1.0.
Container status snippets: We still want this, but it's not critical for 1.0.
Docker-daemon-kills-all-children-on-exit problem: This is still a big problem,
but we're not going to gate our 1.0 on something we don't control. This has
to be documented as a shortcoming in general.
Interconnection of services: expand / decompose the service pattern: overlaps
with the other services topic.
Recipes for settings where networking is not like GCE: This is happening in
the form of cloudprovider modules, but is not going to gate 1.0.
Instead of using `godep path`, we can simply set the GOPATH directly to
point to the Godeps/_workspace. We can still use `godep` to manage the
dependencies on the Godeps/ tree, but we don't need to have it available
for straight builds from git.
v2: Rebased and moved to inside kube::setup_go_environment() function.
Tested:
- Built it without godep in $PATH:
$ hack/build-go.sh
- Ran unit tests without godep in $PATH:
$ hack/test-go.sh
- Retested after rebase.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>