-
Notifications
You must be signed in to change notification settings - Fork 3.5k
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[feature request] call the autogenerated retention policy something other than "default" #3733
Comments
I am OK with this change. I am curious how we want to message this such that it doesn't cause too much problems in the field. It's a semi-breaking change. |
How about |
sure, I vote |
We're keeping it |
@pauldix I strongly disagree. This is a terrible name for documentation and training, and there's no defensible reason to keep it as such long-term. I understand it is a breaking change, but I need this for 1.0. |
If we're going to make a breaking change, I would make the change so that |
That works for me. Creating a database is an infrequent operation, and explicitly requiring the details avoids any confusion. @rkuchan @gunnaraasen what do you think about making |
#5166 is related to this discussion. I'm fine with requiring a user-defined retention policy on database creation. To make it easier, we could only require the duration. If no RP name or replication are provided, we could set the name to the string of the duration, e.g.
This would create a |
@gunnaraasen Full syntax:
If |
@pires it is, we're talking about making that the required syntax, which would be a breaking API change. |
I really don't want to go to 1.0 with this in place. It is very confusing for docs and tutorials. |
There are two changes discussed here:
I'm opposed to option 2. Option 1 is a breaking change to any code that assumes One idea to prevent the breaking change could be to automatically convert |
@jwilder I too am opposed to option 2. Users shouldn't need to grok RPs to make a database. However, I think the original decision to use I do like your idea of mitigating the breaking change, and I also agree that |
How about if the default is just a blank name or a missing retention policy and we rely on the database to fill in the name? We could then do a subtle name of |
@jsternberg Imagine the use case where data is initially written to the DEFAULT policy, but then later a new DEFAULT policy is set. How would the data in |
Ok, looking at the code a bit just changing the name should be really simple. The default retention policy for a database is stored with the database itself so the change won't affect currently existing databases. As long as the person omits the retention policy name, it will choose the correct one automatically as @beckettsean has said. The only change that needs to happen is a change to the parser for the default retention policy name and a change to the meta service for setting the default retention policy when one isn't specified. One thing I noticed when digging through the code was that the default retention policy name wasn't in a constant and was sprinkled around the code everywhere. I'm thinking of changing it to a constant variable but I'm not sure which package to put it in. Either way, I'll put up a change and we'll iterate over it until we're all happy. |
Sounds great! |
The default retention policy name is changed to "autogen" instead of "default" since it ends up being ambiguous when we tell a user to check the default retention policy, it is uncertain if we are referring to the default retention policy (which can be changed) or the retention policy with the name "default". Now the automatically generated retention policy name is "autogen". The default retention policy is now also configurable through the configuration file so an administrator can customize what they think should be the default. Fixes #3733.
The default retention policy name is changed to "autogen" instead of "default" since it ends up being ambiguous when we tell a user to check the default retention policy, it is uncertain if we are referring to the default retention policy (which can be changed) or the retention policy with the name "default". Now the automatically generated retention policy name is "autogen". The default retention policy is now also configurable through the configuration file so an administrator can customize what they think should be the default. Fixes #3733.
The default retention policy name is changed to "autogen" instead of "default" since it ends up being ambiguous when we tell a user to check the default retention policy, it is uncertain if we are referring to the default retention policy (which can be changed) or the retention policy with the name "default". Now the automatically generated retention policy name is "autogen". The default retention policy is now also configurable through the configuration file so an administrator can customize what they think should be the default. Fixes #3733.
The default retention policy name is changed to "autogen" instead of "default" since it ends up being ambiguous when we tell a user to check the default retention policy, it is uncertain if we are referring to the default retention policy (which can be changed) or the retention policy with the name "default". Now the automatically generated retention policy name is "autogen". The default retention policy is now also configurable through the configuration file so an administrator can customize what they think should be the default. Fixes #3733.
The default retention policy name is changed to "autogen" instead of "default" since it ends up being ambiguous when we tell a user to check the default retention policy, it is uncertain if we are referring to the default retention policy (which can be changed) or the retention policy with the name "default". Now the automatically generated retention policy name is "autogen". The default retention policy is now also configurable through the configuration file so an administrator can customize what they think should be the default. Fixes #3733.
The default retention policy name is changed to "autogen" instead of "default" since it ends up being ambiguous when we tell a user to check the default retention policy, it is uncertain if we are referring to the default retention policy (which can be changed) or the retention policy with the name "default". Now the automatically generated retention policy name is "autogen". The default retention policy is now also configurable through the configuration file so an administrator can customize what they think should be the default. Fixes #3733.
…tention policy name change since v1.0 (`autogen` instead of `default`). See: * https://docs.influxdata.com/influxdb/v1.0/administration/config#retention-autocreate-true * influxdata/influxdb#3733
…d with a retention policy of `autogen` instead of default. influxdata/influxdb#3733 Default has been changed to autogen so users have to set this variable if they have old databases that were created pre influxdb v1.0
New version of influxdb use "autogen" as default retention policy name. Please see influxdata/influxdb#3733 for more info. Change-Id: I8aeb47f60b3aeb022e0cd7aaac630d7cad5b0099 Closes-Bug: #1673914
New version of influxdb use "autogen" as default retention policy name. Please see influxdata/influxdb#3733 for more info. Change-Id: I8aeb47f60b3aeb022e0cd7aaac630d7cad5b0099 Closes-Bug: #1673914 (cherry picked from commit a914fb6)
It is a minor breaking change, but should eliminate a lot of confusion.
I don’t look forward to explaining over and over “Your default RP isn’t the
default
RP, you’ve sethourly
as the default. All writes go tohourly
by default.default
is not written to unless you explicitly write to thedefault
retention policy."Possible names from a Slack convo:
The text was updated successfully, but these errors were encountered: