* 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
Currently HttpLog only expected status range - this logs errors
that come back from a REST storage object without being first
converted to something in pkg/api/errors. This usually indicates
unexpected error conditions that a programmer didn't explicitly
check for - the kinds of problems that may need debugging by
an operator later. Set to V(1) because they don't impair normal
operation.
This includes 3 changes:
1) Use the Service.Protocol field, rather than hardcoding TCP.
2) Use Service.Port rather than ContainerPort - ContainerPort can be a string
and has absolutely no meaning to consumers.
3) Beef up tests for these env vars.
