Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename host.name to host.hostname. #144

Merged
merged 3 commits into from
Oct 25, 2018
Merged

Conversation

webmat
Copy link
Contributor

@webmat webmat commented Oct 23, 2018

This is to align with the industry's convention of using the word "hostname".

@ruflin
Copy link
Member

ruflin commented Oct 23, 2018

Can you add a changelog? Also CI does not seem to be happy. My assumption is it's related to an autopep version issue. We had the same recently in Beats. I can open a separate PR for it.

I'm thinking if host.name becomes also valuable beside host.hostname. host.name would contain a name that can be manually set. We can discuss this in an other issue.

@webmat
Copy link
Contributor Author

webmat commented Oct 23, 2018

@ruflin Yeah the fix for the autopep8 code formatting issue is here: #146.

Changelog incoming.

@ruflin
Copy link
Member

ruflin commented Oct 23, 2018

@tsg @jsvd As this is a pretty major on for LS and Beats and want to get your eyes on this one. It is a case we can handle pretty well with the alias feature as it's a 1-1 mapping.

@ruflin
Copy link
Member

ruflin commented Oct 25, 2018

Based on #143 and #142 I think we need host.name and host.hostname. Let me explain. The host.hostname is what we described at the moment as host.name so this PR is valid as it is. host.name is a user given name to the host. In some cases this could be just my-test-host or also fqdn. Is a request we saw frequently in Beats and is the reason beat.name is configurable.

I suggest we move forward with this PR and do a follow up PR to reintroduce host.name. In general *.name is something user configurable.

@ruflin ruflin merged commit 77d7429 into elastic:master Oct 25, 2018
@ppf2
Copy link
Member

ppf2 commented Nov 9, 2018

Some of our users who have hit the breaking change in 6.3 (from hostname to host.name) have since switched to host.name. Re-introducing host.name as an additional "host name" field can be nice so there is 1 less breaking change when they get to 7 :) @acchen97

@webmat webmat deleted the host-hostname branch November 9, 2018 13:42
@webmat
Copy link
Contributor Author

webmat commented Nov 9, 2018

@ppf2 Yeah the convention in ECS will be that .name will be purely a customizable name that people can override. Soon we'll have both of them in the schema.

  • host.hostname == what hostname command returns on this host
  • host.name == whatever override name the admin wants to give this machine

This is also true of other places where we have .name.

  • agent.type=mysql this agent monitors a MySQL thing
  • agent.name=finance-db this agent monitors the finance dept's MySQL thing

So in short, users will be free to continue using host.name however they want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants