[Labs-l] RFC: Webtools setup

Mon Feb 18 00:51:43 UTC 2013

(anonymous) wrote:

> [...]

>>>>> Nova Resource:Webtools also proposes the public entry-point address to
>>>>> be http://web.wmflabs.org/TOOL. As I also said on the talk page, I would
>>>>> prefer tool(s).wmflabs.org. ;) Unfortunately, that went unnoticed. :(

>>>>> [...]

>>>> Sounds good to me, *but* we need to check if we can have a
>>>> catch-all DNS entry for *.wmflabs.org and still other ser-
>>>> vers in this domain.

>>> Wait-a-minute, you meant adding a dns entry *for each tool*??

>> No, I mean if we have a wildcard DNS entry for
>> *.wmflabs.org, we need to ensure that
>> non-webtools-project-1.wmflabs.org and
>> non-webtools-project-2.wmflabs.org are still reachable.

> No, I thought you wanted tools.wmflabs.org/$toolname but now I'm
> wondering if you wanted tools to be a variable,  ie.
> {$toolname}.wmflabs.org (which I don't consider a good idea, better to
> balance it from varnish)

Actually I misread Giftpflanze's proposal that suggested
tools.wmflabs.org/$toolname (i. e., just change the server
name from "webtools" to "tool(s)").  I'm not passionate
about {$toolname}.wmflabs.org, but it should be balanceable
just as well?!

> [...]

>> IMVHO, though, if developers want to work in a collaborative
>> environment, they have to collaborate.  If the world must
>> stop just because they think so, how will they handle issues
>> where they definitely need to wait for other humans?

> No, they don't want that. Those volunteers want to solve for us a
> problem that our software doesn't handle.
> It is our task to make that process easy and nice.

I disagree with this view.  There's no "we" and "them";
we're all volunteers (well, most of us :-)), and there's no
reason why a tool developer cannot wait a few minutes, while
at the same time an immediate reaction would put unnecessary
burden on administrators.  Even in areas where paid WMF em-
ployees/contractors wear the hat and you really could think
of developers submitting a patch to MediaWiki or requesting
a Gerrit repository as "customers" who should be fed and
pampered, we accept *much* longer response times.

In my experience developers in the Wikipedia sphere and es-
pecially on Toolserver are *very* patient, and before we op-
timize the processes for someone who loses interest in de-
veloping a tool after fifteen minutes, we should see how
many of them there really are.

> [...]

> I see now what you mean. Yes, it would be good to keep track of that,
> although I would prefer that it's stored in the same folder (repository)
> as the tool, instead of a different repository (and preferably
> enforced), to keep the dependencies with the tool.
> If we enforce it to go through puppet, we risk that it makes the process
> slow. If we make it work without the dependencies, some package may go
> silently breaking something. In both cases, the listed dependencies may
> get stale because the needed dependencies are fullfiled by other package.

> [...]

My reasoning to use Puppet is very simple: It was designed
for this use case.  If someone with the most rudimentary
knowledge of the WMF cluster wants to set up a new instance
or change its configuration, they will know to look in Pup-
pet for the details (and probably expect that's enough).
The syntax and semantics are known to many admins already,
and if not, learning it is useful as you can use this knowl-
edge elsewhere as well.  On the other hand, adding other
sources for dependencies makes the process more complex, it
doesn't tie in with the existing toolset, it needs to be
documented, new admins need to know about that, etc., etc.,
etc.

It's basically the same motivation for why we should use
Apache instead of Zeus :-).

Tim