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, Nick Vatamaniuc <vatam...@gmail.com> wrote: > > 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 >>>> >>>
