Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update examples for Cloud Bigtable AppProfile #5871

Merged
merged 1 commit into from
Apr 1, 2022

Conversation

kevinsi4508
Copy link
Contributor

@kevinsi4508 kevinsi4508 commented Mar 30, 2022

With latest cluster group support, users can create 3 different flavors of AppProfile:

Any cluster: requests can be routed to any of the clusters in an instance.
Single cluster: requests can be routed to the only cluster specified in the AppProfile.
Muti cluster: request can be routed to a group of clusters specified in the AppProfile.
Update the examples to show users can create all 3 different flavors of AppProfile mentioned above.

If this PR is for Terraform, I acknowledge that I have:

  • Searched through the issue tracker for an open issue that this either resolves or contributes to, commented on it to claim it, and written "fixes {url}" or "part of {url}" in this PR description. If there were no relevant open issues, I opened one and commented that I would like to work on it (not necessary for very small changes).
  • Generated Terraform, and ran make test and make lint to ensure it passes unit and linter tests.
  • Ensured that all new fields I added that can be set by a user appear in at least one example (for generated resources) or third_party test (for handwritten resources or update tests).
  • Ran relevant acceptance tests (If the acceptance tests do not yet pass or you are unable to run them, please let your reviewer know).
  • Read the Release Notes Guide before writing my release note below.

Release Note Template for Downstream PRs (will be copied)

bigtable: Update the examples to show users can create all 3 different flavors of AppProfile

@modular-magician
Copy link
Collaborator

Oops! It looks like you're using an unknown release-note type in your changelog entries:

  • REPLACEME

Please only use the types listed in https://github.com/GoogleCloudPlatform/magic-modules/blob/master/.ci/RELEASE_NOTES_GUIDE.md.

@modular-magician
Copy link
Collaborator

Hello! I am a robot who works on Magic Modules PRs.

I have detected that you are a community contributor, so your PR will be assigned to someone with a commit-bit on this repo for initial review.

Thanks for your contribution! A human will be with you soon.

@slevenick, please review this PR or find an appropriate assignee.

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 2 files changed, 150 insertions(+), 11 deletions(-))
Terraform Beta: Diff ( 2 files changed, 150 insertions(+), 11 deletions(-))
TF Validator: Diff ( 2 files changed, 3 insertions(+), 3 deletions(-))
TF OiCS: Diff ( 6 files changed, 153 insertions(+), 3 deletions(-))

@@ -1,7 +1,7 @@
resource "google_bigtable_instance" "instance" {
name = "<%= ctx[:vars]['instance_name'] %>"
cluster {
cluster_id = "<%= ctx[:vars]['instance_name'] %>"
cluster_id = "cluster-1"
Copy link
Contributor

Choose a reason for hiding this comment

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

Changing this id to cluster-1 will interfere with running multiple tests in parallel. Is there a reason to hard-code this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hm.. interesting. Where are the multiple tests coming from?

If the instance ID (or name) is the same, there is already a naming collision and running multiple tests with that naming collision will have problem.

If the there is no naming collision at the instance level, there should not be a problem using the same cluster ID in different instances.

For example, the following is not a problem:

Instance-1
cluster1: 'projects/my-project-id/instances/Instance-1/clusters/cluster-1'
cluster1: 'projects/my-project-id/instances/Instance-1/clusters/cluster-2'

Instance-2
cluster1: 'projects/my-project-id/instances/Instance-2/clusters/cluster-1'
cluster1: 'projects/my-project-id/instances/Instance-2/clusters/cluster-2'

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking of doing something like this:

"cluster_id = "<%= ctx[:vars]['instance_name'] %>"-c1"
"cluster_id = "<%= ctx[:vars]['instance_name'] %>"-c2"

I thought it is really not needed. As long as the instance ID/name is unique, we can hardcode the cluster IDs (as long as they are unique within the instance).

@slevenick
Copy link
Contributor

/gcbrun

@modular-magician
Copy link
Collaborator

Hi! I'm the modular magician. Your PR generated some diffs in downstreams - here they are.

Diff report:

Terraform GA: Diff ( 2 files changed, 150 insertions(+), 11 deletions(-))
Terraform Beta: Diff ( 2 files changed, 150 insertions(+), 11 deletions(-))
TF Validator: Diff ( 2 files changed, 3 insertions(+), 3 deletions(-))
TF OiCS: Diff ( 6 files changed, 153 insertions(+), 3 deletions(-))

Copy link
Contributor

@slevenick slevenick left a comment

Choose a reason for hiding this comment

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

Looks good to me!

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.

3 participants