turbot/steampipe-plugin-gcp

table gcp_compute_machine_type not support t2a machine type query

Closed this issue · 10 comments

ahlfors commented

Describe the bug
table gcp_compute_machine_type not support t2a machine type query

Steampipe version (steampipe -v)
0.20.9

Plugin version (steampipe plugin list)
v0.40.0

To reproduce
execute:

steampipe query  "select * from gcp_compute_machine_type where name = 't2a-standard-2'" --output line

Expected behavior
Table gcp_compute_machine_type returns t2a-standard-2 machine type records.

Additional context
Returns nothing.

ahlfors commented

#465 Update zone to us-central1-a to support query t2a machine type to fix this issue

rajlearner17 commented

@ahlfors Thanks for using Steampipe!

Nice to see this PR and further testing on it.
Just quick question on the change you made, is there any GCP doc stating to make this change to us-central1-f. This will help.

CC @misraved

ahlfors commented

@rajlearner17 Checked with gcp official doc again, I changed pr to use uc-central1-a, which covered all machine types in this zone : https://cloud.google.com/compute/docs/regions-zones#quotas

rajlearner17 commented

@ahlfors Thanks; I hope you mentioned us-centra1-a above. thanks for sharing this doc ref

image

CC @misraved

ahlfors commented

yes, change to us-centra1-a is the fastest fix, as I known.

cbruno10 commented

If machine types are tied to zones, I wonder if the table should instead use a ParentHydrate to list zones, and then list machine types for each zone? If you then run select * from gcp_compute_machine_type, then it'd list all machine types for all zones, but you could limit results with distinct or distinct on.

  • 👀1
ParthaI commented

@cbruno10 -- After digging into this, below are the points I would like to bring upon

  • We cannot assume that all the machine types returned by the table are supported in all zones.
  • We can list the available machine types per zone using the parent hydrate, but this approach might result in duplicate data.
  • We can determine which machine types are supported in each zone.

Based on your suggestion, we get the following result using the parent hydrate (with my local change).

> select count(name) from gcp_compute_machine_type
+-------+
| count |
+-------+
| 13141 |
+-------+

> select count(distinct name) from gcp_compute_machine_type
+-------+
| count |
+-------+
| 203   |
+-------+

In my opinion, from a design perspective, it would be beneficial to structure the table as follows:

  • The table will use the zone as parent hydrate.
  • An additional column named zone_name will be added to the table gcp_compute_machine_type
  • The list config will include an optional key column, zone_name.
  • If zone_name is specified, API calls will be restricted to that particular zone.
  • The get configuration will require two key columns: name and zone_name.

Please let me know if this approach is acceptable, or we further connect to discuss. Thank you!

cbruno10 commented

@ParthaI Thanks for testing, I think your design suggestions look great!

@ahlfors If this design also looks good to you, are you interested in updating your PR to follow this design? Or we can make the updates to the machine type table if you'd find that helpful.

  • 👍1
  • 👀1
rajlearner17 commented

@ParthaI Better we raise the PR for this, and @ahlfors can validate the outcome. This will help to close this issue.