Closed
Bug 1153353
Opened 9 years ago
Closed 9 years ago
test push server for dom/push mochitests
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dougt, Assigned: dougt)
Details
In order to test push notifications in Firefox, it would be wonderful to be able to test against our own production push server. Currently, we have a docker image that has been deployed in releng infra. The mochitest are configured (via prefs_general.js) to point at this push server. The server can be started via the docker command: docker run -v /root/push/logs:/var/log/automock:rw -v /root/push/config/autopush_shared.ini:/etc/autopush_shared.ini -v /root/push/config/autopush_connection.ini:/etc/autopush_connection.ini -v /root/push/config/autopush_endpoint.ini:/etc/autopush_endpoint.ini -p 8081:8081 -p 8082:8082 kitcambridge/automock:0.2 Note, that we are using two ports: 8081 is a websocket connection. This allows Firefox to 'listen' to push notifications. 8082 is a http connection. This allows people to create a push notification to a particular device. Also note that the last part of the command is the version number (0.2). To update, you just need to kill the existing running instance, and change this value to whatever is the right version (See dougt or kitcambridge for details). There are 3 configuration files that should be mapped. In my setup, I put all 3 files in a /root/push/config directory: autopush_connection.ini =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- port = 8080 endpoint_scheme = http endpoint_hostname = 10.134.156.12 endpoint_port = 8082 Note, that the only thing that needs to change above is the endpoint_hostname. It must be the machine's ip that is running the docker image. autopush_endpoint.ini =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- port = 8082 cors = 1 No change required here. autopush_shared.ini =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ;ssl_key = /etc/autopush_keys/test.key ;ssl_cert = /etc/autopush_keys/test.crt Some day, if we wanted to support TLS, this is what we need to modify. This machine needs to be addressable by ALL testers or the mochitest dom/push will fail. In the prefs_general.js file (part of firefox testing), we have the following at or near the end of that file: // Enable Push user_pref("dom.push.enabled", true); user_pref("dom.push.testing", true); user_pref("dom.push.serverURL", "ws://10.134.156.12:8081"); The .testing flag enabled non-tls connections. The .serverURL should point at the push server. We may want to be able to change this so that people running mochitest outside of releng do not use this IP (and use the default). It would be good to ensure that this is production ready and fits nicely into what releng does wrt its infra.
Comment 1•9 years ago
|
||
From discussion in irc, it sounds like the best option might just be using the production push service and allowing releng hosts to talk directly to it from the datacenter and EC2. We want to make sure that we're not routing the EC2 traffic back through the VPC to the datacenter and then back out (both for traffic cost and for resiliency), so we'd need the static IP of the service so we could add it to the VPC routing tables. According to dougt the two hostnames are `push.services.mozilla.com` for wss, and `updates.push.services.mozilla.com` for causing a push event. After a bunch of CNAME redirection, push.services.mozilla.com resolves to ec2-54-148-192-75.us-west-2.compute.amazonaws.com which has IP 54.148.192.75. This looks like just one EC2 instance instead of a static IP or having it fronted by an ELB or something that we can scale/perform maintenance on as needed. Is this the IP we want to use, or is there something sitting in front of that that we should point at? updates.push.services.mozilla.com points at updates-push.prod.mozaws.net which has IP 52.10.158.14.
Assignee | ||
Comment 2•9 years ago
|
||
This has been fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Component: Tools → General
You need to log in
before you can comment on or make changes to this bug.
Description
•