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

r/redshift_cluster: Nest all logging fields #2230

Merged
merged 1 commit into from
Nov 9, 2017

Conversation

radeksimko
Copy link
Member

@radeksimko radeksimko commented Nov 9, 2017

This is to make the schema aligned more with the API and also to leave some name space for future new fields.

Test Results

screen shot 2017-11-09 at 12 00 53

@radeksimko radeksimko added the enhancement Requests to existing resources that expand the functionality or scope. label Nov 9, 2017
Copy link
Contributor

@tombuildsstuff tombuildsstuff 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 comments - otherwise LGTM 👍

Optional: true,
Computed: true,
Deprecated: "Use enable in the 'logging' block instead",
ConflictsWith: []string{"logging"},
Copy link
Contributor

Choose a reason for hiding this comment

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

would it make more sense to make this logging.0.enabled?

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 think there's no harm in conflicting with the whole logging block. Either they use deprecated field or the whole new block. I'd rather not deal with mix of deprecated and non-deprecated fields. 😉

logging, ok := d.GetOk("logging.0.enable")
_, deprecatedOk := d.GetOk("enable_logging")

if (ok && logging.(bool)) || deprecatedOk {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you want to check the value of enable_logging, rather than that it's set to a value?

Copy link
Member Author

Choose a reason for hiding this comment

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

As it is a boolean field it shouldn't matter, b/c it will always be present - that is in fact why we introduced d.GetOkExists, secondly I intentionally left the implementation as is since it will be deprecated eventually.

Schema: map[string]*schema.Schema{
"enable": {
Type: schema.TypeBool,
Required: true,
Copy link
Contributor

Choose a reason for hiding this comment

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

does this not need a State Migration?

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 don't think so - it's only required within the context of logging block, i.e. you can't define an empty logging {}, it shouldn't affect any existing configs without this block.

@radeksimko radeksimko merged commit 67f2aa5 into master Nov 9, 2017
@radeksimko radeksimko deleted the f-redshift-reshuffle-schema branch November 9, 2017 14:00
@ghost
Copy link

ghost commented Apr 10, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!

@ghost ghost locked and limited conversation to collaborators Apr 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement Requests to existing resources that expand the functionality or scope.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants