Nick,
I missed out the core point I was trying to make in my last mail: all my
suggestions are around framing the API around the internal state machine that
the shard splitting implementation uses.
I think the internal state machine is relatively simple to understand and,
importantly, document -- and exposing it directly will hopefully make the API
feel more natural. While this is exposing implementation to an extent, I feel
that it's unlikely to change massively, and if it did, other APIs would not
insulate the user from this.
I've a couple of further comments below, but in the main I think that generally
considering how to frame API operations in terms of the internal state machine
is the thrust of my opinion here.
On Wed, 30 Jan 2019, at 16:48, Nick Vatamaniuc wrote:
> Ah good call. I like the /_shard_split/state and { "state":
> "stopped/started", "reason": "maintenance ticket 1234" } as a way to change
> it.
>
> Previously I had used a PUT to change the state but I see you suggest a
> POST. Wonder about the difference. My reasoning was that a PUT modifies the
> state as opposed to creating new child state so to speak.
I think you are correct that `PUT /_shard_split/state` is appropriate.
> There is no way to control the job state individually currently. Shard
> splitting as a whole is stopped and it would reflect in the job state when
> queried. I can try adding the ability to stop a job individually. Then a
> POST (though I am inclined to go with PUT as discussed above) to
> ../$jobid/state with a {"state":"running"/"stopped", "reason":"..."} would
> work.
I think it's necessary to have some way to cancel a shard splitting operation
via the HTTP API: people make mistakes when entering commands and being able to
safely back-out is important.
--
Mike.
