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

Deprecate name on aws.rds.Instance #2686

Merged
merged 6 commits into from
Aug 11, 2023
Merged

Deprecate name on aws.rds.Instance #2686

merged 6 commits into from
Aug 11, 2023

Conversation

iwahbe
Copy link
Member

@iwahbe iwahbe commented Aug 9, 2023

Fixes #2682

We should have deprecated name in v5.x. We could then remove it here. Because we didn't remove it here, we need to deprecate it now, so we can remove at v7.0.0.

We want the following properties when we deprecate name:

  • Doesn't require a patch upstream.
  • name is deprecated in the schema.
  • name warns when used, directing the user to use dbName instead.
  • name is still valid as an input.
  • name is still valid as an output.

This PR works by back-porting name into the upstream schema from the Provider() tfbridge.ProviderInfo function. Since the upstream provider is no longer aware of name, we set dbName to the value of name and delete name. If both were provided, we error, just like v5.42.0 did.

As implemented, we get:

  • Doesn't require a patch upstream.
  • name is deprecated in the schema.
  • name warns when used, directing the user to use dbName instead.
  • name is still valid as an input.
  • name is still valid as an output.

To warn when we need to, we need to patch the bridge to allow passing a logger into PreCheckCallback. This change will be non-breaking.

@iwahbe iwahbe self-assigned this Aug 9, 2023
@github-actions
Copy link

github-actions bot commented Aug 9, 2023

Does the PR have any schema changes?

Found 1 breaking change:

Resources

  • 🟢 "aws:rds/instance:Instance": required: "name" property is no longer Required
    No new resources/functions.

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

if err != nil {
return nil, err
}
return applyTags(ctx, config, meta)
Copy link
Contributor

@guineveresaenger guineveresaenger Aug 9, 2023

Choose a reason for hiding this comment

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

Just to make sure I understand the logic here:

  • if a resource that hits this code path has a non-nil callback, we want to apply tags after applying the existing callback function to the config?
  • if a resource that hits this code path doesn't have a callback, or it is nil, we behave as before

Since rds.Instance is currently the only resource with an explicit callback, could there ever be a new PreCheckCallback that doesn't want this to happen?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah this just looks like "add a callback instead of replacing it".

Copy link
Member Author

Choose a reason for hiding this comment

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

If there is a callback, we give re-assign prov.Resources[key].PreCheckCallback so both the old callback and applyTags are called. Otherwise we just set applyTags.

If we introduce a new callback where we don't want this to happen, we can change this code. I don't expect that we will though.

Copy link
Contributor

@guineveresaenger guineveresaenger Aug 10, 2023

Choose a reason for hiding this comment

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

If there is a callback, we give re-assign prov.Resources[key].PreCheckCallback so both the old callback and applyTags are called. Otherwise we just set applyTags.

Makes sense!

If we introduce a new callback where we don't want this to happen, we can change this code. I don't expect that we will though.

How will a future maintainer know to change this code?
If we don't expect new callbacks to be introduced - should we use the resource name as an explicit trigger here?

Copy link
Member Author

Choose a reason for hiding this comment

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

How will a future maintainer know to change this code?

If a future maintainer wants to add a new PreCheckCallback to a specific resource that overrides the behavior of tags, they will notice their change is not working and investigate. It's all in this file. They can grep for PreCheckCallback in resources.go and find this.

If we don't expect new callbacks to be introduced - should we use the resource name as an explicit trigger here?

I'm not sure what you mean? Can you elaborate?

Copy link
Contributor

@guineveresaenger guineveresaenger Aug 11, 2023

Choose a reason for hiding this comment

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

they will notice their change is not working and investigate.

I don't think that is ideal. I think the design of PreCheckCallback invites one to think "oh neat, I can add a callback in this place, on a resource". Getting a surprise can be really frustrating, regardless of how easy it would be to grep for PreCheckCallback.

Can you elaborate?

