On Oct 7, 2020, at 7:28 PM, Bryan Davis
<bd808(a)wikimedia.org> wrote:
This may actually be the root of some of your frustrations. Toolforge
is not meant to be a replacement for a development environment on your
local laptop or other server.
Hmmm. That's not the impression I got from reading what's available on wikitech.
It's called a "developer account". Pages like
https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge
<https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge> say things
like, "If you already know these basics, then you are ready to start developing
tools!" So, it sure sounds like it's supposed to be a development environment.
And
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Developing_successful_to…
<https://wikitech.wikimedia.org/wiki/Help:Toolforge/Developing_successful_tools>
says:
Pick the right development environment
If you will be doing heavy processing (e.g., compiles or tool test runs), please use the
development environment (
dev.toolforge.org) instead of the primary login host
(
login.toolforge.org) so as to help maintain the interactive performance of the primary
login host.
which is at odds with your statement that it's not meant to be a development
environment. Yes, I keep several tmux sessions nailed up. It makes life easier and I
assumed it would be a very small impact on the system. As for:
a python process that appears to be some sort of TCP
log event sync.
That's exactly what it is. Tailing a NFS log file is not practical. I opened a phab
ticket on this <https://phabricator.wikimedia.org/T256426> which got triaged to a
low priority. Fair enough, so I found a workaround. The process you're seeing is
essentially a private syslog server I'm running. My k8s web server process logs to
that, bypassing NFS. I don't need that running when I'm not actively debugging,
so I'll shut it down now. It didn't seem like the kind of thing that would be
imposing any significant load.