Update PROJECT file

[nawazkh]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:

• Using Remove extraneous line from the PROJECT file #5382 as reference, this PR adds some more missing GVKs to the PROJECT file.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):

Special notes for your reviewer:

Just a note:

• ls config/crd/bases/ tells us all the CRDs CAPZ exposes.
• grep -R '+kubebuilder:object:root' api/v1beta1 exp/api/v1beta1 gives us the GVKs of CAPZ defines.

TODOs:

• squashed commits
• includes documentation
• adds unit tests
• cherry-pick candidate

Release note:

NONE

[k8s-ci-robot]

@nawazkh: The label(s) kind/fix cannot be applied, because the repository doesn't have them.

In response to this:

What type of PR is this?
/kind fix

What this PR does / why we need it:

• Using Remove extraneous line from the PROJECT file #5382 as reference, this PR fixes the domain of the project.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):

Special notes for your reviewer:

TODOs:

• squashed commits
• includes documentation
• adds unit tests
• cherry-pick candidate

Release note:

NONE

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.44%. Comparing base (eb432ed) to head (77f9e4b).
Report is 12 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5390   +/-   ##
=======================================
  Coverage   52.44%   52.44%           
=======================================
  Files         272      272           
  Lines       29349    29349           
=======================================
  Hits        15391    15391           
  Misses      13152    13152           
  Partials      806      806           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mboersma]

lgtm, comparing against AWS' version: https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/PROJECT

[nawazkh]

found more things to be added
/hold

[nawazkh]

/unhold
Ready for review.

[mboersma]

/lgtm

Although I'm going to be honest--I don't know what tooling consumes this file or where this YAML is used. Naively, it looks correct now, but can anyone clue me in?

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: abced52128c735e562f483ca4cb3b3ae66b12cd0

[nawazkh]

/lgtm

Although I'm going to be honest--I don't know what tooling consumes this file or where this YAML is used. Naively, it looks correct now, but can anyone clue me in?

TL;DR: PROJECT file is mostly use to showcase the list of APIs the project maintains.
It is an auto-generated file created on using kubebuilder <command>.
We should look into restoring this functionality. Might involve refactoring the CAPZ code.

---

Here's what I found.

• PROJECT file, also known as PROJECT config file is created when Kubebuilder is used to init project and/or add/edit APIs.
• Looking at the blame of this file, looks like PROJECT file was put in place long ago.
  And maybe somewhere along the way in the development of CAPZ we decided to opt for more custom approach of scaffolding CAPZ APIs, dropping (?) kubebulider way of scaffolding APIs. If we were to use kubebuilder --create api --group ... we would see an update to the PROJECT file.
• Reference to PROJECT file in kubebuilder documentation: https://book.kubebuilder.io/reference/project-config#project-config

---

Experiment: I tried creating my own API for a custom resource using Kubebuilder

1. Kubebuilder wanted me to move main.go to ./cmd/.
2. After doing that, kubebuilder did setup the CRD, controller, controller_test, suite_test, api.. etc artifacts. But is also added some new dependencies to the project (updated go.mod).
3. kubebuilder init did not finish successfully, but did generate a lot of artifacts in the project. If we were to go down this path, we want to refactor the code.

This short experiments hints me that CAPZ might have wanted to have more control over their APIs and might have moved away from kubebuilder. OR maybe, we did not add any APIs using kubebuilder create api in a while ?

[nawazkh]

/cc @willie-yao

[willie-yao]

I noticed that the ASO managed cluster types are not included here. Is there a reason for that?

[nawazkh]

I noticed that the ASO managed cluster types are not included here. Is there a reason for that?

I learned that PROJECT file is supposed to maintain a list of GVKs that are owned & maintained by the project.
So the ones like ASO* and AzureServicePrincipals are GVKs that CAPZ does not own, instead refers it or uses them as dependent resources.
Therefore we would not want to have ASO* resources in PROJECT file. Ideally, we should be finding ASO GVKs in ASO repo.

[willie-yao]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: willie-yao

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [willie-yao]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment