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.

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.

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.

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

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

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

Probably not ever.

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.

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

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

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