Replace hostname -f with unmae -n

[nak3]

OpenShift should not depend on hostname command.
From RHEL 7 hostnamectl is used for controlling the HostName. In addition, the specification of hostname is being changed by upstream often.

And then, in case uname -n (even if hostname -f) returns error, it means Fatal. I think it is impossible to return error by uname -n (or hostname -f).

[smarterclayton]

We are consistent with upstream. Please work with them to switch that, then we can change this once upstream has changed.

[smarterclayton]

This should be handled by other code, not here. We do not glog.Fatal in common code.

[nak3]

Even upstream is using glog.Fatalf , we should not use it here?
[1] https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/util/node.go#L31-L34

[smarterclayton]

They are doing startup differently - we only use glog.Fatal in very specific places, and everywhere else is required to return an error.

On Apr 6, 2015, at 11:24 AM, Kenjiro Nakayama [email protected] wrote:

In pkg/cmd/server/start/node_args.go:

if err != nil {

•   return "", fmt.Errorf("Couldn't determine hostname: %v", err)
  

•   glog.Fatalf("Couldn't determine hostname: %v", err)
  

  Even upstream is using glog.Fatalf , we should not use it here?
  [1] https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/util/node.go#L31-L34

—
Reply to this email directly or view it on GitHub.

[nak3]

I think I couldn't tell you correctly. hostname -f is wrapper command of uname -n.

My concern is that it is not simple to get the Hostname by hostname -f. It will look up somewhere /etc/hostname, /proc/sys/kernel/hostname, /etc/hosts or uname -n. hostname's upstream is often updating it and it is a little difficult to follow their update.

On the other hand, uname -n is a front end for a system call and simply get hostanme. Please refer gethostname(2) man page.

[smarterclayton]

That may be the case, but we're simply trying to fit with kube. Can you open an upstream issues on Kubernetes about this with this info? I just want to make sure we're consistent.

----- Original Message -----

I think I couldn't tell you correctly. hostname -f is wrapper command of
uname -n.

My concern is that it is not simple to get the Hostname by hostname -f. It
will look up somewhere /etc/hostname, /proc/sys/kernel/hostname,
/etc/hosts or uname -n. hostname's upstream is often updating it and it
is a little difficult to follow their update.

On the other hand, uname -n is a front end for a system call and simply get
hostanme. Please refer gethostname(2) man page.

---

Reply to this email directly or view it on GitHub:
#1597 (comment)

[nak3]

Ah... I understand. Your upstream means Kubernetes. I thought hostname command's upstream.
Sure I will.

[smarterclayton]

Fixed in upstream - kubernetes/kubernetes#7072. Can you update this pull against the code (we might have added hostname -f in a few places) and then I'll review and merge?

Thanks for following through on this.

[nak3]

Regarding to OpenShift, hostname which is getting fqdn is only here. I think I don't need any update from previous commit.

[smarterclayton]

LGTM [merge]

[openshift-bot]

Evaluated for origin up to cb9f1d8

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/1820/) (Image: devenv-fedora_1449)