If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED

Status

Release Engineering
General
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: dustin, Assigned: dustin)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

7 years ago
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)
(Assignee)

Updated

7 years ago
Assignee: nobody → dustin
(Assignee)

Comment 1

7 years ago
I'd like to get some feedback on this before I go asking for subdomains from server ops, etc.
Summary: dedicated build-internal web-services system → [tracking bug] dedicated build-internal web-services system

Comment 2

7 years ago
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
(Assignee)

Comment 3

7 years ago
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.
(Assignee)

Updated

7 years ago
Depends on: 629477
(Assignee)

Updated

7 years ago
No longer depends on: 629477
(Assignee)

Comment 4

7 years ago
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"?
Summary: [tracking bug] dedicated build-internal web-services system → [tracking bug] point to internal tools from http://build.mozilla.org

Comment 5

7 years ago
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.
(Assignee)

Comment 6

7 years ago
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

7 years ago
Please don't make any more public urls on build.m.o until it's renamed.
See bug 604688.
(Assignee)

Updated

7 years ago
Depends on: 604688
(Assignee)

Comment 8

7 years ago
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.
No longer depends on: 604688
(Assignee)

Comment 9

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.