Rename Event.Status to Event.Condition to match v1beta3 agreement

Question - should this be a phase?  Seems like no, since phase implies
defined lifecycle and this field is explicitly not defined.
This commit is contained in:
Clayton Coleman
2014-12-12 16:27:25 -05:00
parent 61e8baeef9
commit 88715cc6ef
14 changed files with 133 additions and 60 deletions

View File

@@ -953,18 +953,18 @@ type Event struct {
// Required. The object that this event is about.
InvolvedObject ObjectReference `json:"involvedObject,omitempty"`
// Should be a short, machine understandable string that describes the current status
// Should be a short, machine understandable string that describes the current condition
// of the referred object. This should not give the reason for being in this state.
// Examples: "running", "cantStart", "cantSchedule", "deleted".
// It's OK for components to make up statuses to report here, but the same string should
// always be used for the same status.
// Examples: "Running", "CantStart", "CantSchedule", "Deleted".
// It's OK for components to make up conditions to report here, but the same string should
// always be used for the same conditions.
// TODO: define a way of making sure these are consistent and don't collide.
// TODO: provide exact specification for format.
Status string `json:"status,omitempty"`
Condition string `json:"condition,omitempty"`
// Optional; this should be a short, machine understandable string that gives the reason
// for the transition into the object's current status. For example, if ObjectStatus is
// "cantStart", StatusReason might be "imageNotFound".
// for the transition into the object's current condition. For example, if ObjectCondition is
// "CantStart", StatusReason might be "ImageNotFound".
// TODO: provide exact specification for format.
Reason string `json:"reason,omitempty"`