Preferred parameter naming

Hello,

I am working on cleaning up our parameters, documenting and renaming some that are copies (e.g. ntpServer and ntp-server). While working on this, it makes sense to find a common naming scheme and enforce it for once and forever probably via a simple Raketask (grep) or rule for https://github.com/Shopify/erb-lint. We have several styles, the purpose of this poll is to find the preferred way, then rename all parameters of course in non-breaking way (implementing aliases and auto conversion of existing ones) and enforce the style in our codebase.

  • Underscore: ntp_server (67 params today)
  • Dash: ntp-server (31 params)
  • Camel: ntpServer (15 params)

0 voters

The reason why we want to cleanup the list is user experience, we are going to show parameters on the host/hostgroup form, even if we improve the UI we don’t want to confuse users with showing two or three variants of the same parameter.

I’d prpopose to implement auto aliasing with deprecation warning, a simple hash hardcoded in the codebase converting renamed names to new one issuing deprecation warning. Also for user convinience, if we pick let’s say underscore, it would automatically convert ntp-server or ntpServer to ntp-server issuing the same warning.

If you just want me to cleanup parameters, rename and deprecate old ones (without new “auto coversion”) or simply keep the status quo, drop a comment below. I cannot edit a poll anymore.

For me it is kebab-case > snake_case > camelCase.

So let’s say we decide to go with underscores. Then when there’s a myVar in a template, it would get translated and we’d look for my_var parameter assigned to the host, correct? Should we also introduce a fallback to the original name of the parameter?

Then any of the three would work:

  • host_param('myVar')
  • host_param('my_var)
  • host_param('my-var')

But in the database (Parameters table) we would only have my_var and this would be presented to the user. Long term, we would convert all templates to use my_var too but no pressure.

They could use any of the three options, but the parameter would have to be called my_var. But what if people had custom templates and parameters? Or do we want to enforce that even custom parameters have to have our preferred format?

Oh I was thinking this as a fallback, if myVar was not found then try my_var as well.

I believe this is a bad idea to enforce globally since users set up their own templates and parameters. We could decide to try and make the default templates consistent and migrate the parameters used by them, but that will likely break a lot of custom templates that use the same parameter names.
Also, what if some user is using the same name with different case style to denote different use cases? e.g. for provisioning they use ntp_server but for rex they use ntpServer.

Absolutely, I am not proposing that. My proposal was to enforce this in our core codebase only for better consistency.

Yes that is the plan for sure. The thing is many of these changes will be converting from dash to underscore or vice versa, thus I proposed the naming auto-fallback (not sure how to name this).

That’s the reason why I am proposing list of deprecated parameters that will make this easier.

That is a problem which such a cleanup can bring to attention. I’d say benefits are over this, so I’d go ahead and if there is a bugreport we can easily fix this. This is quite theoretical, if you have a host/hostgroup you want to keep the parameters the same regardless of the method.