-
Notifications
You must be signed in to change notification settings - Fork 155
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
Conversation
Does the PR have any schema changes?Found 1 breaking change: Resources
Maintainer note: consult the runbook for dealing with any breaking changes. |
if err != nil { | ||
return nil, err | ||
} | ||
return applyTags(ctx, config, meta) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
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(). |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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!; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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": { |
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
08fde9b
to
041c604
Compare
041c604
to
e7a9a30
Compare
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: 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 When using the deprecated name property,Pulumi preview shows: If we change the name property to db_name, Pulumi preview displays: If we don't set properties name or db_name Pulumi preview runs without any changes (update/replace) to the RDS instance. |
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! |
Fixes #2682
We should have deprecated
name
inv5.x
. We could then remove it here. Because we didn't remove it here, we need to deprecate it now, so we can remove atv7.0.0
.We want the following properties when we deprecate
name
:name
is deprecated in the schema.name
warns when used, directing the user to usedbName
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 theProvider() tfbridge.ProviderInfo
function. Since the upstream provider is no longer aware ofname
, we setdbName
to the value ofname
and deletename
. If both were provided, we error, just likev5.42.0
did.As implemented, we get:
name
is deprecated in the schema.name
warns when used, directing the user to usedbName
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.