Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Can I get a look at this, please? cc @dchen1107 @vishh @mikedanese

What is the use case?

@vishh our (coreos) personal use case is that, due to lack of kubelet checkpointing, we're working on a (temporary solution) "user-space" checkpointing system to checkpoint the apiserver pod manifest in a self-hosted cluster. This is so that if the system ever reboots/crashes we have a "checkpointed" apiserver manifest that we expose as a static manifest on disk that the kubelet can pick up and run. From there the cluster can heal itself.

That static manifest makes use of the downward API for the IP address. When the pod is using host networking, the kubelet looks in the node store for the IP. That store is filled from the API server exclusively. In that scenario, there is no API server for the kubelet to talk to to get this information, so the value is the empty string.

The information should be available regardless of if the node can reach the API server. It is local information, after all, so we shouldn't have to rely on contacting an API server to retrieve it. In this patch, I simply pre-fill the cache store with the node information.

@derekparker #27107 does something similar. Does that satisfy your use case?

@derekparker is out of office this week

@vishh I tested #27303 and it doesn't resolve this issue.

Repro is adding a simple api pod manifest with hostNetwork: true to a static-pod dir, then starting a kubelet which can't contact an api-server. Example pod:

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  hostNetwork: true
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "$(MY_POD_IP)" ]
      env:
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: MY_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
  restartPolicy: Never

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message may repeat a few times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

Otherwise, if this message is too spammy, please complain to ixdy.

Fwiw, I opened an alternative PR here: #27508

@derekparker PR needs rebase

@derekparker @aaronlevy Can we close this PR in favor of #27508 ?

@vishh I'm fine with that.