908467 - Protocol deprecation indicators: server support

Status: RESOLVED FIXED

(Cloud Services Graveyard :: Server: Sync, defect, P1)

Description

[Richard Newman [:rnewman]]

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.

Comment 1

[Toby Elliott [:telliott]]

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.

Comment 2

[Ryan Kelly [:rfkelly]]

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.

Comment 3

[Richard Newman [:rnewman]]

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

Comment 4

[James Bonacci [:jbonacci]]

What is the status of this work on the server side?

Comment 5

[Ryan Kelly [:rfkelly]]

I don't think we're getting a sync1.1 stage environment anytime soon...are we?

Comment 6

[James Bonacci [:jbonacci]]

Probably not ever.

Comment 7

[Ryan Kelly [:rfkelly]]

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.

Comment 8

[Bob Micheletto [:bobm]]

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

Comment 9

[Richard Newman [:rnewman]]

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

Comment 10

[Ryan Kelly [:rfkelly]]

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.

Comment 11

[James Bonacci [:jbonacci]]

Yep. It's kinda far down on my ToDo list, but it's there along with bug 908461

Comment 12

[Ryan Kelly [:rfkelly]]

This is well and truly in use and underway, closing out the bug