That would work. Good idea
On Mon, Apr 5, 2021 at 3:12 PM Robert Newson <rnew...@apache.org> 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 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 > >>>> > >>> >
