1101447 - Move /push-server-config to Push APIs

Status: RESOLVED WONTFIX

(Hello (Loop) :: Server, defect)

Description

[Tarek Ziadé (:tarek)]

This API endpoint is supposedly used by the client to get a list of Push endpoints 
Right now its just a static config file in the Loop server. 

I do not uderstand the benefit for this indirection. It adds deployment complexity with no apparent benefits.

I think we should simply store the endpoint in the client (and also offer a way to configure it in about:config - so developers can point Hello to a specific push server.)

If we're keeping it nevertheless, I propose that we move this API under Push responsability - so *they* can decide (and make evolve) what to send back to the client.

Comment 1

[Tarek Ziadé (:tarek)]

Maire, if you have a bug filed for adding the push endpoint in about:config, can you link it here ? thx!

Comment 2

[Alexis Metaireau (:alexis)]

This bug comes after a discussion we had this morning with the team (Tarek, Remy and I) and we agreed this is something that needs to evolve. The reason we currently have this indirection level is so that the server drives the channel that will be used for simple push.

Having the client ask directly to the SP cluster makes sense, and avoids an indirection (no need to ask loop-server to do the lookup and then return).

Plan is to:

1. Have Simple Push expose a similar API to know which server needs to be chosen;
1. Make the client ask directly the simple push cluster what is the push endpoint to use;
2. Once this is used by all the clients, drop the /push-server-config endpoint.

I'm NI Adam here since he's the one who designed at first the push-server-config endpoint, and Ben as he's driving the SP effort.

Comment 3

[Ian Bicking (:ianbicking)]

The idea behind the indirection was that we may, on the fly, want to change the SimplePush/LoopPush cluster that new clients use, as a form of balancing.  I think this basic purpose of /push-server-config still remains.  However, it makes sense for that config to be owned by the people managing the LoopPush cluster, as they are the people who might want to change it (and maybe on short notice).

I think the location of /push-server-config should become its own configuration value, and point that at a new location TBD.

Comment 4

[Mark Banner (:standard8)]

This may affect what we do on bug 1094433, so linking these together.

Comment 5

[Adam Roach [:abr]]

(In reply to Alexis Metaireau (:alexis) from comment #2)
> This bug comes after a discussion we had this morning with the team (Tarek,
> Remy and I) and we agreed this is something that needs to evolve. The reason
> we currently have this indirection level is so that the server drives the
> channel that will be used for simple push.
> 
> Having the client ask directly to the SP cluster makes sense, and avoids an
> indirection (no need to ask loop-server to do the lookup and then return).
> 
> Plan is to:
> 
> 1. Have Simple Push expose a similar API to know which server needs to be
> chosen;
> 1. Make the client ask directly the simple push cluster what is the push
> endpoint to use;
> 2. Once this is used by all the clients, drop the /push-server-config
> endpoint.
> 
> I'm NI Adam here since he's the one who designed at first the
> push-server-config endpoint, and Ben as he's driving the SP effort.

This is reasonable at a high level.

I do want to point out that the original comment to this bug kind of misses the key behavior for this endpoint: the idea was to have a *list* of URLs, which were returned randomly, not just one URL. I recall reading the code and determining that this was coded correctly, and that we're just using a list of one right now.

It's perfectly sensible to hand this responsibility off to the push servers, but we want to be very careful about how we make the transition. All versions of Firefox up until Bug 1055145 lands (currently scheduled for 37) are going to fall back to the services.push.serverURL value if there's an error trying to get /push-server-config from the Loop server.

So what we really need to do here is (in strict order):
1) Stand up a /push-server-config endpoint (or something similar) on a push server cluster somewhere.
2) Change the Loop server /push-server-config endpoint to send a 308 (or, if that causes problems, 301) response that redirects to the new location
3) Change the loop client to use the new location (using a configuration value, as Ian suggests in comment 3)
4) After the number of hits on the Loop server /push-server-config endpoint drop to a low enough level that we're comfortable doing so, we can turn the redirect off.

Comment 6

[Ben Bangert [:benbangert]]

I think it'd be good to move this URL to be under the control of ops.

Comment 7

[Rémy Hubscher (:natim)]

(In reply to Ben Bangert [:benbangert] from comment #6)
> I think it'd be good to move this URL to be under the control of ops.

Actually this is already the case because the content of this URL is a loop-server only configuration change.

Comment 8

[Maire Reavy [:mreavy]]

(In reply to Tarek Ziadé (:tarek) from comment #1)
> Maire, if you have a bug filed for adding the push endpoint in about:config, can you link it here ? thx!

See Bug 1104733

Comment 9

[Rémy Hubscher (:natim)]

The key behavior is to be able to configure the loop-push endpoint.

The plan is:

 - To have a prefs in Firefox with the push endpoint. (Bug 1104733) so that the user can configure its loop-push websocket endpoint.

 - If the prefs is empty or undefined, call the /push-server-config endpoint which will return a list of endpoints or make a HTTP 301/308 to another endpoint that returns that list.

 - One of this list is then used to set the about:config parameter.

Ben — Do you have an HTTP endpoint on loop-push cluster yet that can give us a list of loop-push endpoints?

Comment 10

[Adam Roach [:abr]]

(In reply to Rémy Hubscher (:natim) from comment #9)
>  - To have a prefs in Firefox with the push endpoint. (Bug 1104733) so that
> the user can configure its loop-push websocket endpoint.

Just to make sure -- the only purpose of this is as an obscure "nerd knob" that allows people who really, really know what they're doing to set an override, right? In other words, this won't be populated during the normal course of operation, and it will be unset for typical users.

If that's not the case, then we need to have a conversation about the issue Ben raises in Bug 1104733 comment 10.

Comment 11

[Rémy Hubscher (:natim)]

> the only purpose of this is as an obscure "nerd knob" that allows people who really, really know what they're doing to set an override, right?

Isn't it the case for all about:config prefs?

For me it is not a big deal if we call /push-server-config each time we need to open a Loop-Push websocket. Also I like the DNS option.

Comment 12

[Ben Bangert [:benbangert]]

Ok, so the current plan is to fully abandon the use of a URL that a client hits to get a list of servers. Instead there will be a single DNS name that loop-push can use (which I filed a ticket for).

Rather than having ops manipulate a HTTP URL to return different clusters, ops will run a script that updates the DNS round-robin entry with servers in *any* cluster that have open connection availability.

The ticket for ops to setup this new DNS name is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1122176

Once the name is ready, loop-client should switch to using that name, with the assumption that it will always result in locating a usable loop-push machine.

I think it'd be useful to expose this name in about:config, so that its easy for QA to test since they could then easily change it to one of our staging/dev deployments.

Comment 13

[Rémy Hubscher (:natim)]

Ok so we can keep our endpoint and point it to the DNS server and let it handle the rest of the flow.

Settings as WONTFIX on the server side then.

For me Bug 1104733 is still relevant because it let the power user define her own push endpoint if she wants.