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

Request For Comments: Renaming wmi_exporter? #499

Closed
carlpett opened this issue Apr 4, 2020 · 14 comments
Closed

Request For Comments: Renaming wmi_exporter? #499

carlpett opened this issue Apr 4, 2020 · 14 comments

Comments

@carlpett
Copy link
Collaborator

carlpett commented Apr 4, 2020

Hi everyone!
When @martinlindhe started out the project, we used WMI exclusively to get data to convert to metrics. The last year or so, however, we've increasingly started to move away from WMI due to performance and reliability issues, as well as widened how we collect data, and now use Perflib and HCS in addition to WMI.
As we move towards less and less WMI usage, we'd like to deemphasise it from the project. For this reason, it might make sense to rename the project. We'd like feedback on two things:

  • What would be a good name? windows_exporter and winnode_exporter are ones that have been proposed earlier, but other options would be very welcome.
  • How would a name change impact you? There are likely a number of scripts and similar things that have been written over the years that would need to be changed. In some cases perhaps security policies and such. Let us know what sort of issues you'd face! Would it be sufficient to supply artifacts for both the new and old name for some period?
@carlpett
Copy link
Collaborator Author

carlpett commented Apr 4, 2020

cc @andrewmostello - for the chocolatey bits, what would need to happen there?

@SuperQ
Copy link
Contributor

SuperQ commented Apr 4, 2020

windows_exporter sounds like a fine name to me.

@simmohall
Copy link

sounds like a good idea. I lean towards winnode_exporter as it's similar to the linux counterpart node_exporter

@discordianfish
Copy link
Member

I like windows_exporter.

PS: When I started the node-exporter at SoundCloud, there was a lot of bikeshedding involved in finding the name. No reason to stick with 'node' since not everybody was a big fan of that name back then either :)

@Mario-Hofstaetter
Copy link
Contributor

I also prefer windows_exporter , and dislike node_exporter 😄
Hopefully this is future proof?
Since we are early in rolling out the exporter the name changes has no consequence but thats clearly the exception.

@martinlindhe
Copy link
Collaborator

I prefer windows_exporter

@andrewmostello
Copy link
Contributor

cc @andrewmostello - for the chocolatey bits, what would need to happen there?

I think I would just create a new package with the updated name, and make a reference note and link on the old package. I've been looking into it and I don't think you can rename packages, although I'll keep reviewing the documentation.

@dalejrodriguez
Copy link

windows_exporter sounds good to me.

@marcusteixeira
Copy link

Great work!
I also prefer windows_exporter.

@daviddetorres
Copy link

windows_exporter seems to me more intuitive, but people used to monitor node-exporter will find it more similar with winnode_exporter... Difficult to choose.

I'd go for winnode_exporter.

@eikaas
Copy link
Contributor

eikaas commented May 6, 2020

I suggest the slightly more Go idiomatic winexporter

I'd prefer win_exporter over windows_exporter though, as it's easier to type and I don't think the win-abbreviation adds any ambiguity

@SuperQ
Copy link
Contributor

SuperQ commented May 6, 2020

As @discordianfish said, there's no need to follow the node_exporter name. windows_exporter is sufficient. In Prometheus naming, we usually recommend avoiding abbreviations.

@discordianfish
Copy link
Member

Man, this is the most bikesheddingy issue ever. Going to unsubscribe.

@carlpett
Copy link
Collaborator Author

carlpett commented May 7, 2020

Yes, this should probably have been brought to a conclusion a while ago. Let's go with windows_exporter. There's a couple of things that need to happen, but I'll put them in a separate issue.

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

No branches or pull requests