Thanos: Move components names to `Ruler`, `Compactor`, `Querier` (`-er`)

[bwplotka]

It's maybe a minor but we should be consistent on naming. In the documentation, code and thanos command we have rule, compact, downample, query vs in some docs, deployments and most of the presentations we are leaking Querier, Ruler, Compactor

This conflicts a bit with Store Gateway but we already have some discussion about renaming it: https://github.com/thanos-io/thanos/issues/1646

I would vote -er as it's more correct (aka go way of naming objects as well) and it avoids name collisions like rule (recording/alerting rule) vs rule (the component responsible for evaluating rules).

AC:
< to agree>

Any thoughts?

[GiedriusS]

It makes sense, I agree. Also, don't forget our GH labels! :smile:

[domgreen]

Why not also change store to gateway or proxyer whilst making changes?

[bwplotka]

Same for receive -> receiver I guess (:

[yeya24]

Anyone work on this issue? I guess I can take this 😆

[bwplotka]

Thanks. We need to decide what to do with metrics as well as they are all over the place with query rule etc, should we rename at once? @brancz any tips? (:

[bwplotka]

I think we need to be careful here as this minor consistency naming change might be not worth everywhere when introducing so many breaking changes ): Things like metrics, components will make our user life harder when upgrading.

[yeya24]

I think updating the metrics now might not be a good option. Just update the docs first.

[bwplotka]

:+1:

[brancz]

I feel like for how disruptive renaming the components would be, the gain would be too small. Yes we should be consistent in the metrics and component names, but in docs and presentations for the flow of the language we can use querier, ruler, etc. but otherwise the existing component names work just fine in my opinion and don't require changing.

I don't feel super strongly about this so if the rest of the maintainers feel like this is necessary I won't stand in the way, but I feel it's going to cause more confusion and unexpected breakage than gain.

[daixiang0]

@kakkoyun any process about this?

[bwplotka]

Due to compatibility issues I would say we stick to docs, new places we name things like Alert names, deployment names etc.

Metrics, command, and component names in code should stay for now.

[kakkoyun]

@daixiang0 This week I'll start working on this and primarily focus on docs.

[yeya24]

I am not sure is this still valid?

[kakkoyun]

@yeya24 Maybe we should break this into pieces. Like thanos-mixin/compact -> thanos-mixin/compactor, docs/compact -> docs/compactor and cmd/compact -> cmd/compactor etc.

WDYT?

[brancz]

I think we need to revisit our changes slightly here. I was under the assumption we’re only changing language in sentence form but keep technical references consistent so I think the mixin should use the command names in its structure and in let’s say alert descriptions use whatever is more fluent.

[kakkoyun]

My understanding from this issue was, we would eventually move to *tor naming schema, thus my changes.

And it's more clear now.

Just to recap. we will keep structural build blocks (code references, filenames etc.) as in commands and only rename documentation (user guideline, alert message etc). Am I right?

[bwplotka]

Definitely, we have to find something consistent (:

only changing language in sentence form
keep technical references

What exactly this means? I assume:

• User -er -or in:

  • While speaking about components
  • Presentations
  • Documentation
  • Code comments (?)
  • Log messages, traces?

• Keep the old way (and revert things that were made -er -or:

  • Metrics
  • Commands
  • Mixin/alerts/rules
  • Container names
  • Flags, configuration?
  • Code methods/structs
  • Package names

There are some gray areas like logging e.g which are not really tricky to change. I think we need to just put some list and agree on this. Anything else I missed?

[brancz]

That sounds perfect to me. I'll start applying that. Maybe it's worth documenting this in our CONTRIBUTING.md ?

[bwplotka]

Definitely will add - and let's make sure we keep it up to date

[bwplotka]

Done: https://github.com/thanos-io/thanos/pull/2094

To close this issue we probably have to look through those items and ensure consistency. I know for sure there are metrics that are sometimes compact sometimes compactor etc.

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.

[brancz]

I think we’re pretty close to having all the changes down for this. Only a few metric names have to be fixed I think.

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. Please comment on status otherwise the issue will be closed in a week. Thank you for your contributions.