Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Set elastic password and generate enrollment token #75816
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
Set elastic password and generate enrollment token #75816
Changes from 21 commits
97f799a
45c0080
d83f324
8e2c773
3b0ca34
6a4821f
8d0b281
6e1c717
8ad067f
1d40d0c
b5f464e
791c195
e1c996e
7a6b58b
eb0eae8
4c4c69e
5f9b007
cebdbc8
1a169c1
945bddb
faae76a
c8c0214
23d1b38
d56fac3
14395a8
19e228f
d28e251
d67d318
eb7e14b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
bound_address
->boundAddresses
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.
nit suggestion :
getEnoded()
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.
this error handling is now redundant.
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.
nit: redundant
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.
nit make this private as well
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.
That's merely preference, so just a nit. I wouldn't add these constructors only so that we can mock the method in tests. You can mock the object it returns instead
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 need real client in test to test the checkClusterHealthWithRetries
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.
Apologies, I don't follow this, can you elaborate ?
You use a real client in tests by doing
CommandLineHttpClient client = new CommandLineHttpClient(environment);
already. You are not usinggetClient()
for that. In fact, you are usinggetClient()
only with themock(CommandLineHttpClient)
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.
@BigPandaToo I think the point is that either you have a no-arg constructor with accessors that you can mock, or if the constructor takes args you can pass the mocks as args and avoid accessors altogether. There's no point in passing real objects as args to the constructor, but then mocking their accessors.
Hope this helps. Personally, I find it clearer to mock things (accessor methods) rather than have the production code use functions/suppliers instead of plain fields. But I'm OK either way.
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 don't think the parameter name is suitable.
We know that we're only going to set this parameter when the auto configuration runs in docker.
But this might change in the future, because what it does has actually nothing to do with docker. It's better to name it for what it does.
I suggest the name of "node-enrollment-token" or "include-node-enrollment-token".
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.
let's not have two variables of different type with almost the same name if we don't need to. You can simply have
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.
This is the first time I'm bringing this up.
It would be better if we collate all the individual lines into a big
String
that is then passed toterminal#print
.This way the tool shows output when everything is completely done, and no output if one of the calls fails part way. It's still technically possible to show parts of it but much less likely, especially to the human eye.
It also helps with reordering of the information, without reordering of the endpoint calls (ie keep the elastic password reset last).
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.
nit: I think we should have one big try-catch block with all the endpoint calling methods grouped inside. I think it is easier to follow this way.
Lets avoid swallowing exceptions. I know we're not going to show these to users in the first phase but it bothers me every time I see it, and it is distracting.
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.
Agree on having one block. But what do you mean by swallowing exceptions? We don't swallow them, just don't have custom messages
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.
->
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.
This doesn't really work.
The problem is that the
env.settings()
object doesn't contain the settings from the keystore.If you look at the
BaseRunAsSuperuserCommand#execute
preamble code (elasticsearch/x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/tool/BaseRunAsSuperuserCommand.java
Line 92 in 72ba4cd
Instead, you've chosen to build the environment every time you want to read the Secure Setting and then throw it out (the
readBootstrapPassword
method).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.
You can't pass a
SecureString
as the value infield()
, you need to use the char array here and wrap it in a SecureString later or calltoString()
on theSecureString
you already have