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

fix: retention period update buckets #25989

Conversation

NguyenHoangSon96
Copy link

@NguyenHoangSon96 NguyenHoangSon96 commented Feb 11, 2025

Closes influxdata/ui#1607

Fix the bug when updating the retention period of buckets:

  • Before fix: set a retention period, eg. 1 hour, then change to never -> the retention period is still 1 hour
  • After fix: set a retention period, eg. 1 hour, then change to never -> the retention period changes to never
  • Test case added
  • Issue Link
Screen.Recording.2025-02-12.at.15.30.26.mov
  • I've read the contributing section of the project README.
  • Signed CLA (if not already signed).

@NguyenHoangSon96 NguyenHoangSon96 self-assigned this Feb 11, 2025
@NguyenHoangSon96 NguyenHoangSon96 marked this pull request as draft February 11, 2025 07:05
@NguyenHoangSon96 NguyenHoangSon96 marked this pull request as ready for review February 12, 2025 08:34
@bednar bednar removed their request for review February 13, 2025 08:57
@philjb
Copy link
Contributor

philjb commented Feb 18, 2025

@NguyenHoangSon96 - are you ready for this PR to be reviewed?

@NguyenHoangSon96
Copy link
Author

@NguyenHoangSon96 - are you ready for this PR to be reviewed?

Hi @philjb
Yes, this PR is ready for review

Copy link

@wdoconnell wdoconnell left a comment

Choose a reason for hiding this comment

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

I have some concerns about making this a server-side as opposed to a frontend change. Tagging @jeffreyssmith2nd as I believe this is similar to a concern he raised.

@@ -210,6 +210,10 @@ func (b *bucketUpdate) toInfluxDB() *influxdb.BucketUpdate {
sgd := time.Duration(*rule.ShardGroupDurationSeconds) * time.Second
upd.ShardGroupDuration = &sgd
}
} else if len(b.RetentionRules) == 0 {

Choose a reason for hiding this comment

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

I think this would have the side effect of unintentional retention period changes.

This infers from len(b.RetentionRules) == 0 that the user is attempting to update the retention period. That will not always be the case, it seems. Based on the docs for bucket updates, and the BucketUpdate struct, it looks like the bucket-update-request is not restricted to changing retention periods: the user can also update the bucket name or description. In those cases, if a user tries to update the bucket name or description, this looks like it will set their retentionPeriod and shardGroupDuration to 0 even when they are not trying to update those fields. See related concern @jeffreyssmith2nd raised here:

If OSS was updated with the same behavior, users would silently have their retention changed which could lead to disk out of space errors, etc. I think it makes more sense for the UI to explicitly send a retention rule with a seconds of 0 and shard group of the default.

IMHO, the better place to fix this is actually in the UI repository. Annoyingly, we will need a forked implementation. As @wiedld identified here, the C2 backend implementation differs in that it translates a null retentionRule to 0, and passing an explicit 0 will result in an error, unlike the OSS implementation that requires an explicit 0. Below is some suggested pseudocode for an update that is more in line with how to resolve this on the UI side, when the DELETE - NEVER button is clicked:

 if (CLOUD) {
    [call API without retentionRules parameter in the request (retentionRules is `null`)]
    return
}

const retentionRules = [{type: 'expire' , everySeconds: 0}]
[call API with retentionRules payload - this will affect OSS only]

Copy link
Contributor

Choose a reason for hiding this comment

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

@wdoconnell Thanks for looking at this, and I agree 100%. Silently updating the retention in the background isn't the behaviour we're looking for. So I think the only right place it can be fixed is in the UI.

Copy link
Author

Choose a reason for hiding this comment

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

Hi guys
Thank you for your input. I will fix it on the front-end side.
But I have some questions. Which branch is influxdb2 cloud backend and which branch is for UI in the cloud?

@bednar
Copy link
Contributor

bednar commented Feb 26, 2025

Based on discussion, we’ve prepared another PR directly in the UI repository - influxdata/ui#7016

@bednar bednar closed this Feb 26, 2025
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.

5 participants