Add gateway endpoints for exporter disable request

[deepthidevaki]

Add gateway endpoint to disable an exporter by its id. We should also add a way to monitor the progress of the operation. To be discussed if we should reuse the endpoint for cluster (scaling, force configure etc..) or define a new one specific for exporting or a general configurations.

[deepthidevaki]

Currently we have two related endpoints

• actuator/exporting/ for pausing an resuming exporting
• actuator/cluster for monitoring cluster configuration changes and the topology

For the new endpoints for enabling and disabling exporters

Proposal 1

POST actuator/exporters/{exportId} to enable // Here we also have to specify which other exporer to initialize from
DELETE actuator/exporters/{exporterId} to disable. We are not technically deleting the exporter. It remains in the config.

Proposal 2

POST actuator/exporters/enable/{exporterId} // Here we also have to specify which other exporer to initialize from
POST actuator/exporters/disable/{exporterId}

Proposal 3

POST actuator/exporters/{exporterId} 
{
 state: "enabled"
 initializeFrom: "otherExporterId"
}

POST actuator/exporters/{exporterId} 
{
 state: "disabled"
}

Monitoring

Users can also monitor the state of exporters and also monitor when enabling or disabling request is completed.

Proposal 1

We can reuse the endpoint for the cluster
GET actuator/cluster that respond with the full ClusterConfiguration including the ongoing change.

Proposal 2

Define a new endpoint
GET actuator/exporting or GET actuator/exporters that respond with only relevant fields from ClusterConfiguration including the ongoing change.

If going with this approach, we have to decide what should be included in the response for GET actuator/cluster.

@npepinpe Any suggestions?

[npepinpe]

I see a third proposal for the modification: PATCH /actuator/exporters/{exporterId}/disable . By definition, PATCH is for partial updates, POST and PUT typically would expect the full body (except PUT would be idempotent). That said, I understand most people use POST as a default, so I'm also fine with that 🤷

But I don't have a super strong opinion between this and the second proposal. I would opt against the first however, as I think it's more confusing than anything, and it prevents us in the future from, say, deleting exporters entirely 🙃

As for monitoring, I like the idea of the new endpoint - I think it's more intuitive. But we could start with an iterative process: first we include the new info in the response we get from the existing cluster monitoring endpoint. Then as a second iteration purely for UX, we can add a new endpoint just for exporters.

[deepthidevaki]

PATCH or POST /actuator/exporters/{exporterId}/disable sounds good to me. But, one problem here is that it is not really restful. The best practice says we should not put any verbs in the rest url. Semantically it should be accessing or updating resources.

Alternatives restful urls for similar operations suggested here are

PATCH /actuator/exporters/{exporterId}
{ op: disable }

This is similar to Proposal 3 above.

OR

POST /actuator/exporters/{exporterId}/activation  => adding activation = activate or enable
DELETE /actuator/exporters/{exporterId}/activation => deleting activation = deactivate or disable

[deepthidevaki]

@npepinpe and me discussed briefly the query endpoint for monitoring the state of exporters. The idea is that it could return and aggregated state instead of per partition per broker state of each exporters. So something like

{
  "exporterA": {
     "state": "enabled"    // enabled | disabled | enabling | disabling
  },
 "exporterB": {
    "state": "disabling"
  }
}

I will open another issue for this.