If this particular callback is unique to rds.Instance, I think I would prefer logic that explicitly triggers on "if this resource is rds.Instance, use this callback". That will avoid a future maintainer having to look why something seemingly unrelated is getting involved with their callback.

I guess my TL;DR is: I don't think that "PreCheckCallback is not nil" is a discerning enough evaluation to decide whether we should call this code. Let's just use rds.Instance. After all, we would want to remove this on v7, correct?

@iwahbe
Copy link
Member Author

iwahbe commented Aug 9, 2023

We can get the warning we want easily after we merge pulumi/pulumi-terraform-bridge#1333.

// up in the schema. It is never observed non-nil by the
// upstream provider and we warn when you set it.

p.ResourcesMap().Get("aws_db_instance").Schema().
Copy link
Member

Choose a reason for hiding this comment

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

This is a little too interesting, you prefer this to having the upstream patch?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, because:

  • The totality of the change is well defined.
  • Its obvious to maintainers that it is a Pulumi change.
  • The code is next to PreCheckCallback which is it logically tied to.
  • There cannot be merge conflicts.

// Name doesn't actually exist on the underlying provider anymore,
// so we make sure it only sees `dbName`, not `name`.
config["dbName"] = name
delete(config, "name")
Copy link
Member

Choose a reason for hiding this comment

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

Yes!

@@ -489,7 +489,7 @@ public partial class Instance : global::Pulumi.CustomResource
public Output<bool> MultiAz { get; private set; } = null!;

[Output("name")]
public Output<string> Name { get; private set; } = null!;
public Output<string?> Name { get; private set; } = null!;
Copy link
Member

Choose a reason for hiding this comment

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

Interesting. Benign? This might be coming out of tfgen changes actually

Copy link
Member Author

Choose a reason for hiding this comment

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

This is real and correct. name is not set if the user correctly supplies dbName.

Optional: true,
Computed: true,
},
+ "name": {
Copy link
Member

Choose a reason for hiding this comment

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

Yes! Here we go, delete this one.

Copy link
Member

@t0yv0 t0yv0 left a comment

Choose a reason for hiding this comment

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

A few nits but 🚀 🚀 this looks just like what we want.

Any chance to attach how Pulumi responds to the failing example e.g. how the deprecation message looks like? Thank you!

@iwahbe iwahbe force-pushed the iwahbe/2682/depricate-name branch from 041c604 to e7a9a30 Compare August 9, 2023 14:01
@t0yv0 t0yv0 enabled auto-merge (squash) August 11, 2023 22:24
@t0yv0 t0yv0 disabled auto-merge August 11, 2023 22:24
@t0yv0 t0yv0 merged commit f158e81 into master Aug 11, 2023
15 checks passed
@t0yv0 t0yv0 deleted the iwahbe/2682/depricate-name branch August 11, 2023 22:25
@netum-ArturMalinin
Copy link

Hello, I noticed this PR as we are facing issues when upgrading from version 5.42.0 to 6.2.0 with Python.

Firstly, this warning is probably incorrect:
warning: name is deprecated: This property has been deprecated. Please use 'dbName' instead.

As there is no 'dbName' property here: https://github.com/pulumi/pulumi-aws/blob/master/sdk/python/pulumi_aws/rds/instance.py#L19-L81

Pulumi is also attempting to execute a replacement of the aws.rds.Instance in our case. This is probably not as intended?

When using the deprecated name property,Pulumi preview shows:
aws:rds:Instance **-*****-*** replace [diff: +dbName]; 2 warnings

If we change the name property to db_name, Pulumi preview displays:
aws:rds:Instance **-*****-*** replace [diff: +dbName]

If we don't set properties name or db_name Pulumi preview runs without any changes (update/replace) to the RDS instance.

@t0yv0
Copy link
Member

t0yv0 commented Sep 21, 2023

I'm sorry you are running into this. Could you please open a new issue, this will help my team prioritize looking at this! Thank you!

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.

RDS Instance replacement when upgrading to 6.0
4 participants