Protocol deprecation indicators: server support

RESOLVED FIXED

Status

Cloud Services
Server: Sync
P1
normal
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: rnewman, Assigned: rfkelly)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa+])

(Reporter)

Description

4 years ago
See Bug 895518 for details. This bug tracks sending appropriate headers and error responses in conjunction with either/both account provisioning or service-wide flags/rolling deprecations/whatever.
Whiteboard: [qa+]
(Reporter)

Updated

4 years ago
Blocks: 908461
I believe we'll do all of this (the X-Weave-Alert and the 513) at the Zeus level, so this should go straight over to operations.
(Assignee)

Comment 2

4 years ago
Hmm, I think I've lost track of the "spec" here, linked bug has some musings but no definitive protocol.  Is the following correct?

Soft EOL:  normal operation, but an X-Weave-Alert header that includes a JSON obect with code:soft-eol, like this:

    200 OK
    X-Weave-Alert: {"code": "soft-eol", "url": "blablah"}


Hard EOL:  all requests return a 503, with an X-Weave-Alert header that includes a JSON object with code:hard-eol, like this:

    513 GO AWAY
    X-Weave-Alert: {"code": "hard-eol", "url": "blablah"}


I agree it makes the most sense to do this in Zeus.  If we can work up some scripts to turn it on/off for a particular user, that will be helpful for testing the client-side code. May be a bit risky to try without a sync staging environment though.  :bobm thoughts?

:jbonacci the other option for testing would be to stand up a custom server with this logic switched on, let me know if you want to go that route.
(Reporter)

Comment 3

4 years ago
(In reply to Ryan Kelly [:rfkelly] from comment #2)
> Hmm, I think I've lost track of the "spec" here, linked bug has some musings
> but no definitive protocol.  Is the following correct?

[dev-doc-needed] :D

> Soft EOL:  normal operation, but an X-Weave-Alert header that includes a
> JSON obect with code:soft-eol, like this:
> 
>     200 OK
>     X-Weave-Alert: {"code": "soft-eol", "url": "blablah"}

Yup. I envision this on /info/collections.
 

> Hard EOL:  all requests return a 503, with an X-Weave-Alert header that

513...

> includes a JSON object with code:hard-eol, like this:
> 
>     513 GO AWAY
>     X-Weave-Alert: {"code": "hard-eol", "url": "blablah"}

Yup.


> I agree it makes the most sense to do this in Zeus.  If we can work up some
> scripts to turn it on/off for a particular user, that will be helpful for
> testing the client-side code. May be a bit risky to try without a sync
> staging environment though.  :bobm thoughts?

Definitely seems like something to do in stage :D

As mentioned in the meeting, this is kinda all part of a migration/EOL plan, for which a mutable Sync account store is needed, so might be worth doing the work if stage is dead.
(Assignee)

Updated

4 years ago
Blocks: 907479
(Assignee)

Updated

4 years ago
Assignee: nobody → rfkelly
(Assignee)

Updated

4 years ago
Blocks: 951986
What is the status of this work on the server side?
Priority: -- → P1
(Assignee)

Comment 5

4 years ago
I don't think we're getting a sync1.1 stage environment anytime soon...are we?
Flags: needinfo?(bobm)
Probably not ever.
(Assignee)

Comment 7

4 years ago
So our options include (1) DO IT LIVE and (2) run a little dev stack and try it out here.  We basically want to QA client behaviour here, right?  We could spin up a run-your-own server instance and hack the headers into there for testing.
(In reply to Ryan Kelly [:rfkelly] from comment #5)
> I don't think we're getting a sync1.1 stage environment anytime soon...are
> we?

We are not.  However, we did have some working AWS sync 1.1 nodes, and if it would be useful for this bug I can deploy it.
Flags: needinfo?(bobm)
(Reporter)

Comment 9

4 years ago
(In reply to Ryan Kelly [:rfkelly] from comment #7)
> So our options include (1) DO IT LIVE and (2) run a little dev stack and try
> it out here.  We basically want to QA client behaviour here, right?  We
> could spin up a run-your-own server instance and hack the headers into there
> for testing.

Yes, we want to QA client behavior, but also build a little reference manual and any necessary tooling for whoever is decommissioning Sync and needs to drive things.

For example, setting up the SUMO links, setting EOL responses in Zeus, monitoring traffic, etc. etc.
(Assignee)

Comment 10

4 years ago
Bumping this, we should test it out one way or another.  It'll become more important as we actually want to switch this thing off.
Yep. It's kinda far down on my ToDo list, but it's there along with bug 908461
Status: NEW → ASSIGNED
(Assignee)

Updated

4 years ago
Blocks: 1008066
(Assignee)

Updated

3 years ago
Blocks: 1014411
(Assignee)

Updated

3 years ago
No longer blocks: 1014411
Depends on: 1014411
Depends on: 908463
Blocks: 1014406
(Assignee)

Comment 12

2 years ago
This is well and truly in use and underway, closing out the bug
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.