Should projectRef be a required field?

[erikjoh]

I've noticed that several resources now require the projectRef field.

k8s-config-connector/crds/networkservices_v1beta1_networkservicesmesh.yaml

Lines 128 to 130 in a4b6667

	required:
	- location
	- projectRef

Whereas there are some resources that have but don't require the projectRef field.

k8s-config-connector/crds/bigquery_v1beta1_bigquerydataset.yaml

Lines 238 to 239 in a4b6667

	projectRef:
	description: The project that this resource belongs to.

Based on the discussion about projectRef in #349 , shouldn't the projectRef field be optional?
Since we have namespace level annotations for project I don't really see why it would be required in all cases.

For example now we must do:

apiVersion: networkservices.cnrm.cloud.google.com/v1beta1
kind: NetworkServicesMesh
metadata:
  name: mesh
  namespace: <project> # namespace that is annotated 'cnrm.cloud.google.com/project-id: <project>'
spec:
  location: global
  projectRef:
    external: projects/<project>

to not get a validation error (spec.projectRef: Required value).

Instead it would be nice to just have to do:

apiVersion: networkservices.cnrm.cloud.google.com/v1beta1
kind: NetworkServicesMesh
metadata:
  name: mesh
  namespace: <project> # namespace that is annotated 'cnrm.cloud.google.com/project-id: <project>'
spec:
  location: global

And let the field default based on the namespace annotation.

[xiaobaitusi]

Hi @erikjoh, thanks for posting the question.

In the long term, we are considering to deprecate the namespace-level cnrm.cloud.google.com/project-id annotation for a couple of reasons: 1) projectRef field in each resource should be the optimal approach to configure the project where the resource belongs to. Because the interface aligns consistently with the generic resource reference concept like topicRef. 2) the namespace defaulting logic requires the webhook to read the namespace object which causes some performance issue on upgrades or when a great number of resource being applied. We are suggested by GKE to minimize the outgoing calls from the webhook to the API server for the latency concern.

Therefore we suggest to specify the project info on the resource level using projectRef field or cnrm.cloud.google.com/project-id annotation. You can use kpt setter to specify the project for resources within the kpt package. See this kpt package example

Note that we are in the process of backfilling the projectRef field for existing resources. Newly released resources like NetworkServicesMesh will not support the cnrm.cloud.google.com/project-id annotation and only support the required projectRef field.

Is specifying the project info on the resource level maybe using kpt an acceptable alternative? Let us know what you think.

[erikjoh]

the namespace defaulting logic requires the webhook to read the namespace object which causes some performance issue on upgrades or when a great number of resource being applied

This is a strong enough reason to convince me projectRef should be required 😄
I think kpt would work for this.
Thanks for that detailed explanation!

[zchenyu]

@xiaobaitusi is there an issue we can track for this deprecation? Thanks!

[diviner524]

@zchenyu If you are referring to namespace-level cnrm.cloud.google.com/project-id. We will keep supporting this feature (although not recommended as explained in this thread) until the next major version.