Skip to content

gcp - bigtable - list clusters and tables by instance name - #11228

Open
Thanatos9404 wants to merge 2 commits into
cloud-custodian:mainfrom
Thanatos9404:gcp-bigtable-child-instance-name
Open

Thanatos9404 wants to merge 2 commits into
cloud-custodian:mainfrom
Thanatos9404:gcp-bigtable-child-instance-name

Conversation

@Thanatos9404

@Thanatos9404 Thanatos9404 commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Fixes #10664

gcp.bigtable-instance-cluster and gcp.bigtable-instance-table built their parent path from the instance's displayName, so whenever the display name differs from the instance id, the list call returns a 404 and the policy fails.

Instances already carry the full path in name. This sets the cluster resource's child_enum_params to ('name', 'parent'), matching the table resource, and removes both _get_child_enum_args overrides so the base ChildResourceManager maps the parent. This also fixes bigtable-instance-cluster-backup, which lists clusters through the cluster resource.

Tests

Added test_bigtable_instance_cluster_query (the policy from the issue) and test_bigtable_instance_table_query, with an instance whose id and display name differ. Both fail on main because the request goes to the display name path, and pass with this change. I don't have a GCP project, so their flight data is hand-written in the shape of the existing bigtable recordings.

#10676 also touches bigtable.py, so whichever lands second needs a small rebase.

bigtable-instance-cluster and bigtable-instance-table built the parent
path from the instance displayName, so listing failed with a 404 for
any instance whose display name differs from its id.

Map the parent from the instance name instead. It is already the full
projects/<project>/instances/<id> path, so the overrides that rebuilt
it from the default project and the display name are no longer needed.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 6 files

Confidence score: 4/5

  • test_bigtable.py won’t catch a project-mismatch regression because the replay session and instance use the same project. Use a different project for the parent instance and session.
Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="tools/c7n_gcp/tests/test_bigtable.py">

<violation number="1" location="tools/c7n_gcp/tests/test_bigtable.py:27">
P2: These new tests never exercise a project mismatch: both the replay session and returned instance use `cloud-custodian`. Use a fixture whose parent instance belongs to a different project and a separate session project so regressions to `get_default_project()` fail.</violation>
</file>

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

def test_bigtable_instance_cluster_query(self):
# The instance's displayName differs from its id, so clusters
# have to be listed under the instance name.
factory = self.replay_flight_data('bigtable-instance-cluster-query')

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: These new tests never exercise a project mismatch: both the replay session and returned instance use cloud-custodian. Use a fixture whose parent instance belongs to a different project and a separate session project so regressions to get_default_project() fail.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At tools/c7n_gcp/tests/test_bigtable.py, line 27:

<comment>These new tests never exercise a project mismatch: both the replay session and returned instance use `cloud-custodian`. Use a fixture whose parent instance belongs to a different project and a separate session project so regressions to `get_default_project()` fail.</comment>

<file context>
@@ -21,6 +21,32 @@ def test_bigtable_instance_cluster_backup_query(self):
+    def test_bigtable_instance_cluster_query(self):
+        # The instance's displayName differs from its id, so clusters
+        # have to be listed under the instance name.
+        factory = self.replay_flight_data('bigtable-instance-cluster-query')
+        p = self.load_policy({
+            'name': 'bigtable-instance-cluster',
</file context>

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parent bigtable-instance resource is listed in the session's project (scope_template='projects/{}'), so an instance's name always carries that same project and a mismatch can't happen in practice. The new tests cover the case behind the 404 in #10664, where the instance's displayName differs from its id.

…stance-name

# Conflicts:
#	tools/c7n_gcp/c7n_gcp/resources/bigtable.py

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GCP - BigTableInstanceCluster Uses Parent displayName

1 participant