@bgrant0607 This is the implementation of the first step from #5207. It seems that there was a bug in #2097 in setPodHostTo method: pod.DesiredState was chanaged to Status instead of Spec (pkg/registry/etcd/etcd.go:190).

@jszczepkowski It wasn't a bug, it was a hack. The problem is that users can set Spec.Host, but the scheduler needs to post the binding in order for the pod to be added to BoundPods. The scheduler effectively watches status.host, so we need to continue to write that for now.
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/registry/pod/rest.go#L132

And:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/v1beta1/conversion.go#L1357

xref #5005

PTAL

LGTM. Did you run e2e?

This PR seems incorrect to me...

If you set the Host field in the PodSpec, the Host field in the pod status would never be updated because the binding was rejected prematurely (Spec.Host != "").

As a result, pod (status) cache will never check kubelet for the actual status (it relies on the Status.Host). The pod is hence stuck at pending forever. You can reproduce this issue by creating a pod with Spec.Host set to an non-empty string.

There are two ways to solve this issue:

• Do not reject the binding and update Status.Host
• Update pod_cache.go to check Spec.Host too.

@bgrant0607, which do you prefer?

rm pod_cache.go? Won't this be fixed by #5205?

Ok, good catch. I'd prefer to eliminate Status.Host from the internal representation, populate it from Spec.Host in the conversion code, remove it from v1beta3, and eliminate all other accesses to Status.Host in our own code?

Yes, #5205 might fix this, under the condition than kubelet is watching Spec.Host, not Status.Host. (I'm not sure which one it watches currently, or in the proposed PR).

Ideally we should do what you suggested. Given this is a bug introduced by this PR and it affects the use of Spec.Host, I'd like to either do a quick fix using one of the methods I suggested or just revert the PR.

How hard is it really to set Status.Host from Spec.Host?

If it is non-trivial, then I have no preference between your alternatives -- whatever is easiest. Regardless, it should be ripped out in O(days).

Somehow in my local e2e test, I'm getting pods with one of these fields set but not the other. Trying to figure out if it's a local change I made or if this broke things.

BTW the error message is super confusing now; it should %q the strings because the second one is blank for me.