Let me take a step backwards. I accept that documentation may be out of date, wrong,
misleading, etc. Maybe I've been barking up the wrong tree because the out-of-date
documentation led me astray. These things happen as systems evolve.
So, what I want to do is develop and run web servers, written in Python/django, which can
access the database mirrors (the same databases that Quarry runs against) and also make
API calls. I need my users to be able to authenticate to my sever using their
<http://en.wikipedia.org/> credentials (i.e. via OAuth).
I'd really like that my development environment be as similar to the production
environment as possible. The more differences there are, the more complicated things
become. In other words, keeping the development environment on my laptop would be
If you were setting out to do that, how would you set up your development and production
environments, given the current state of Toolforge?
On Oct 7, 2020, at 8:16 PM, Roy Smith
On Oct 7, 2020, at 7:28 PM, Bryan Davis
<bd808(a)wikimedia.org <mailto:firstname.lastname@example.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> 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.
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
<http://dev.toolforge.org/>) instead of
the primary login host (login.toolforge.org
<http://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.
Wikimedia Cloud Services mailing list
Cloud(a)lists.wikimedia.org (formerly labs-l(a)lists.wikimedia.org)