Add project quotas factory

[wiktorn]

Follow up on #2210 - add factory to manage quotas.

Use cases for this factory:

• application teams - to manage quotas within their projects (usually together with project_create = false), especially when using GPUs
• to be used in modules/project-factory - to allow quota management during project creation

---

Checklist

I applicable, I acknowledge that I have:

• Read the contributing guide
• Ran terraform fmt on all modified files
• Regenerated the relevant README.md files using tools/tfdoc.py
• Made sure all relevant tests pass

[ludoo]

Great stuff, but do you think one factory per project is a valid use case? For the type of usage I've seen, I would think of

• support for multiple projects in a single factory, only used to control quotas
• simple support for quotas in a project factory project-level YAML file, to control specific quotas at project creation

Do you have an actual use case for the factory in this pr?

[wiktorn]

Updated the description above. My use-case is the - application teams. They do get a project from central team, but they are free to manage IAM and quotas locally. They have just a bunch of projects (few projects per environment), where they do need to manage the quotas and one IaC service account per project (limited to the project scope).

Multiple-project quota-only factory could be used here as well, but in this case, it would be used just for single project.

[ludoo]

Updated the description above. My use-case is the - application teams. They do get a project from central team, but they are free to manage IAM and quotas locally. They have just a bunch of projects (few projects per environment), where they do need to manage the quotas and one IaC service account per project (limited to the project scope).

Multiple-project quota-only factory could be used here as well, but in this case, it would be used just for single project.

Makes sense, thanks. What would you think of a slightly different factory, that used one file per region respecting the format you get with gcloud compute regions describe? It would allow dumping the yaml from gcloud, deleting a bunch of lines, and reusing it.

[wiktorn]

Makes sense, thanks. What would you think of a slightly different factory, that used one file per region respecting the format you get with gcloud compute regions describe? It would allow dumping the yaml from gcloud, deleting a bunch of lines, and reusing it.

Good idea. I still think it is necessary to keep current structure as well, for all the quotas that are not region based or have multiple dimensions, and user wants to specify them all.

This will allow some foot-shooting, when user will specify the same quota twice with different values for the same dimensions. The other approach is to "re-key" them by dimensions and quota_id's.

[ludoo]

Makes sense, thanks. What would you think of a slightly different factory, that used one file per region respecting the format you get with gcloud compute regions describe? It would allow dumping the yaml from gcloud, deleting a bunch of lines, and reusing it.

Good idea. I still think it is necessary to keep current structure as well, for all the quotas that are not region based or have multiple dimensions, and user wants to specify them all.

This will allow some foot-shooting, when user will specify the same quota twice with different values for the same dimensions. The other approach is to "re-key" them by dimensions and quota_id's.

Well compute quotas (are there any others?) are either regional or global, and the structure is identical. My preference would be for using one file per region, and one file with "global", and reusing the format exported by gcloud.

Dimension is just the region for compute.

[ludoo]

Well, new format has dimensions and is what we need so Wiktor wins this discussion. :)