Mike,
> 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.
Agree, I like having the .../state part in the API it feels more restful
and easier to understand. Interacting between stopping the shard splits
globally per cluster and for each individual jobs hopefully won't be too
confusing.
I haven't added state transition history yet. That's a larger change
> 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.
I just added that ability, it wasn't that hard overall. So now there is an
ability to stop and resume individual jobs and the API is
_shard_splits/jobs/$jobid/state with GET and PUT
{"state":"running"|"stopped", "reason":...} bodies.
Cheers,
-Nick
On Thu, Jan 31, 2019 at 4:59 AM Mike Rhodes <couc...@dx13.co.uk> wrote:
> 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.
>
