1227279 - 200-inator service for FHR EOL

Status: RESOLVED FIXED

(Cloud Services Graveyard :: Metrics: Pipeline, defect, P1)

Description

[Wesley Dawson [:whd]]

This is a proposed solution to monitoring FHR after EOL, any concerns should be addressed here before implementation.

Ops has provisioning logic for services that return a single status code:

https://github.com/mozilla-services/puppet-config/tree/master/n_inator

The idea is we set up a 200inator fronted by an ELB, enable ELB logging, and use the logs for monitoring FHRv2 health. In this way we will discard the payloads but still have IP, UA and request path, which should be sufficient for monitoring (we would need an ELB log decoder, but the format is easy to parse). The overhead and cost of running the service would be small, and setting it up would also be easy.

Comment 1

[Richard Newman [:rnewman]]

Please make sure this works for both kinds of Bagheera requests -- upload and delete.

Is the timeline for this planned to be at the moment of EOL? Quietly returning 200s will make client failures less of an issue, avoiding costly retries.

Comment 2

[Wesley Dawson [:whd]]

https://github.com/mozilla-services/puppet-config/pull/1873/files
https://github.com/mozilla-services/svcops/pull/922/files

Living at https://fhr.dev.mozaws.net and https://fhr.r53-2.services.mozilla.com. The latter is the production server with the production SSL cert that will be cut over to once things have been tested.

Comment 3

[Thomas Huelbert]

closing as test is available, opening new bug for live cut over.