618109 - [tracking bug] point to internal tools from http://build.mozilla.org

Status: RESOLVED FIXED

Description

[Dustin J. Mitchell [:dustin] pronoun: he]

We have a number of private web services, and are building more (slave allocator).

Catlee mentioned in bug 614629 that we need a place to host such things *within* the build network.  Cruncher is sorta serving this purpose right now, but it's not a good place for it.

I'm thinking of
  http://webservices.build.mozilla.org
and also hosting potentially hefty services at vhosts to make it easier to move them if the need arises, e.g.,
  http://stackwalker.build.mozilla.org
(realizing this service is dead - just an example)

Comment 1

[Dustin J. Mitchell [:dustin] pronoun: he]

I'd like to get some feedback on this before I go asking for subdomains from server ops, etc.

Comment 2

[Mike Taylor [:bear]]

What was wrong with bug 617129 that a new bug is needed, or if this is a tracking bug then the conversation shouldn't happen, IMO, in this bug but the other 

Also, you are asking for decisions when we, at least from what I can see, we haven't hashed out internally all of the items

Once we know internally what the starting services are, what systems they are based on and what the breakdown is between internal/external then I think we can go to IT with a single set of requests

Comment 3

[Dustin J. Mitchell [:dustin] pronoun: he]

Bug 617129 is about an external server.  This one is about an internal system.  The two will have very different requirements in terms of accessibility to us, infrasec, etc.

I'm asking to hash things out, then for decisions.  I only mentioned server ops, etc., because someone suggested I request the subdomain and that seemed premature.

So you can think of this as "find a beefier replacement for cruncher" if you'd like.

Comment 4

[Dustin J. Mitchell [:dustin] pronoun: he]

I'm going to re-purpose this to list the build-internal tools on build.mozilla.org, with appropriate annotations so outsiders are not surprised they can't access them.  Maybe that means a separate "internal.html"?

Comment 5

[Mike Taylor [:bear]]

The security part of me wants to say "no" to this - anything that is a link to a web interface to an internal system may not be protected because of the buildvpn assumption.

Having link to private services on a web page that is public viewable is an "H4cK M3 M04R" sign just inviting trouble.

Comment 6

[Dustin J. Mitchell [:dustin] pronoun: he]

We could condition displaying the links on the source IP.  I'm not much for security by obscurity, especially in an open environment like ours.

Comment 7

[Aki Sasaki [:aki]]

Please don't make any more public urls on build.m.o until it's renamed.
See bug 604688.

Comment 8

[Dustin J. Mitchell [:dustin] pronoun: he]

Oops, sorry, this bug is for *internal* services, which should also be renamed.  Bug 614629 is for external interfaces.  Let's concentrate there for now, since self-serve and BuildAPI are the topics du jour.

Comment 9

[Dustin J. Mitchell [:dustin] pronoun: he]

So we've been solving this by adding a VM for each service, e.g., slavealloc.  This will probably apply to external services, too, and we'll just proxy them via build.mozilla.org.