mixins: Normalize headless service name for query-frontend/scheduler

[JoaoBraveCoding]

What this PR does / why we need it:
Mixins in general are rather complex pieces of code to consume. When trying to use the loki mixins it wasn't apparent at first that I could use a headless service for DNS SRV discovery for both query_frontend and query_scheduler, especially because for frontend the service is named query_frontend_headless_service and for the scheduler, it's named query_scheduler_service_discovery. Furthermore, the query_frontend mixin provides a non-headless version of the service while query_scheduler doesn't. This PR aims at normalizing this for end users, both headless services are now named query_frontend_headless_service and query_scheduler_headless_service and both also provide a non-headless version of the service.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• CHANGELOG.md updated
• Changes that require user attention or interaction to upgrade are documented in docs/sources/upgrading/_index.md

[dannykopping]

@JoaoBraveCoding please fill in the PR template so we know why these changes are being made.
The "why" is just as important as the "what".

[JoaoBraveCoding]

@dannykopping done, sorry I forgot

[dannykopping]

Thank you @JoaoBraveCoding! I like the initiative here; have you tested this with your setup?

I'm hesitant to approve this though because it's changing the name of a service, which could cause disruption. I think we should hide this name behind a config option, defaulting to query-scheduler-discovery, and allowing folks to override it if they want to.

[JoaoBraveCoding]

I'm hesitant to approve this though because it's changing the name of a service, which could cause disruption. I think we should hide this name behind a config option, defaulting to query-scheduler-discovery, and allowing folks to override it if they want to.

Do you mean just the service name (metadata.name) or are you also worried that I've changed the name of the service resource in the mixin? Regarding the first, I am happy to put the name under a config variable defaulting to query-scheduler-discovery

have you tested this with your setup?

Not yet but I don't expect this to break anything since the only actual change was adding a service (the non-headless for scheduler) and modifying the name of a service (query-scheduler-discovery -> query-scheduler-headless)

[dannykopping]

I'm hesitant to approve this though because it's changing the name of a service, which could cause disruption. I think we should hide this name behind a config option, defaulting to query-scheduler-discovery, and allowing folks to override it if they want to.

Do you mean just the service name (metadata.name) or are you also worried that I've changed the name of the service resource in the mixin? Regarding the first, I am happy to put the name under a config variable defaulting to query-scheduler-discovery

Yeah if it changes the way we identify the resource in k8s then I think that's a risk.

[JoaoBraveCoding]

I've tested the change (thank you @dannykopping for suggesting it 😅 it had some bugs) This PR shows the modifications I had to make to use my version JoaoBraveCoding/observatorium#1 (I ran the make generate cmd to generate the new YAML manifests, no changes) this PR shows a green test CI with the new version observatorium/observatorium#508

[dannykopping]

Almost there, thanks for the changes!

[dannykopping]

LGTM, thank you very much @JoaoBraveCoding!