More meaningful name for `@task.kubernetes` pods by default

[insomnes]

Description

Generate more meaningful default names for pods by @task.kubernetes with explicit randomness control

Use case/motivation

Reference PR with tests showing the desired changes:
#46462

Now pod created by decorator would have name f"k8s_airflow_pod_{uuid.uuid4().hex}" if name was not explicitly provided by the user.

I want more meaningful names by default (via python_callable name utilization) and to reuse already present randomness in name control option from KubernetesPodOperator: random_name_suffix.

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[RNHTTR]

For future reference, there's no need to open an issue if you already have a PR submitted :)

[insomnes]

Yeah, sorry for that, I thought that for features it's different from bug fixes. Thanks for clarifying this for me!

[insomnes]

I think these changes also somewhat solve
#44779

[insomnes]

Can someone with the rights please set reviewers (or even take a look) for the new PR?

It is redo of the PR already approved by Ryan, but I've messed it up during rebase for providers transition and closes it.

So after re-creation it fell in a loophole when CODEOWNERS file was broken due to mentioned transition, and no reviewers were set automatically.

#46535

[potiuk]

Please do not "rush" things. You seem to be pretty impatient to get reviews. But this is open-source and people review things (and generally react) when they feel like they have some time or when they are interested in certain features or where someone is persistent (but also patient) enough to remind about their PR. BUT those are mostly volunteers here. 72 HRS for ANY reaction time is an absolute minimum you can expect. People here work in their free time often. They have holidays, weekens, sometimes families they tend to. Or simply might be busy at work and decide for a while not to spend their FREE time on the project.

And CODEOWNERS are not really well used so far - they were - in many cases not even used. I just - lterally an hour ago started a discussion about that on our devlist https://lists.apache.org/thread/xq7837nd2j99slb558ls7b6jqntq6y32 and if you would like to add your thinking on how things should be working there from a user perspective - you are absolutley free to joing the conversation (see community tab on our website to know how to join the devlist).

Generally speaking - you should be patient and wait for maintainers to pick an interest and if they don't, you should re-ping (again in -general - not individual people) after reasonable time - counted in several days, not hours. This is also described in our contribution guides - particularly https://github.com/apache/airflow/blob/main/contributing-docs/16_contribution_workflow.rst where you can learn more (and I suggest you generally read the whole contributor's guide - it's pretty good read).

Also - if I may suggest - open a few more PRs while you are waiting. One of the things here is that different areas are often tended to by different people and some of them might pick interested in different PRs faster of slower. By having several different things to work on you can account for the asynchronous - and apparently longer that maybe you are used to -feedback time. Having several things in parallel helps with that enormously.