That would work. Good idea
On Mon, Apr 5, 2021 at 3:12 PM Robert Newson wrote:
>
> Several good points in there, Nick.
>
> How about a config toggle? A single config setting that decides if any
> endpoint exposes “erlangness” (so at least node names, pids or registered
> names). To be applied
Several good points in there, Nick.
How about a config toggle? A single config setting that decides if any endpoint
exposes “erlangness” (so at least node names, pids or registered names). To be
applied to active_tasks output also. Defaulting to true for compatibility.
> On 5 Apr 2021, at 17:17
The "node" field can be helpful in determining where the background
task runs even if nodes are not connected in a mesh. Nodes could still
be named something like replication_node_1, replication_node_2, etc.
Even in 3.x, the replicator doesn't rely on the nodes being meshed all
that much, the jobs
I support removing obsolete fields from responses.
I also support tracking API changes.
Donat
On Fri, Apr 2, 2021 at 10:23 PM Robert Newson wrote:
>
> +1 to removing “node” on main (but not 3.x branch).
>
> B.
>
> > On 2 Apr 2021, at 21:11, Ilya Khlopotov wrote:
> >
> > Hi,
> >
> > In FDB worl
+1 to removing “node” on main (but not 3.x branch).
B.
> On 2 Apr 2021, at 21:11, Ilya Khlopotov wrote:
>
> Hi,
>
> In FDB world there wouldn't be erlang mesh as far as I can tell. In this
> situation the `node` field in the response from `/_scheduler/jobs` and
> `/_scheduler/docs` doesn't
Hi,
In FDB world there wouldn't be erlang mesh as far as I can tell. In this
situation the `node` field in the response from `/_scheduler/jobs` and
`/_scheduler/docs` doesn't make sense.
We could either remove the field or set it to `None`. I propose complete
removal.
I also propose to est
