k3s/pkg/api/types.go

527 lines
23 KiB
Go
Raw Normal View History

2014-06-06 23:40:48 +00:00
/*
Copyright 2014 Google Inc. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package api
import (
"github.com/GoogleCloudPlatform/kubernetes/pkg/api/common"
2014-07-13 04:46:01 +00:00
"github.com/GoogleCloudPlatform/kubernetes/pkg/util"
"github.com/GoogleCloudPlatform/kubernetes/pkg/watch"
"github.com/fsouza/go-dockerclient"
)
// Common string formats
// ---------------------
// Many fields in this API have formatting requirements. The commonly used
// formats are defined here.
//
// C_IDENTIFIER: This is a string that conforms the definition of an "identifier"
// in the C language. This is captured by the following regex:
// [A-Za-z_][A-Za-z0-9_]*
// This defines the format, but not the length restriction, which should be
// specified at the definition of any field of this type.
//
// DNS_LABEL: This is a string, no more than 63 characters long, that conforms
// to the definition of a "label" in RFCs 1035 and 1123. This is captured
// by the following regex:
// [a-z0-9]([-a-z0-9]*[a-z0-9])?
//
// DNS_SUBDOMAIN: This is a string, no more than 253 characters long, that conforms
// to the definition of a "subdomain" in RFCs 1035 and 1123. This is captured
// by the following regex:
// [a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*
// or more simply:
// DNS_LABEL(\.DNS_LABEL)*
2014-06-06 23:40:48 +00:00
// ContainerManifest corresponds to the Container Manifest format, documented at:
2014-06-12 00:10:10 +00:00
// https://developers.google.com/compute/docs/containers/container_vms#container_manifest
// This is used as the representation of Kubernetes workloads.
2014-06-06 23:40:48 +00:00
type ContainerManifest struct {
// Required: This must be a supported version string, such as "v1beta1".
Version string `yaml:"version" json:"version"`
// Required: This must be a DNS_SUBDOMAIN.
// TODO: ID on Manifest is deprecated and will be removed in the future.
ID string `yaml:"id" json:"id"`
2014-06-06 23:40:48 +00:00
Volumes []Volume `yaml:"volumes" json:"volumes"`
Containers []Container `yaml:"containers" json:"containers"`
}
// ContainerManifestList is used to communicate container manifests to kubelet.
type ContainerManifestList struct {
JSONBase `json:",inline" yaml:",inline"`
Items []ContainerManifest `json:"items,omitempty" yaml:"items,omitempty"`
}
2014-06-16 05:34:16 +00:00
// Volume represents a named volume in a pod that may be accessed by any containers in the pod.
2014-06-06 23:40:48 +00:00
type Volume struct {
// Required: This must be a DNS_LABEL. Each volume in a pod must have
// a unique name.
2014-06-06 23:40:48 +00:00
Name string `yaml:"name" json:"name"`
// Source represents the location and type of a volume to mount.
// This is optional for now. If not specified, the Volume is implied to be an EmptyDir.
// This implied behavior is deprecated and will be removed in a future version.
Source *VolumeSource `yaml:"source" json:"source"`
}
type VolumeSource struct {
// Only one of the following sources may be specified
// HostDirectory represents a pre-existing directory on the host machine that is directly
// exposed to the container. This is generally used for system agents or other privileged
// things that are allowed to see the host machine. Most containers will NOT need this.
// TODO(jonesdl) We need to restrict who can use host directory mounts and
// who can/can not mount host directories as read/write.
HostDirectory *HostDirectory `yaml:"hostDir" json:"hostDir"`
// EmptyDirectory represents a temporary directory that shares a pod's lifetime.
EmptyDirectory *EmptyDirectory `yaml:"emptyDir" json:"emptyDir"`
}
// HostDirectory represents bare host directory volume.
type HostDirectory struct {
Path string `yaml:"path" json:"path"`
2014-06-06 23:40:48 +00:00
}
type EmptyDirectory struct{}
// Port represents a network port in a single container.
2014-06-06 23:40:48 +00:00
type Port struct {
// Optional: If specified, this must be a DNS_LABEL. Each named port
// in a pod must have a unique name.
Name string `yaml:"name,omitempty" json:"name,omitempty"`
// Optional: If specified, this must be a valid port number, 0 < x < 65536.
HostPort int `yaml:"hostPort,omitempty" json:"hostPort,omitempty"`
// Required: This must be a valid port number, 0 < x < 65536.
ContainerPort int `yaml:"containerPort" json:"containerPort"`
// Optional: Defaults to "TCP".
Protocol string `yaml:"protocol,omitempty" json:"protocol,omitempty"`
// Optional: What host IP to bind the external port to.
HostIP string `yaml:"hostIP,omitempty" json:"hostIP,omitempty"`
2014-06-06 23:40:48 +00:00
}
// VolumeMount describes a mounting of a Volume within a container.
2014-06-06 23:40:48 +00:00
type VolumeMount struct {
// Required: This must match the Name of a Volume [above].
Name string `yaml:"name" json:"name"`
// Optional: Defaults to false (read-write).
ReadOnly bool `yaml:"readOnly,omitempty" json:"readOnly,omitempty"`
// Required.
2014-06-06 23:40:48 +00:00
MountPath string `yaml:"mountPath,omitempty" json:"mountPath,omitempty"`
}
// EnvVar represents an environment variable present in a Container.
2014-06-06 23:40:48 +00:00
type EnvVar struct {
// Required: This must be a C_IDENTIFIER.
Name string `yaml:"name" json:"name"`
// Optional: defaults to "".
2014-06-06 23:40:48 +00:00
Value string `yaml:"value,omitempty" json:"value,omitempty"`
}
2014-07-10 11:46:35 +00:00
// HTTPGetProbe describes a liveness probe based on HTTP Get requests.
2014-07-03 05:35:50 +00:00
type HTTPGetProbe struct {
// Optional: Path to access on the HTTP server.
2014-07-03 05:35:50 +00:00
Path string `yaml:"path,omitempty" json:"path,omitempty"`
// Required: Name or number of the port to access on the container.
Port util.IntOrString `yaml:"port,omitempty" json:"port,omitempty"`
// Optional: Host name to connect to, defaults to the pod IP.
2014-07-03 05:35:50 +00:00
Host string `yaml:"host,omitempty" json:"host,omitempty"`
}
// TCPSocketProbe describes a liveness probe based on opening a socket.
2014-08-01 00:35:54 +00:00
type TCPSocketProbe struct {
// Required: Port to connect to.
Port util.IntOrString `yaml:"port,omitempty" json:"port,omitempty"`
2014-08-01 00:35:54 +00:00
}
// ExecProbe describes a "run in container" health probe.
type ExecProbe struct {
// Command is the command line to execute inside the container, the working directory for the
// command is root ('/') in the container's filesystem. The command is simply exec'd, it is
// not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use
// a shell, you need to explicitly call out to that shell.
Command []string `yaml:"command,omitempty" json:"command,omitempty"`
}
2014-07-10 11:46:35 +00:00
// LivenessProbe describes a liveness probe to be examined to the container.
2014-07-03 05:35:50 +00:00
type LivenessProbe struct {
2014-08-01 00:35:54 +00:00
// Type of liveness probe. Current legal values "http", "tcp"
2014-07-03 05:35:50 +00:00
Type string `yaml:"type,omitempty" json:"type,omitempty"`
// HTTPGetProbe parameters, required if Type == 'http'
2014-07-09 23:53:31 +00:00
HTTPGet *HTTPGetProbe `yaml:"httpGet,omitempty" json:"httpGet,omitempty"`
2014-08-01 00:35:54 +00:00
// TCPSocketProbe parameter, required if Type == 'tcp'
TCPSocket *TCPSocketProbe `yaml:"tcpSocket,omitempty" json:"tcpSocket,omitempty"`
// ExecProbe parameter, required if Type == 'exec'
Exec *ExecProbe `yaml:"exec,omitempty" json:"exec,omitempty"`
2014-07-03 05:35:50 +00:00
// Length of time before health checking is activated. In seconds.
InitialDelaySeconds int64 `yaml:"initialDelaySeconds,omitempty" json:"initialDelaySeconds,omitempty"`
}
2014-06-06 23:40:48 +00:00
// Container represents a single container that is expected to be run on the host.
type Container struct {
// Required: This must be a DNS_LABEL. Each container in a pod must
// have a unique name.
Name string `yaml:"name" json:"name"`
// Required.
Image string `yaml:"image" json:"image"`
// Optional: Defaults to whatever is defined in the image.
Command []string `yaml:"command,omitempty" json:"command,omitempty"`
// Optional: Defaults to Docker's default.
WorkingDir string `yaml:"workingDir,omitempty" json:"workingDir,omitempty"`
Ports []Port `yaml:"ports,omitempty" json:"ports,omitempty"`
Env []EnvVar `yaml:"env,omitempty" json:"env,omitempty"`
// Optional: Defaults to unlimited.
Memory int `yaml:"memory,omitempty" json:"memory,omitempty"`
// Optional: Defaults to unlimited.
2014-07-09 23:53:31 +00:00
CPU int `yaml:"cpu,omitempty" json:"cpu,omitempty"`
VolumeMounts []VolumeMount `yaml:"volumeMounts,omitempty" json:"volumeMounts,omitempty"`
LivenessProbe *LivenessProbe `yaml:"livenessProbe,omitempty" json:"livenessProbe,omitempty"`
2014-06-06 23:40:48 +00:00
}
// Event is the representation of an event logged to etcd backends.
2014-06-06 23:40:48 +00:00
type Event struct {
Event string `json:"event,omitempty"`
Manifest *ContainerManifest `json:"manifest,omitempty"`
Container *Container `json:"container,omitempty"`
Timestamp int64 `json:"timestamp"`
}
// The below types are used by kube_client and api_server.
// JSONBase is shared by all objects sent to, or returned from the client.
2014-06-06 23:40:48 +00:00
type JSONBase struct {
Kind string `json:"kind,omitempty" yaml:"kind,omitempty"`
ID string `json:"id,omitempty" yaml:"id,omitempty"`
CreationTimestamp util.Time `json:"creationTimestamp,omitempty" yaml:"creationTimestamp,omitempty"`
SelfLink string `json:"selfLink,omitempty" yaml:"selfLink,omitempty"`
ResourceVersion uint64 `json:"resourceVersion,omitempty" yaml:"resourceVersion,omitempty"`
APIVersion string `json:"apiVersion,omitempty" yaml:"apiVersion,omitempty"`
2014-06-06 23:40:48 +00:00
}
2014-07-08 07:08:58 +00:00
// PodStatus represents a status of a pod.
type PodStatus string
2014-07-08 07:08:58 +00:00
// These are the valid statuses of pods.
const (
// PodWaiting means that we're waiting for the pod to begin running.
PodWaiting PodStatus = "Waiting"
// PodRunning means that the pod is up and running.
PodRunning PodStatus = "Running"
// PodTerminated means that the pod has stopped.
PodTerminated PodStatus = "Terminated"
)
// PodInfo contains one entry for every container with available info.
type PodInfo map[string]docker.Container
// RestartPolicyType represents a restart policy for a pod.
type RestartPolicyType string
// Valid restart policies defined for a PodState.RestartPolicy.
const (
RestartAlways RestartPolicyType = "RestartAlways"
RestartOnFailure RestartPolicyType = "RestartOnFailure"
RestartNever RestartPolicyType = "RestartNever"
)
type RestartPolicy struct {
// Optional: Defaults to "RestartAlways".
Type RestartPolicyType `yaml:"type,omitempty" json:"type,omitempty"`
}
// PodState is the state of a pod, used as either input (desired state) or output (current state).
2014-06-09 04:39:57 +00:00
type PodState struct {
2014-06-06 23:40:48 +00:00
Manifest ContainerManifest `json:"manifest,omitempty" yaml:"manifest,omitempty"`
Status PodStatus `json:"status,omitempty" yaml:"status,omitempty"`
2014-06-06 23:40:48 +00:00
Host string `json:"host,omitempty" yaml:"host,omitempty"`
HostIP string `json:"hostIP,omitempty" yaml:"hostIP,omitempty"`
PodIP string `json:"podIP,omitempty" yaml:"podIP,omitempty"`
// The key of this map is the *name* of the container within the manifest; it has one
// entry per container in the manifest. The value of this map is currently the output
// of `docker inspect`. This output format is *not* final and should not be relied
// upon.
// TODO: Make real decisions about what our info should look like. Re-enable fuzz test
// when we have done this.
Info PodInfo `json:"info,omitempty" yaml:"info,omitempty"`
RestartPolicy RestartPolicy `json:"restartpolicy,omitempty" yaml:"restartpolicy,omitempty"`
2014-06-06 23:40:48 +00:00
}
2014-07-08 07:08:58 +00:00
// PodList is a list of Pods.
2014-06-09 04:39:57 +00:00
type PodList struct {
2014-06-12 22:10:28 +00:00
JSONBase `json:",inline" yaml:",inline"`
Items []Pod `json:"items" yaml:"items,omitempty"`
2014-06-06 23:40:48 +00:00
}
// Pod is a collection of containers, used as either input (create, update) or as output (list, get).
type Pod struct {
2014-06-12 22:10:28 +00:00
JSONBase `json:",inline" yaml:",inline"`
2014-06-06 23:40:48 +00:00
Labels map[string]string `json:"labels,omitempty" yaml:"labels,omitempty"`
2014-06-09 04:39:57 +00:00
DesiredState PodState `json:"desiredState,omitempty" yaml:"desiredState,omitempty"`
CurrentState PodState `json:"currentState,omitempty" yaml:"currentState,omitempty"`
2014-06-06 23:40:48 +00:00
}
// ReplicationControllerState is the state of a replication controller, either input (create, update) or as output (list, get).
2014-06-06 23:40:48 +00:00
type ReplicationControllerState struct {
Replicas int `json:"replicas" yaml:"replicas"`
ReplicaSelector map[string]string `json:"replicaSelector,omitempty" yaml:"replicaSelector,omitempty"`
PodTemplate PodTemplate `json:"podTemplate,omitempty" yaml:"podTemplate,omitempty"`
2014-06-06 23:40:48 +00:00
}
2014-07-08 07:08:58 +00:00
// ReplicationControllerList is a collection of replication controllers.
2014-06-06 23:40:48 +00:00
type ReplicationControllerList struct {
2014-06-12 22:10:28 +00:00
JSONBase `json:",inline" yaml:",inline"`
Items []ReplicationController `json:"items,omitempty" yaml:"items,omitempty"`
2014-06-06 23:40:48 +00:00
}
// ReplicationController represents the configuration of a replication controller.
2014-06-06 23:40:48 +00:00
type ReplicationController struct {
2014-06-12 22:10:28 +00:00
JSONBase `json:",inline" yaml:",inline"`
2014-06-06 23:40:48 +00:00
DesiredState ReplicationControllerState `json:"desiredState,omitempty" yaml:"desiredState,omitempty"`
Labels map[string]string `json:"labels,omitempty" yaml:"labels,omitempty"`
}
// PodTemplate holds the information used for creating pods.
2014-06-09 04:39:57 +00:00
type PodTemplate struct {
DesiredState PodState `json:"desiredState,omitempty" yaml:"desiredState,omitempty"`
2014-06-06 23:40:48 +00:00
Labels map[string]string `json:"labels,omitempty" yaml:"labels,omitempty"`
}
// ServiceList holds a list of services.
2014-06-06 23:40:48 +00:00
type ServiceList struct {
2014-06-12 22:10:28 +00:00
JSONBase `json:",inline" yaml:",inline"`
Items []Service `json:"items" yaml:"items"`
2014-06-06 23:40:48 +00:00
}
2014-07-08 07:08:58 +00:00
// Service is a named abstraction of software service (for example, mysql) consisting of local port
// (for example 3306) that the proxy listens on, and the selector that determines which pods
// will answer requests sent through the proxy.
2014-06-06 23:40:48 +00:00
type Service struct {
JSONBase `json:",inline" yaml:",inline"`
Port int `json:"port,omitempty" yaml:"port,omitempty"`
// This service's labels.
Labels map[string]string `json:"labels,omitempty" yaml:"labels,omitempty"`
// This service will route traffic to pods having labels matching this selector.
Selector map[string]string `json:"selector,omitempty" yaml:"selector,omitempty"`
CreateExternalLoadBalancer bool `json:"createExternalLoadBalancer,omitempty" yaml:"createExternalLoadBalancer,omitempty"`
2014-07-13 04:46:01 +00:00
// ContainerPort is the name of the port on the container to direct traffic to.
// Optional, if unspecified use the first port on the container.
2014-07-13 04:46:01 +00:00
ContainerPort util.IntOrString `json:"containerPort,omitempty" yaml:"containerPort,omitempty"`
2014-06-06 23:40:48 +00:00
}
2014-07-08 07:08:58 +00:00
// Endpoints is a collection of endpoints that implement the actual service, for example:
2014-06-06 23:40:48 +00:00
// Name: "mysql", Endpoints: ["10.10.1.1:1909", "10.10.2.2:8834"]
type Endpoints struct {
JSONBase `json:",inline" yaml:",inline"`
Endpoints []string `json:"endpoints,omitempty" yaml:"endpoints,omitempty"`
2014-06-06 23:40:48 +00:00
}
2014-06-20 23:50:56 +00:00
2014-07-08 07:08:58 +00:00
// Minion is a worker node in Kubernetenes.
// The name of the minion according to etcd is in JSONBase.ID.
type Minion struct {
JSONBase `json:",inline" yaml:",inline"`
// Queried from cloud provider, if available.
HostIP string `json:"hostIP,omitempty" yaml:"hostIP,omitempty"`
}
2014-07-08 07:08:58 +00:00
// MinionList is a list of minions.
type MinionList struct {
JSONBase `json:",inline" yaml:",inline"`
2014-08-29 02:39:42 +00:00
Items []Minion `json:"items,omitempty" yaml:"items,omitempty"`
}
// Binding is written by a scheduler to cause a pod to be bound to a host.
type Binding struct {
JSONBase `json:",inline" yaml:",inline"`
PodID string `json:"podID" yaml:"podID"`
Host string `json:"host" yaml:"host"`
}
2014-06-20 23:50:56 +00:00
// Status is a return value for calls that don't return other objects.
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// TODO: this could go in apiserver, but I'm including it here so clients needn't
2014-06-20 23:50:56 +00:00
// import both.
type Status struct {
JSONBase `json:",inline" yaml:",inline"`
// One of: "success", "failure", "working" (for operations not yet completed)
Status string `json:"status,omitempty" yaml:"status,omitempty"`
// A human-readable description of the status of this operation.
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
Message string `json:"message,omitempty" yaml:"message,omitempty"`
// A machine-readable description of why this operation is in the
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// "failure" or "working" status. If this value is empty there
// is no information available. A Reason clarifies an HTTP status
// code but does not override it.
Reason StatusReason `json:"reason,omitempty" yaml:"reason,omitempty"`
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// Extended data associated with the reason. Each reason may define its
// own extended details. This field is optional and the data returned
// is not guaranteed to conform to any schema except that defined by
// the reason type.
Details *StatusDetails `json:"details,omitempty" yaml:"details,omitempty"`
// Suggested HTTP return code for this status, 0 if not set.
Code int `json:"code,omitempty" yaml:"code,omitempty"`
2014-06-20 23:50:56 +00:00
}
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// StatusDetails is a set of additional properties that MAY be set by the
// server to provide additional information about a response. The Reason
// field of a Status object defines what attributes will be set. Clients
// must ignore fields that do not match the defined type of each attribute,
// and should assume that any attribute may be empty, invalid, or under
// defined.
type StatusDetails struct {
// The ID attribute of the resource associated with the status StatusReason
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// (when there is a single ID which can be described).
ID string `json:"id,omitempty" yaml:"id,omitempty"`
// The kind attribute of the resource associated with the status StatusReason.
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// On some operations may differ from the requested resource Kind.
Kind string `json:"kind,omitempty" yaml:"kind,omitempty"`
// The Causes array includes more details associated with the StatusReason
// failure. Not all StatusReasons may provide detailed causes.
Causes []StatusCause `json:"causes,omitempty" yaml:"causes,omitempty"`
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
}
2014-06-20 23:50:56 +00:00
// Values of Status.Status
const (
StatusSuccess = "success"
StatusFailure = "failure"
StatusWorking = "working"
)
// StatusReason is an enumeration of possible failure causes. Each StatusReason
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// must map to a single HTTP status code, but multiple reasons may map
// to the same HTTP status code.
// TODO: move to apiserver
type StatusReason string
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
const (
// StatusReasonUnknown means the server has declined to indicate a specific reason.
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// The details field may contain other information about this error.
// Status code 500.
StatusReasonUnknown StatusReason = ""
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// StatusReasonWorking means the server is processing this request and will complete
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// at a future time.
// Details (optional):
// "kind" string - the name of the resource being referenced ("operation" today)
// "id" string - the identifier of the Operation resource where updates
// will be returned
// Headers (optional):
// "Location" - HTTP header populated with a URL that can retrieved the final
// status of this operation.
// Status code 202
StatusReasonWorking StatusReason = "working"
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// StatusReasonNotFound means one or more resources required for this operation
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// could not be found.
// Details (optional):
// "kind" string - the kind attribute of the missing resource
// on some operations may differ from the requested
// resource.
// "id" string - the identifier of the missing resource
// Status code 404
StatusReasonNotFound StatusReason = "not_found"
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// StatusReasonAlreadyExists means the resource you are creating already exists.
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// Details (optional):
// "kind" string - the kind attribute of the conflicting resource
// "id" string - the identifier of the conflicting resource
// Status code 409
StatusReasonAlreadyExists StatusReason = "already_exists"
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// StatusReasonConflict means the requested update operation cannot be completed
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
// due to a conflict in the operation. The client may need to alter the request.
// Each resource may define custom details that indicate the nature of the
// conflict.
// Status code 409
StatusReasonConflict StatusReason = "conflict"
// StatusReasonInvalid means the requested create or update operation cannot be
// completed due to invalid data provided as part of the request. The client may
// need to alter the request. When set, the client may use the StatusDetails
// message field as a summary of the issues encountered.
// Details (optional):
// "kind" string - the kind attribute of the invalid resource
// "id" string - the identifier of the invalid resource
// "causes" - one or more StatusCause entries indicating the data in the
// provided resource that was invalid. The code, message, and
// field attributes will be set.
// Status code 422
StatusReasonInvalid StatusReason = "invalid"
)
// StatusCause provides more information about an api.Status failure, including
// cases when multiple errors are encountered.
type StatusCause struct {
// A machine-readable description of the cause of the error. If this value is
// empty there is no information available.
Type CauseType `json:"reason,omitempty" yaml:"reason,omitempty"`
// A human-readable description of the cause of the error. This field may be
// presented as-is to a reader.
Message string `json:"message,omitempty" yaml:"message,omitempty"`
// The field of the resource that has caused this error, as named by its JSON
// serialization. May include dot and postfix notation for nested attributes.
// Arrays are zero-indexed. Fields may appear more than once in an array of
// causes due to fields having multiple errors.
// Optional.
//
// Examples:
// "name" - the field "name" on the current resource
// "items[0].name" - the field "name" on the first array entry in "items"
Field string `json:"field,omitempty" yaml:"field,omitempty"`
}
// CauseType is a machine readable value providing more detail about what
// occured in a status response. An operation may have multiple causes for a
// status (whether failure, success, or working).
type CauseType string
const (
// CauseTypeFieldValueNotFound is used to report failure to find a requested value
// (e.g. looking up an ID).
CauseTypeFieldValueNotFound CauseType = "fieldValueNotFound"
// CauseTypeFieldValueInvalid is used to report required values that are not
// provided (e.g. empty strings, null values, or empty arrays).
CauseTypeFieldValueRequired CauseType = "fieldValueRequired"
// CauseTypeFieldValueDuplicate is used to report collisions of values that must be
// unique (e.g. unique IDs).
CauseTypeFieldValueDuplicate CauseType = "fieldValueDuplicate"
// CauseTypeFieldValueInvalid is used to report malformed values (e.g. failed regex
// match).
CauseTypeFieldValueInvalid CauseType = "fieldValueInvalid"
// CauseTypeFieldValueNotSupported is used to report valid (as per formatting rules)
// values that can not be handled (e.g. an enumerated string).
CauseTypeFieldValueNotSupported CauseType = "fieldValueNotSupported"
Evolve the api.Status object with Reason/Details 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
2014-07-31 18:12:26 +00:00
)
2014-07-08 07:08:58 +00:00
// ServerOp is an operation delivered to API clients.
type ServerOp struct {
JSONBase `yaml:",inline" json:",inline"`
}
2014-07-08 07:08:58 +00:00
// ServerOpList is a list of operations, as delivered to API clients.
type ServerOpList struct {
JSONBase `yaml:",inline" json:",inline"`
Items []ServerOp `yaml:"items,omitempty" json:"items,omitempty"`
}
// WatchEvent objects are streamed from the api server in response to a watch request.
type WatchEvent struct {
// The type of the watch event; added, modified, or deleted.
Type watch.EventType
// For added or modified objects, this is the new object; for deleted objects,
// it's the state of the object immediately prior to its deletion.
Object common.Object
}