Closed
Bug 1302631
Opened 8 years ago
Closed 7 years ago
add https support to trychooser
Categories
(Infrastructure & Operations :: RelOps: General, task)
Infrastructure & Operations
RelOps: General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: glob, Assigned: garbas)
References
()
Details
(Keywords: trychooser)
in order to embed trychooser within mozreview (bug 1173842, bug 1295306) trychooser needs to be served over https to avoid mixed content issue. please add https support to trychooser. thanks!
Updated•8 years ago
|
Assignee: nobody → relops
Component: Tools → RelOps
Product: Release Engineering → Infrastructure & Operations
QA Contact: hwine → arich
Updated•8 years ago
|
Flags: needinfo?(dustin)
Comment 1•8 years ago
|
||
The trychooser is just a bit of JS, so you could serve it on any https domain. https://github.com/mozilla/build-tools/tree/master/trychooser It's probably easiest to just "vendor" that in mozreview. That said, I think sfink owns trychooser, so he may be the best person to talk to.
Flags: needinfo?(dustin)
Comment 3•8 years ago
|
||
Hah! It's good to see people taking philor's words *more* seriously than they should, for once. For the record, I don't "own" trychooser any more than anybody else. (Well, depending on what you mean by 'trychooser'. I own the perennial out-of-date hg trychooser extension. I do not own the trychooser web UI, and I make no effort to keep the job configuration there up to date, though I did write most of its current logic. I do not own the try syntax parsing in either buildbot or taskcluster, though I am to blame for writing/modifying much of the awful buildbot code.) But if you want opinions, I can do that! Serving http://trychooser.pub.build.mozilla.org/ over https seems like it's just an IT issue, or whoever manages that server, and this request should be redirected there. The job taxonomy information should probably be brought in tree around now. I wrote up a long rambling thing here, but moved it to new bug 1303770.
Flags: needinfo?(sfink)
Comment 4•8 years ago
|
||
I believe that, by design, none of the pub.build.mozilla.org sites do ssl. Those are all on one vhost, secure.pub.build.mozilla.org. rok: is this something that you'd want to move to heroku/cloudfront/aws vi mozilla-releng.net?
Flags: needinfo?(rgarbas)
Comment 5•8 years ago
|
||
Since trychooser is a static site, it would also be fine if it were served from secure.pub.build.mozilla.org/trychooser or something (in addition to being served from trychooser.pub.build.mozilla.org).
Assignee | ||
Comment 6•8 years ago
|
||
:arr: +1, i'll move it to today/tonight or tomorrow. i'll ping here when i'm done.
Flags: needinfo?(rgarbas)
Assignee | ||
Comment 7•8 years ago
|
||
i've created 2 pull requests - https://github.com/mozilla/build-tools/pull/27 (to remove trychooser) - https://github.com/mozilla-releng/services/pull/60 (to move it into mozilla-releng/services) at one point it would be nice to rewrite trychooser into elm (now that i think about it this would be a nice first code somebody could learn how to write elm). trychooser should be available on: - https://mozilla-releng.net/trychooser - https://staging.mozilla-releng.net/trychooser :dustin: am i missing something when i'm removing trychooser? is there any automation that is expecting trychooser to be there?
Flags: needinfo?(dustin)
Comment 8•8 years ago
|
||
build/tools is an hg repo, I believe? http://hg.mozilla.org/build/tools The deployment code on the releng web cluster expects trychooser there. I assume moving it into releng services makes that unnecessary? I don't think anything else is using it, but I am not sure -- people do crazy things :) I'm curious why you are using a sub-path for trychooser, rather than trychooser.mozilla-releng.net?
Flags: needinfo?(dustin)
Updated•8 years ago
|
Assignee: relops → rgarbas
Assignee | ||
Comment 9•8 years ago
|
||
> The deployment code on the releng web cluster expects trychooser there. I > assume moving it into releng services makes that unnecessary? > where can i find this deployment code (github, some hg repo)? > I'm curious why you are using a sub-path for trychooser, rather than > trychooser.mozilla-releng.net? releng_frontend (mozilla-releng.net) is (becoming) already a collection of smaller frontend interfaces. trychooser will be just one more. for now trychooser i just copied it, but i'm keeping it on the list of projects where somebody could brush their elm skills. /me self notes - fix deployment code of releng web cluster - redirect from old domain to https://www.mozilla-releng.net/trychooser
Flags: needinfo?(dustin)
Comment 10•8 years ago
|
||
The code is under (my memory..) /data/src/releng/trychooser on relengwebadm Note that https://mozilla-releng.net doesn't work, just www :(
Flags: needinfo?(dustin)
Assignee | ||
Comment 11•8 years ago
|
||
:dustin: For some reason redirect is not possible? https://bugzilla.mozilla.org/show_bug.cgi?id=1301677#c24 ... Any idea how we could setup certificates differently to have this?
Flags: needinfo?(dustin)
Comment 12•8 years ago
|
||
It's not an issue of certificates -- the problem is not using a subdomain. The name `mozilla-releng.net` has to use A records, not CNAMEs, which means that it can't use any of the cloud-based load-balancing systems. I expressed a similar concern in comment 8. When we had initially discussed setting this up, the idea was to use a microservices architecture with each service at a different domain name, which gives you the ability to shuffle services around, for example putting some behind cloudfront, some on heroku, etc. That said, I'm definitely not in the loop here. I assume you had good reasons to choose the single-hostname solution, and bug 1301677 contains some possibilities for making that work.
Flags: needinfo?(dustin)
Comment 13•8 years ago
|
||
I made the same argument. We should only be using subdomains and not the TLD because we have no way to use CNAMEs and A names introduce a single point of failure in a datacenter.
Reporter | ||
Comment 15•7 years ago
|
||
is https://www.mozilla-releng.net/trychooser/ now the authoritative location for trychooser? ie. are updates from the repo being deployed there? we still have a copy of trychooser as part of the mozreview repo, and i'd like to stop doing that.
Flags: needinfo?(rgarbas)
Assignee | ||
Comment 16•7 years ago
|
||
:glob: yes. New location is https://mozilla-releng.net/trychooser. Code was moved here https://github.com/mozilla-releng/services/tree/master/src/releng_frontend/src/trychooser and will be at some point rewritten into Elm (https://github.com/mozilla-releng/services/issues/122) and this reminds me a need to push trychooser so that redirect gets activated.
Flags: needinfo?(rgarbas)
Assignee | ||
Comment 17•7 years ago
|
||
The redirect was merged into build/tools repo and I just triggered the update for trychooser. http://trychooser.pub.build.mozilla.org/ now redirects to https://mozilla-releng.net/trychooser/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment 18•7 years ago
|
||
Why not add an actual 302 redirect, instead of using meta http-equiv="refresh"?
Assignee | ||
Comment 19•7 years ago
|
||
2 reasons: - I want users to see that the redirect is happening. Even if for a second. - I could do it on my own without bugging anybody.
You need to log in
before you can comment on or make changes to this bug.
Description
•