Renamed: logging.md -> devel/logging.m
Renamed: access.md -> design/access.md
Renamed: identifiers.md -> design/identifiers.md
Renamed: labels.md -> design/labels.md
Renamed: namespaces.md -> design/namespaces.md
Renamed: security.md -> design/security.md
Renamed: networking.md -> design/networking.md
Added abbreviated user user-focused document in place of most moved docs.
Added docs/README.md explains how docs are organized.
Added short, user-oriented documentation on labels
Added a glossary.
Fixed up some links.
The example systemd services files, environment files, and the fedora
manual config doc all used numerous references to minion_. Many of
these are better named kubelet_. Convert them.
The pods.md document was referring to the networking.md document, and
was including the docs/ prefix, which led to a 404 due to the link being
https://$host/docs/docs/networking.md. Removing the docs/ prefix gets
the link working again.
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>
While the linux dependency is obvious with a moment's thought, some
users (especially on *nix) might plow ahead before realizing their
system isn't supported. This adds a requirements section and points
users in the direction of guides more likely to work for them.
Building kubecfg is required for kubecfg.sh. kubecfg.sh will warn
of this if it hasn't been built, but it's a better user experience
to make people explicitly aware of all required steps.
The project README is getting quite large mainly because of all
the getting started guides embedded in the README.
Create the docs/getting-started-guides directory and relocate all
getting started guides. Update the README to link to each getting
started guide.
As I read through it I wanted to wordsmith a bit, which lead to reordering
some to read sort of top-down. There were a couple things I thought were wrong
(pod name should be a subdomain) and a few things I think we can make more
concise. I also added examples and clarified implications.