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

Keep httpEndpoint valid #185

Merged
merged 8 commits into from
Aug 25, 2023
Merged

Keep httpEndpoint valid #185

merged 8 commits into from
Aug 25, 2023

Conversation

rquitales
Copy link
Member

@rquitales rquitales commented Aug 24, 2023

We do this by re-projecting the field into the TF provider (without logic) and then ensuring that the upstream provider never sees the field. This fixes #181.

We also:

  • Update pu/pu to v3.78.1 for the examples test package
  • Update the bridge to v3.57.0
  • Add a new test to ensure our fix works as expected.

@github-actions
Copy link

Does the PR have any schema changes?

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.

Maintainer note: consult the runbook for dealing with any breaking changes.

Fixes broken test options required for new test case.
@rquitales rquitales added the impact/no-changelog-required This issue doesn't require a CHANGELOG update label Aug 24, 2023
@rquitales rquitales requested a review from a team August 24, 2023 20:12
@rquitales rquitales marked this pull request as ready for review August 24, 2023 20:12
Copy link
Member

@iwahbe iwahbe left a comment

Choose a reason for hiding this comment

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

This is very similar to what caused us problems in with aws.rds.Instance. Could we remove the patch all-together and apply a similar solution to pulumi/pulumi-aws#2686 (keeping all of our code in resources.go).

This way there won't be any unintended interactions within the upstream provider.

This is an alternative strategy to restore an old field, and does not require a patch in
the upstream provider. Instead, we create the field in resources.go and make sure that if
a user sets it, we move it to `restEndpoint` (which the provider still has as valid).
@iwahbe iwahbe changed the title Add httpEndpoint field in Kafka Topic datasource Keep httpEndpoint valid Aug 25, 2023
@iwahbe iwahbe self-requested a review August 25, 2023 17:33
Copy link
Member

@iwahbe iwahbe left a comment

Choose a reason for hiding this comment

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

I'm approving to remove the "(requested changes)" from my review, but I would like a second pair of eyes before I merge.

Copy link
Contributor

@guineveresaenger guineveresaenger 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, thank you!

I have a personal preference to using the plain string as a lookup key rather than assigning to a const but it's definitely not a blocker 😄

provider/resources.go Outdated Show resolved Hide resolved
provider/resources.go Outdated Show resolved Hide resolved
@iwahbe iwahbe enabled auto-merge (squash) August 25, 2023 18:21
@iwahbe iwahbe merged commit 4441db3 into main Aug 25, 2023
14 checks passed
@iwahbe iwahbe deleted the rquitales/fix-patches branch August 25, 2023 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/no-changelog-required This issue doesn't require a CHANGELOG update
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ccloud.get_kafka_topic_output seems to always raise error 'Invalid address to set: []string{"http_endpoint"}'
3 participants