REQUEST: Create Repository for CPU DRA driver

[catblade]

New repo, staging repo, or migrate existing

New repository

Is it a staging repo?

no

Requested name for new repository

dra-driver-cpu

Which Organization should it reside

kubernetes-sigs

Who should have admin access?

@johnbelamaric, @pohly, @klueska, @catblade

Who should have write access?

@johnbelamaric, @pohly, @klueska, @catblade

Who should be listed as approvers in OWNERS?

@johnbelamaric, @pohly, @klueska, @catblade

Who should be listed in SECURITY_CONTACTS?

@johnbelamaric, @pohly, @klueska, @catblade

What should the repo description be?

CPU DRA Driver

What SIG and subproject does this fall under?

sig-node, resource-management

Please provide references to appropriate approval for this new repo

Multiple Discussions on this Topic.

Recent one at latest KubeCon:
cncf/maintainer-summit#15

Design doc for requirements here:
https://docs.google.com/document/d/1sPE7EhuSkNYXGf9TTDoD_V2D4TZAWF1ieJ4xmArMmPQ/

Additional context for request

Ping to @johnbelamaric and @mrunalp

[dims]

@catblade are there going to be more of these? we have used the prefix pattern before:

• https://github.com/orgs/kubernetes/repositories?q=cloud-provider
• https://github.com/orgs/kubernetes-sigs/repositories?q=cluster-api-provider

as well suffix pattern:

• https://github.com/orgs/kubernetes-sigs/repositories?q=csi

So picking one or the other should be conscious decision. Are you ok with the suffix?

[johnbelamaric]

Oof we have both already: https://github.com/orgs/kubernetes-sigs/repositories?q=dra

[johnbelamaric]

I don't have a particular preference personally. So either dra-cpu-driver or cpu-dra-driver. Maybe we can rename one of the others so they are all consistent?

[johnbelamaric]

Or even dra-driver-cpu?

[johnbelamaric]

I think probably k-sigs too

[catblade]

I'm ambivalent on the name.

[dims]

as a group, please pick one and stick to it (and update existing repos!)

[pohly]

"The DRA example driver" led to "dra-example-driver". This flows better for me than "the example DRA driver". It's also referenced quite a bit more than the CNI driver, so my preference is to use the dra-<something>-driver pattern.

Note sure how much I care about renaming cni-dra-driver to dra-cni-driver. @LionelJouin, @aojea ?

[klueska]

We had a long discussion on this when naming the DRA driver for GPUs, and eventually settled on nvidia-dra-driver-gpu. The reason being that there may be more nvidia-dra-driver's in the future (that arent for GPUs) and its nicer to see the qualifying piece at the end rather than stuck in the middle. We also always refer to it as the "NVIDIA DRA driver for GPUs" not the "NVIDIA DRA GPU driver" to avoid three all caps acronyms next to one another -- and this then matches the schema we decided on with <vendor>-dra-driver-<class>.

[aojea]

Note sure how much I care about renaming cni-dra-driver to dra-cni-driver. @LionelJouin, @aojea ?

I do not think in networking we get into a vendors problem, we have fragmentation on the implementations of the low level cni, nri, cdi, ... or the functionality, nics or more complex things or networking constructs like VRF or "Networks", so dra-network-driver-<something> sounds a good pattern for networking, @LionelJouin WDY?

[pohly]

<vendor>-dra-driver-<class>

With "DRA example driver", I'm thinking of DRA as "the vendor". It's "our" example. We could rename to "sigs.k8s.io/dra-driver-example"? I don't like "kubernetes-dra-driver-example", it feels redundant.

[klueska]

Yeah, I'd be fine leaving off kubernetes as an implied vendor / sponsor when it has open-governance