Skip to content

Commit 4d3f7db

Browse files
umairidrismorgante
andauthored
chore: Add V4 migration guide (#56)
* add migration guide * use list * Update docs/upgrading_to_bigquery_v4.0.md Co-Authored-By: Morgante Pell <morgante.pell@morgante.net> * simplify access migration Co-authored-by: Morgante Pell <morgante.pell@morgante.net>
1 parent 0367d69 commit 4d3f7db

File tree

1 file changed

+83
-0
lines changed

1 file changed

+83
-0
lines changed

docs/upgrading_to_bigquery_v4.0.md

+83
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
# Upgrading to BigQuery v4.0
2+
3+
The v4.0 release of BigQuery is a backwards incompatible release.
4+
- The supported provider has been updated to v3.0.
5+
- Add support for setting custom access. The default has been changed to be more
6+
secure.
7+
- The UDFS submodule has been isolated from the main module.
8+
- Trimmed outputs and made their names more consistent.
9+
10+
## Access
11+
12+
The major logic change in this release is a new default for the `access` field.
13+
14+
Datasets are created with the following
15+
[default](https://cloud.google.com/bigquery/docs/reference/rest/v2/datasets):
16+
17+
18+
> If unspecified at dataset creation time, BigQuery adds default dataset access for the following entities: access.specialGroup: projectReaders; access.role: READER; access.specialGroup: projectWriters; access.role: WRITER; access.specialGroup: projectOwners; access.role: OWNER; access.userByEmail: [dataset creator email]; access.role: OWNER;
19+
20+
The problematic default is
21+
`access.userByEmail: [dataset creator email]; access.role: OWNER`.
22+
This will subtly grant owner access to the creating user and leave that access
23+
on, even if the access to the project, etc is revoked.
24+
25+
The new default will only set
26+
`specialGroup: projectOwners; access.role: roles/bigquery.admin`. This is done
27+
because the BigQuery API requires at least one owner on the dataset, and this is
28+
the safest and most generic owner that can be granted.
29+
30+
Do note that standard GCP IAM logic still apply to bigquery datasets.
31+
For example, setting an IAM role at the project level will inherit to all
32+
datasets within the project.
33+
34+
## Migration Instructions
35+
36+
1. Upgrade version
37+
```diff
38+
module "bigquery" {
39+
source = "terraform-google-modules/bigquery/google"
40+
- version = "~> 3.0"
41+
+ version = "~> 4.0"
42+
....
43+
}
44+
```
45+
46+
2. Set access to an empty slice if you wish to preserve existing behaviour
47+
```diff
48+
module "bigquery" {
49+
source = "terraform-google-modules/bigquery/google"
50+
+ access = []
51+
...
52+
}
53+
```
54+
55+
3. Move add_udf field to its own module call
56+
```diff
57+
module "bigquery" {
58+
source = "terraform-google-modules/bigquery/google"
59+
- add_udfs: true
60+
...
61+
}
62+
63+
+ module "add_udfs" {
64+
+ source = ""terraform-google-modules/bigquery/google//modules/udf"
65+
+ version = "~> 4.0"
66+
+ dataset_id = module.bigquery.bigquery_dataset.dataset_id
67+
+ project_id = module.bigquery.bigquery_dataset.project
68+
}
69+
```
70+
71+
4. Adjust output references
72+
73+
- The following outputs have been deleted:
74+
- dataset_labels
75+
- table_labels
76+
- added_udfs
77+
- The following outputs have been renamed:
78+
- data_project -> project
79+
- table_id -> table_ids
80+
- table_name -> table_names
81+
82+
See https://www.terraform.io/docs/configuration/outputs.html#accessing-child-module-outputs
83+
on how to adjust your usage.

0 commit comments

Comments
 (0)