Bug 1809345: Add the machine's name as a known NodeInternalDNS #88
Conversation
GCP platform provides search paths to resolve the virtual machine names by default. see https://cloud.google.com/compute/docs/internal-dns#resolv.conf this also allows nodes in clusters to have node-names matching the virtual machine name instead of the fqdn be because fqdn is too long for RHCOS to accept as hostname by default
abhinavdahiya
changed the title
|
@abhinavdahiya: This pull request references Bugzilla bug 1809345, which is valid. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
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. |
openshift-ci-robot
added
bugzilla/severity-high
| // provides search paths to resolve those. | ||
| // https://cloud.google.com/compute/docs/internal-dns#resolv.conf | ||
| nodeAddresses = append(nodeAddresses, corev1.NodeAddress{ | ||
| Type: corev1.NodeInternalDNS, |
There was a problem hiding this comment.
do we need to also include this as NodeHostName?
There was a problem hiding this comment.
Not really, this VM name is resolvable internal DNS name for the machine on GCP. We can't say what the hostname will be.
|
Related PR for ref openshift/machine-config-operator#1711 |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: enxebre The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
|
My only concern here is that the kubelet might be getting node name from the cloud provider (eg, metadata) rather than the output of 'hostname'. Though, worst case here we have an extra name appended to the machine-object that has no effect. |
|
@michaelgugino well what the kubelet can pick a nodename based on various factors, but this change only adds the VM name as one of the internal DNS which is true orthogonal to nodename, kubelet based on https://cloud.google.com/compute/docs/internal-dns#resolv.conf So on GCP, the kubelet uses the os hostname as node-name. And that can also be change by a flag on kubelet. |
|
I have limited understanding of the dynamics at play. However, in light of openshift/machine-config-operator#1711 this makes sense; 1711 provides for a truncated host name which will be used when the FQDN exceeds 63 characters. /lgtm |
|
@abhinavdahiya: All pull requests linked via external trackers have merged: openshift/cluster-api-provider-gcp#88, openshift/machine-config-operator#1711. Bugzilla bug 1809345 has been moved to the MODIFIED state. In response to this:
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. |
|
/cherry-pick release-4.4 |
|
@abhinavdahiya: new pull request created: #91 In response to this:
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. |
|
/cherry-pick release-4.3 |
|
@abhinavdahiya: new pull request created: #92 In response to this:
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. |
The infra id of the clusters on GCP was reduced to 12 in openshift#2088 because we couldn't handle the hostname seen by rhcos machine to be greater than 64. More details on this are available in https://bugzilla.redhat.com/show_bug.cgi?id=1809345 now since BZ 1809345 is fixed by openshift/machine-config-operator#1711 and openshift/cluster-api-provider-gcp#88 the installer can relax the restriction on the infra-id to match the other platforms. Why is it important? On GCP all resources are prefixed with infra-id, which currently is 12 chars with 6 chars used by random bit, leaving only 6 chars from cluster name. This causes trouble associating the cluster to jobs in CI as most of the identifyable characters are dropped from the resource names in CI due to this restriction. Also because of the previous restriction, only one char are used from pool's name, making is higly likely to collide in cases there are more.
The infra id of the clusters on GCP was reduced to 12 in openshift#2088 because we couldn't handle the hostname seen by rhcos machine to be greater than 64. More details on this are available in https://bugzilla.redhat.com/show_bug.cgi?id=1809345 now since BZ 1809345 is fixed by openshift/machine-config-operator#1711 and openshift/cluster-api-provider-gcp#88 the installer can relax the restriction on the infra-id to match the other platforms. Why is it important? On GCP all resources are prefixed with infra-id, which currently is 12 chars with 6 chars used by random bit, leaving only 6 chars from cluster name. This causes trouble associating the cluster to jobs in CI as most of the identifyable characters are dropped from the resource names in CI due to this restriction. Also because of the previous restriction, only one char are used from pool's name, making is higly likely to collide in cases there are more.
The infra id of the clusters on GCP was reduced to 12 in openshift#2088 because we couldn't handle the hostname seen by rhcos machine to be greater than 64. More details on this are available in https://bugzilla.redhat.com/show_bug.cgi?id=1809345 now since BZ 1809345 is fixed by openshift/machine-config-operator#1711 and openshift/cluster-api-provider-gcp#88 the installer can relax the restriction on the infra-id to match the other platforms. Why is it important? On GCP all resources are prefixed with infra-id, which currently is 12 chars with 6 chars used by random bit, leaving only 6 chars from cluster name. This causes trouble associating the cluster to jobs in CI as most of the identifyable characters are dropped from the resource names in CI due to this restriction. Also because of the previous restriction, only one char are used from pool's name, making is higly likely to collide in cases there are more.
This mirrors changes to GCP IPI in openshift#3544 The infra id of the clusters on GCP was reduced to 12 in openshift#2088 because we couldn't handle the hostname seen by rhcos machine to be greater than 64. More details on this are available in https://bugzilla.redhat.com/show_bug.cgi?id=1809345 now since BZ 1809345 is fixed by openshift/machine-config-operator#1711 and openshift/cluster-api-provider-gcp#88 the installer can relax the restriction on the infra-id to match the other platforms. Why is it important? On GCP all resources are prefixed with infra-id, which currently is 12 chars with 6 chars used by random bit, leaving only 6 chars from cluster name. This causes trouble associating the cluster to jobs in CI as most of the identifyable characters are dropped from the resource names in CI due to this restriction. Also because of the previous restriction, only one char are used from pool's name, making is higly likely to collide in cases there are more.
This mirrors changes to GCP IPI in openshift#3544 The infra id of the clusters on GCP was reduced to 12 in openshift#2088 because we couldn't handle the hostname seen by rhcos machine to be greater than 64. More details on this are available in https://bugzilla.redhat.com/show_bug.cgi?id=1809345 now since BZ 1809345 is fixed by openshift/machine-config-operator#1711 and openshift/cluster-api-provider-gcp#88 the installer can relax the restriction on the infra-id to match the other platforms. Why is it important? On GCP all resources are prefixed with infra-id, which currently is 12 chars with 6 chars used by random bit, leaving only 6 chars from cluster name. This causes trouble associating the cluster to jobs in CI as most of the identifyable characters are dropped from the resource names in CI due to this restriction. Also because of the previous restriction, only one char are used from pool's name, making is higly likely to collide in cases there are more.
🌱 Rebase on cluster-api v1.4
GCP platform provides search paths to resolve the virtual machine names by default. see https://cloud.google.com/compute/docs/internal-dns#resolv.conf
this also allows nodes in clusters to have node-names matching the virtual machine name instead of the fqdn be because fqdn is too long for RHCOS to accept as hostname
by default