Pod status rule is misleading about pod-reaper HOT 3 OPEN

I was wondering if/when this would ever come back to bite me... #37
Long story short... "status" as listed by kubectl isn't either pod-phase or reason... it's actually something different... something not addressed directly in the the API from what I saw.

I suspect that Running isn't actually a "pod status" but actually a "container status". I 100% agree, it's confusing as hell!

// ContainerState holds a possible state of container.
// Only one of its members may be specified.
// If none of them is specified, the default one is ContainerStateWaiting.
type ContainerState struct {
	// Details about a waiting container
	// +optional
	Waiting *ContainerStateWaiting `json:"waiting,omitempty" protobuf:"bytes,1,opt,name=waiting"`
	// Details about a running container
	// +optional
	Running *ContainerStateRunning `json:"running,omitempty" protobuf:"bytes,2,opt,name=running"`
	// Details about a terminated container
	// +optional
	Terminated *ContainerStateTerminated `json:"terminated,omitempty" protobuf:"bytes,3,opt,name=terminated"`
}

There isn't anything that detects "Running" container state right now, and I think changing the "container status" rule would probably would result in behavior that isn't intended (I think changing the already existing rule would result in the pod being flagged for reaping if ANY of the containers in it were "Running" -- like it currently identifies if ANY container in the pod is "terminated" or "waiting"... uhg...

from pod-reaper.

Perhaps the way forward is

1. Rename current pod_status rule to pod_status_reason, and change the environment variable to POD_STATUS_REASON
2. Add pod_status_phase rule with environment variable POD_STATUS_PHASE

from pod-reaper.