-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Enforce limitations on ILM policy names #35104
Enforce limitations on ILM policy names #35104
Conversation
For consistency, ILM policy names must now follow the same rules as index names.
Pinging @elastic/es-core-infra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gwbrown I left some comments
...k/plugin/core/src/main/java/org/elasticsearch/xpack/core/indexlifecycle/LifecyclePolicy.java
Outdated
Show resolved
Hide resolved
...gin/core/src/test/java/org/elasticsearch/xpack/core/indexlifecycle/LifecyclePolicyTests.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are still discussing on #34928 whether or not this is the right restriction to apply, if any. Please do not merge this until that discussion is resolved.
Marking this as WIP for now as more review is pointless until we decide on a higher-level direction. |
} | ||
int byteCount = 0; | ||
try { | ||
byteCount = policy.getBytes("UTF-8").length; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is cleaner: name.getBytes(StandardCharsets.UTF_8)
and then there is no need to catch UnsupportedEncodingException
.
Also I think that utf-8 should always be available in a Java runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left one small comment but otherwise this LGTM
} | ||
if (policy.charAt(0) == '_') { | ||
throw new IllegalArgumentException("invalid policy name [" + policy + "]: must not start with '_', '-', or '+'"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would be nicer for the user if we just have a single message here that describes all the characters that we don't allow in a policy name? This might avoid frustration if the user tries something like _foo bar
as the policy name since they will be able to fix everything in one step rather than two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only if we don't end up with something too complicated. As-is, it's simple to read and validate that it follows the rules when encoded this way. The rules aren't so onerous that I expect any and certainly not multiple to be broken on a routine basis, they will be the exception. We can document the rules in the ILM API guide too, that would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking it would be ok as
"invalid policy name [" + policy + "]: must not start with '_', '-', or '+'" and must not contain any spaces or `,`."
But I don't feel too strongly about this, I agree the likelihood of multiple violations is low since there are too many rules here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue that's harder to consume for the case of a single violation (the common case contingent on any violation) as now as a user I am left wondering, wait, which rule did I break?
It's like those awful password dialog boxes. Password doesn't meet the required criteria:
- must be between 8 and 16 characters on Monday--Friday
- must be between 7 and 17 characters on weekends
- contains none of !@*&#
- contains at least two of ()_+-
- contains at least four digits
- contains at least one upper-case letter
- contains at least two lower-case letters
- not contain three of the same character
- not contain any adjacent repeating characters
- not contain adjacent consecutive digits or letters
- unless in reverse order
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok lets leave it as is then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I'm on board with leaving this as separate messages.
- This particular message was out of date, I've updated it to only say that policy names cannot start with
_
(the other characters are okay).
Now ILM is merged into master and 6.x we should label the PRs with |
My understanding, and is how we've been operating in CCR, is that we should also leave the version labels off of these as they show up in the weekly changelog otherwise. We want to continue to not report these individual changes until after the feature is delivered. (They are meaningless until then.) |
I am ok with that approach for now given thats how the weekly changelog works but I think we should discuss how this should be for the future as I think its useful to be able to see on PRs what versions a change went into quickly regardless of whether the PR is listed on changelogs/release notes |
Let's offline that, that's not germane to this PR. |
Enforces restrictions on ILM policy names to ensure we don't accept policy names the system can't handle, or may reserve for future use.
Enforces restrictions on ILM policy names to ensure we don't accept policy names the system can't handle, or may reserve for future use.
Enforces restrictions on ILM policy names to ensure we don't accept
policy names the system can't handle, or may reserve for future use.
As of now, the limitations are:
_
,
(as we allow comma-separated names in e.g.GET _ilm/one,two
- currently you canPUT
, but notGET
a policy named
contains,comma
as far as I can tell, althoughother special characters work fine)
Resolves #34928
For consistency, ILM policy names must now follow the same rules asindex names.
I ended up copying most of the logic, as there was a little bit of index-specificcode in the original, and also it felt weird to call intoMetaDataCreateIndexService
from here. If anyone strongly objects it would be possible to do this without any
duplication, though, with only minor tweaks to the index-name checking code.