Closed
Bug 776261
Opened 12 years ago
Closed 12 years ago
Open a route to http://runtime-binaries.pvt.build.mozilla.org/tooltool from community machines
Categories
(Infrastructure & Operations Graveyard :: NetOps, task, P1)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: Callek, Unassigned)
References
Details
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•12 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•12 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 ;-)
Comment 3•12 years ago
|
||
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
Closed: 12 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 4•12 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.
Comment 5•12 years ago
|
||
Not that I know of, but as discussed in that bug, it's quite possible that it will eventually contain such things.
Updated•11 years ago
|
Product: mozilla.org → Infrastructure & Operations
Updated•1 year ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•