Log hostname/actual IP for instances request ignition files on first boot

[michaelgugino]

A recurring problem the MAO has is a machine is provisioned, but never joins the cluster. Invariably, this is blamed on the machine-api due to lack of understanding how ignition and MCS/MCO works.

We need to track the hostname and/or private-ip address of machines that request the first boot ignition file so we can identify where a failure has occurred. The MCS currently logs IP addresses it sees from the http connection level, but this information is usually a VIP or a NAT and not useful. The actual hostname and/or private-ip should be captured in either the http headers or the request payload, and we should track these requests in a way they can be easily associated with a particular machine object. Machine objects know via the cloud providers what the hostname and/or ip addresses of an instance will be, so having the MCS report this information somewhere useful will allow us to build tooling to help diagnose cluster-joining problems easier.

[runcom]

The actual hostname and/or private-ip should be captured in either the http headers or the request payload, and we should track these requests in a way they can be easily associated with a particular machine object. Machine objects know via the cloud providers what the hostname and/or ip addresses of an instance will be, so having the MCS report this information somewhere useful will allow us to build tooling to help diagnose cluster-joining problems easier.

sounds good to me - we can work together on this as it seems the above is missing from the MachineAPI implementation right? or can we go ahead and check the headers we get in the MCS already?

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.