test push server for dom/push mochitests



4 years ago
2 years ago


(Reporter: dougt, Assigned: dougt)


Firefox Tracking Flags

(Not tracked)




4 years ago
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:

port = 8080
endpoint_scheme = http
endpoint_hostname =
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.

port = 8082
cors = 1

No change required here.

;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://");

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.
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 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

Comment 2

3 years ago
This has been fixed.
Last Resolved: 3 years ago
Resolution: --- → FIXED
Component: Tools → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.