REST high-level client: add support for split and shrink index API#28425
REST high-level client: add support for split and shrink index API#28425javanna merged 6 commits intoelastic:masterfrom
Conversation
|
@olcbean maybe you want to have a look too ;) |
olcbean
left a comment
There was a problem hiding this comment.
LGMT! I left few comments : mostly nits.
There was a problem hiding this comment.
Thanks for reformatting ;)
There was a problem hiding this comment.
Maybe HttpPut.METHOD_NAME instead?
There was a problem hiding this comment.
I think it would be better to call toLowerCase as the index should be lowercase ( or generate randomIndicesNames )
There was a problem hiding this comment.
Can this be replaced by randomCreateIndexRequest()? Or maybe removed ?
There was a problem hiding this comment.
no, resize supports only a couple of sections compared to create index (aliases and settings only). I think it is better to set only those specifically.
There was a problem hiding this comment.
My bad !
But I do not see it being used here. Did you mean to set it as target?
There was a problem hiding this comment.
it should be set within the method, that is why we pass in the request, otherwise we'd have to return a List<Alias> and set them one by one as the request doesn't accept a list of alias directly.
There was a problem hiding this comment.
I am afraid I am missing something ...
I am not sure why createIndexRequest in initialized but not used in the resizeRequest : I would have expected to see something like :
resizeRequest.setTargetIndex(createIndexRequest) ?
Currently it seems that the targetIndexRequest is always null regardless of the randomization
There was a problem hiding this comment.
ops. thanks for being persistent on this :)
There was a problem hiding this comment.
@tlrx should we add assertBusy here ( the same as for create and delete ) ? Or here it is not needed ?
There was a problem hiding this comment.
I think that this is OK here because the test framework will wait for pending cluster state updates to be processed before executing the next test and resize action is based on cluster state updates.
There was a problem hiding this comment.
I don't know about this, we don't do it in other tests, not sure that we need it?
There was a problem hiding this comment.
Ops : there is not validation of the index names here
There was a problem hiding this comment.
assertBusy : same as above ?
tlrx
left a comment
There was a problem hiding this comment.
This looks great! I left many comments but most of them are really minor.
There was a problem hiding this comment.
Nit: can we change the message to something like "Wrong resize type [..] for indices split request"?
There was a problem hiding this comment.
Should we check that the target index is not null at this stage?
There was a problem hiding this comment.
we already check this in the validate method, which the high level client calls internally.
There was a problem hiding this comment.
Yes, I know but I was thinking we could be more defensive. On the other side there's no reason this method would be reused somewhere else so let's keep it like this.
There was a problem hiding this comment.
Do we expect this test to be executed against something else than a single node cluster?
There was a problem hiding this comment.
I am not too sure about this. I was under the impression that it could be either 1 or 2, but not too sure.
There was a problem hiding this comment.
I think it's always a single node cluster, but I'm good to keep it like this.
There was a problem hiding this comment.
Do you have an objection in using XContentMapValues.extractValue() ?
There was a problem hiding this comment.
I feel a bit bad about adding another random stuff generator class in the test framework :(
There was a problem hiding this comment.
why? we need it in both the client tests and core tests after all. Maybe you have a better name in mind perhaps?
There was a problem hiding this comment.
Nit: sometimes there's a point at the end of the line, sometimes not
There was a problem hiding this comment.
Nit: could we add some empty lines or anonymous blocks around start/end object to make the object creation easier to read?
There was a problem hiding this comment.
Maybe add more doc about the randomized parts( aliases, settings, mappings only)?
7fbe26a to
de78192
Compare
|
thanks @tlrx I have addressed your comments |
There was a problem hiding this comment.
Not for this PR but we might want to rename restHighLevelClient to client here
1f91579 to
0a1fb6c
Compare
Relates to #27205