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

FEATURE: VTTablet naming #543

Open
GenLN opened this issue Mar 22, 2024 · 5 comments
Open

FEATURE: VTTablet naming #543

GenLN opened this issue Mar 22, 2024 · 5 comments

Comments

@GenLN
Copy link

GenLN commented Mar 22, 2024

Hi, is there some option to define custom naming of vttablet pods?
VTTablet pods are named like:

clusterName-vttablet-cellName-Tablet_UID-randomString

I would like to include keyspace-shard into naming instead having them on labels...

clusterName-vttablet-cellName-Keyspace-Shard-Tablet_uid-random string

Or if this gets too long for naming it like:

vttablet-Keyspace-Shard-TabletUID-randomString
cell in labels, clusterName in labels...

Or adjust values file to have an option for custom naming pods of vttablets and other components...

Looking at the pods list of vttablets i have no idea which one is for the specific keyspace/shard, until i read labels of the pod...

@mattlord
Copy link
Collaborator

I'm not necessarily against the idea, but it's worth noting that labels are the standard way to do this and it allows for using label selectors for filtering. For example:

 kubectl -n <ns> get pods --selector=planetscale.com/component=vttablet,planetscale.com/keyspace=customer,planetscale.com/shard=-80 -L planetscale.com/keyspace,planetscale.com/shard

That is objectively much better than having to use e.g. awk with the list of pod names. I understand that's not as convenient as being able to quickly see it in the pod names with a simple get pods, so I'm not against the idea, but just noting that this would likely have to be a contribution for it to happen.

@GenLN
Copy link
Author

GenLN commented Mar 28, 2024

Mainly reason is for easy monitoring/alerting components. As for vttablets I do monitor each pod on it's metric exposed ports... But for pod/container resource usage is much harder to obtain these labels in metrics(offers pod name or pvc name). Which if it was there would make dashboarding and filtering much easier, also alerting. If I can filter it by keyspace, shard, would show much more meaning info than pod name of the vttablet.
Vttablet pod name doesn't tell the much on first look, it gives you only tablet-uid and cell info aka alias. Also in resource metrics you have the pod name or pvc name which doesn't tell you right information on the first look, like oh it's vttablet of this shard of the keyspace which I need to look to it. Also what I noticed, vttablet label for tablet-type doesn't tell you this is primary vttablet. Didn't notice any of the lables can tell you this is primary. Until I look more deeper, like using vtctldclient to get primary vttablet alias etc..

@mattlord
Copy link
Collaborator

mattlord commented Apr 1, 2024

The problem you describe in the comment above certainly seems valid to me, but it's also not what I see the issue title and description as being about -- not as I read it anyway. IMO it's better to open an issue that describes the problem you're having in detail rather than proposing a potential solution which you feel might make 1 or more problems better. Make sense? Issue is the problem, a PR would be a proposed solution to the given problem.

@frouioui
Copy link
Member

frouioui commented Dec 2, 2024

Agreed with @mattlord. @GenLN do you have any update on this issue?

@GenLN
Copy link
Author

GenLN commented Dec 20, 2024

@frouioui yes, we managed to solve it via monitoring and custom grafana dashboards to easily identify tablets from which keyspace, shard, is it primary or not, etc.
So dashboard is our reference to those vttablet namings, ofc always we can check it by reading labels of the pod...

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

No branches or pull requests

3 participants