Closed Bug 1302631 Opened 8 years ago Closed 7 years ago

add https support to trychooser

Categories

(Infrastructure & Operations :: RelOps: General, task)

task
Not set
normal

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!
See Also: → 833266
Assignee: nobody → relops
Component: Tools → RelOps
Product: Release Engineering → Infrastructure & Operations
QA Contact: hwine → arich
Flags: needinfo?(dustin)
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)
Okay, looping sfink in with a needinfo.
Flags: needinfo?(sfink)
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)
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)
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).
:arr: +1, i'll move it to today/tonight or tomorrow. i'll ping here when i'm done.
Flags: needinfo?(rgarbas)
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)
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)
Assignee: relops → rgarbas
> 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)
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)
Blocks: 1308723
Depends on: 1309259
: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)
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)
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.
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)
: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)
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
Why not add an actual 302 redirect, instead of using meta http-equiv="refresh"?
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.