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

Add err checks on aggregate on fw_v2 resources #1592

Closed

Conversation

nikParasyr
Copy link
Member

Add error checking on aggregate types for fw_v2 resources based on best practises

@nikParasyr
Copy link
Member Author

@kayrus I noticed that err checks were added on #456 but they are just logged. Do you recall the reasoning?

@kayrus
Copy link
Collaborator

kayrus commented Jun 29, 2023

Do you recall the reasoning?

Not really...

BTW, There is a special TF_SCHEMA_PANIC_ON_ERROR=1 env variable that allows to panic on Set to catch such issues. See #601

d.Set("status", group.Status)
d.Set("region", GetRegion(d, config))

if err := d.Set("ports", group.Ports); err != nil {
diag.Errorf("Unable to set ports for openstack_fw_group_v2 %s: %s", group.ID, err)
Copy link
Collaborator

Choose a reason for hiding this comment

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

shouldn't we return the diag.Errorf? And does it make sense to check all Set err codes?

Copy link
Member Author

Choose a reason for hiding this comment

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

shouldn't we return the diag.Errorf?

yes

And does it make sense to check all Set err codes?

Only the aggregate types (schema.TypeList, schema.TypeSet, and schema.TypeMap)
but we probably want to standardize this. We are logging it in various resourcess, but not in all

Copy link
Collaborator

Choose a reason for hiding this comment

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

There is also a change to set Bool to String and String to Bool ;)

Copy link
Member Author

Choose a reason for hiding this comment

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

I set TF_SCHEMA_PANIC_ON_ERROR=1 on all ci in #1593 and everything passed. From various docs i found that it was defaulted to 1 when TF_ACC is set on sdkv2. So probably we were able to catch all the possible issues on the ci.

I'm not sure whether we want to implement this tbh. We have it in some resources but not all, and it is just logged. I came across it while going through the docs and I recalled the checks werent added of fw resources.
I think i'll close the PR as it is a more "generic" issue, to standardize the check.

I wonder what could be a good way of standardizing this. I checked a bit the aws provider and they only check for attributes they flatten etc. Checking all aggregate types + Bool + String seems quite an overkill to me.

Not sure how you feel but the aws approach seems good to me. Checks the attributes with the highest possibility of being wrong, but doesn't add 100s of checks on all kind of attributes.

@nikParasyr
Copy link
Member Author

BTW, There is a special TF_SCHEMA_PANIC_ON_ERROR=1 env variable that allows to panic on Set to catch such issues. See #601

I'm reading that this is enabled by default on sdkv2. But i'll trigger a ci pipeline to see what we get

@nikParasyr nikParasyr closed this Jul 26, 2023
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.

None yet

2 participants