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

Open a route to http://runtime-binaries.pvt.build.mozilla.org/tooltool from community machines

RESOLVED WONTFIX

Status

Infrastructure & Operations
NetOps
P1
normal
RESOLVED WONTFIX
5 years ago
4 years ago

People

(Reporter: Callek, Unassigned)

Tracking

Details

(Reporter)

Description

5 years ago
Hey Guys, SeaMonkey is hoping to utilize tooltool and relevant manifests like MoCo projects at this time. (Bug 775539)

And failing a place for SeaMonkey to host the tooltool related files at the moment, and failing the creation of a public tooltool location (Bug 768879), I wonder if we can be granted access to the private one for the time being?

This would be the community VLAN in scl1->runtime-binaries.pvt.build.mozilla.org port 80
and community VLAN in scl3 -> runtime-binaries.pvt.build.mozilla.org port 80

If we need more restrictive we can grab for all the SeaMonkey IP's from inventory. (And I suspect calendar would want/need this too, soon, but it can be another bug/thought as well).

CC'ed catlee and dustin for any objections. Unsure if we need to rope in infrasec.

:Ravi, is this even *possible* with the build network restrictions?
(Reporter)

Comment 1

5 years ago
(bumping prio to 1, since the absense of tooltool atm for SeaMonkey is keeping us from succeeding to build on mac on trunk right now)
Priority: -- → P1
(Reporter)

Comment 2

5 years ago
I should note, if a route can be opened we'll need to setup a DNS entry that shows/points to the right place, *or* hardcode an IP if the host even works for it.

In theory, we could just have a CNAME in the community network that IP->points to runtime binaries, if the flows work right, I'm not too picky so long as it works ;-)
This is a .pvt.build.mozilla.org CNAME, and as such it is not public and should not be made public.  There are a few other binaries on there (outside of tooltool) too.

Bug 768879 is the right solution here.

In the short term, since you have access to the contents of the private tooltool repo, you could mirror the public files manually to some external, temporary spot.  That may be as simple as pre-seeding the tooltool cache on all of the SM slaves, or perhaps the master's built-in web server could be used.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 4

5 years ago
(In reply to Dustin J. Mitchell [:dustin] from comment #3)
> This is a .pvt.build.mozilla.org CNAME, and as such it is not public and
> should not be made public.  There are a few other binaries on there (outside
> of tooltool) too.
> 
> Bug 768879 is the right solution here.
> 
> In the short term, since you have access to the contents of the private
> tooltool repo, you could mirror the public files manually to some external,
> temporary spot.  That may be as simple as pre-seeding the tooltool cache on
> all of the SM slaves, or perhaps the master's built-in web server could be
> used.

Is anything in tooltool itself private? I forgot this domain hosted other binaries.
Not that I know of, but as discussed in that bug, it's quite possible that it will eventually contain such things.
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.