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 start independently on each node based on how _replicator doc shards are distributed.
A few more thoughts around it: * If we're going to remove "node", should we also remove the "pid" field? It seems odd to have one but not the other... * One of the reasons node and pid were added to _scheduler/* endpoints was to eliminate the need for the users to ever look in _active_tasks to check the status of their replication jobs. In other words, having to tell a user "if you want stats look in _scheduler/jobs, but if you want to find the node look in _active_tasks". * What about _active_tasks and "node" and "pid" there? Both view indexing and replication jobs have those fields, should we remove them too? So I think overall I am neutral (-0) on the idea. I can see how it may be odd to have those internal details in there to start with, but I am not sure meshing alone is a good reason either way. And if we're going to do it, it may be better to be consistent with "pid" and "node" and in regards to _active_tasks as well. (As a fun aside, the node and pid was once helpful in our test environment in discovering that a different kube cluster was picking up and executing indexing jobs due to a misconfigured [fabric] fdb_directory config. Both clusters were sharing the same FDB cluster underneath). Cheers, -Nick On Fri, Apr 2, 2021 at 6:00 PM Bessenyei Balázs Donát <bes...@apache.org> wrote: > > 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 <rnew...@apache.org> wrote: > > > > +1 to removing “node” on main (but not 3.x branch). > > > > B. > > > > > On 2 Apr 2021, at 21:11, Ilya Khlopotov <iil...@apache.org> 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 make sense. > > > > > > We could either remove the field or set it to `None`. I propose complete > > > removal. > > > > > > I also propose to establish a formal process to track API changes > > > formally. Sooner or latter we would need to compile list of changes > > > between versions. In case of a rewrite on top of FDB I suspect the > > > archeology process wouldn't be easy. We could create a github issue > > > template which would set necessary labels for example. > > > > > > Best regards, > > > iilyak > > > > >
