This is some cleanup that has been needed for a while.
There's still one more step that could usefully be done, which is to
split up our api package into the part that provides the helper
functions and the part that provides the internal types. That can come
later.
The v1beta1 package is now a good example of what an api plugin should
do to version its types.
Convert host:port and URLs passed to client.New() into the proper
values, and return an error if the value is invalid. Change CLI
to return an error if -master is invalid. Remove Client.rawRequest
which was not in use, and fix the involved tests. Add NewOrDie
Preserves the behavior of the client to not auth when a non-https
URL is passed (although in the future this should be corrected).
Contains breaking API change on api.Status#Details (type change)
Turn Details from string -> StatusDetails - a general
bucket for keyed error behavior. Define an open enumeration
ReasonType exposed as Reason on the status object to provide
machine readable subcategorization beyond HTTP Status Code. Define
a human readable field Message which is common convention (previously
this was joined into Details).
Precedence order: HTTP Status Code, Reason, Details. apiserver would
impose restraints on the ReasonTypes defined by the main apiobject,
and ensure their use is consistent.
There are four long term scenarios this change supports:
1. Allow a client access to a machine readable field that can be
easily switched on for improving or translating the generic
server Message.
2. Return a 404 when a composite operation on multiple resources
fails with enough data so that a client can distinguish which
item does not exist. E.g. resource Parent and resource Child,
POST /parents/1/children to create a new Child, but /parents/1
is deleted. POST returns 404, ReasonTypeNotFound, and
Details.ID = "1", Details.Kind = "parent"
3. Allow a client to receive validation data that is keyed by
attribute for building user facing UIs around field submission.
Validation is usually expressed as map[string][]string, but
that type is less appropriate for many other uses.
4. Allow specific API errors to return more granular failure status
for specific operations. An example might be a minion proxy,
where the operation that failed may be both proxying OR the
minion itself. In this case a reason may be defined "proxy_failed"
corresponding to 502, where the Details field may be extended
to contain a nested error object.
At this time only ID and Kind are exposed
We're not exercising anything TLS related in client and request,
set these back to NewServer. Should add a new TLS end-to-end
test for hack/test-cmd.sh with real (test) certs.
Improve apiserver/logger.go's interface (it's pretty cool now).
Improve apiserver's error reporting to clients.
Improve client's handling of errors from apiserver.
Make failed PUTs return 409 (conflict)-- http status codes are amazingly
well defined for what we're doing!
1) imported glog to third_party (previous commit)
2) add support for third_party/update.sh to update just one pkg
3) search-and-replace:
s/log.Printf/glog.Infof/
s/log.Print/glog.Info/
s/log.Fatalf/glog.Fatalf/
s/log.Fatal/glog.Fatal/
4) convert glog.Info.*, err into glog.Error*
Adds some util interfaces to logging and calls them from each cmd, which
will set the default log output to write to glog. Pass glog-wrapped
Loggers to etcd for logging.
Log files will go to /tmp - we should probably follow this up with a
default log dir for each cmd.
The glog lib is sort of weak in that it only flushes every 30 seconds, so
we spin up our own flushing goroutine.