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

bigtable_gc_policy: Adding support for duration lower than day #7879

Merged
merged 7 commits into from
Dec 23, 2020

Conversation

eraac
Copy link
Contributor

@eraac eraac commented Nov 24, 2020

Allow GC policy to have a duration lower than a day, bigtable supports GC policies down to the hour. In case one day the support go to minutes/seconds the code will be already good

bigtable: added support for specifying `duration` for `bigtable_gc_policy` to allow durations shorter than a day

Signed-off-by: Kevin Labesse <kevin@labesse.me>
@ghost ghost added the size/s label Nov 24, 2020
@ghost ghost requested a review from slevenick November 24, 2020 15:44
Copy link
Collaborator

@slevenick slevenick left a comment

Choose a reason for hiding this comment

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

Is there another way we could handle this? Potentially adding new fields and calculating the max age policy depending on which is set? We need to handle this without adding a new required field at least until 4.0.0 is ready to release

google/resource_bigtable_gc_policy.go Outdated Show resolved Hide resolved
@slevenick
Copy link
Collaborator

So, the existing tests pass using the seconds field, but using the days field seems to be causing errors for me. It seems to always be producing a duration of 0 even when days is set to real values.

google/resource_bigtable_gc_policy.go Outdated Show resolved Hide resolved
@@ -257,3 +267,17 @@ func generateBigtableGCPolicy(d *schema.ResourceData) (bigtable.GCPolicy, error)

return policies[0], nil
}

func getMaxAgeDuration(values map[string]interface{}) (time.Duration, error) {
d, ok := values["seconds"]
Copy link
Collaborator

Choose a reason for hiding this comment

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

Terraform will default the value of seconds to 0 if it is unset (because int is a primitive value I believe). This prevents us from telling if seconds is set to the value 0, or unset. ok will always be true because of this, causing this code to return a duration of 0 seconds if days is specified.

Because 0 is an invalid duration, we should probably assume that a value of 0 is equivalent to seconds not being set.

On that note, we should enforce validation on the seconds field to make sure users set a positive int value. This could look like ValidateFunc: validation.IntAtLeast(1000) or some similar value

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've change the type to string and use time.ParseDuration, and set a validation function

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, that won't quite work either. Changing the type of the days field will cause existing user configs to stop working, which would be a breaking change.

I think what we want is to set them back to ints, set the ValidateFunc on the seconds field, to make sure anyone who specifies it enters a number greater than 0. Then we can assume that a 0 value is the same as unset, and use the value for days instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, I'm dumb ... furthermore I've update only the half of the reference to second ...

Anyway, days stay a int and the new field duration accept a valid duration (in string). If duration is set use it, otherwise fallback on days

Copy link
Collaborator

@slevenick slevenick left a comment

Choose a reason for hiding this comment

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

Looks like validation fails:

1 error occurred:
  * resource google_bigtable_gc_policy: ExactlyOneOf: max_age configuration
block reference (max_age.0.days) can only be used with TypeList and MaxItems:

I think that the ExactlyOneOf needs to be on the days block rather than the max_age block

Copy link
Collaborator

@slevenick slevenick left a comment

Choose a reason for hiding this comment

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

Thanks! I've added a couple fixes on the upstream build, they should be included once that PR is merged

@ghost
Copy link

ghost commented Jan 23, 2021

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. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Jan 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants