Closed stephen-soltesz closed 2 years ago
From mlab-staging unified downloads daily count - verifying the web100_static update is WAI.
From measurement-lab unified uploads after deployment to production/public views.
Evidently, the v2 pipeline parsers in production are using the default value of the annotatorURL: https://github.com/m-lab/etl/blob/master/cmd/etl_worker/etl_worker.go#L71 which targets mlab-sandbox by default...
These requests should be no-ops (just burned cycles) and corrected by https://github.com/m-lab/etl/pull/1078 But, this was unexpected/unintended cross-project configuration and must be resolved before deleting the annotation-service in sandbox.
To complete:
I have confirmed that the only IPs accessing the annotation-service according to the request logs are from GKE nodes in mlab-oti. No other requests are directed to the /batch_annotation
resource.
After deploying https://github.com/m-lab/etl/pull/1078, the production v2 pipeline is no longer targeting the mlab-sandbox annotation-service.
There are no requests to the annotation service in mlab-staging or mlab-oti either. So, it should be safe to delete this service now..
After staging deployment of above PRs, I've confirmed downloader_last_success_time_seconds
is still in staging prometheus after deleting the old downloader from data-processing-cluster. Also confirmed updates in gs://downloader-mlab-staging.
Since deleting the v1 data pipeline components, the burn rate has reduced ~$6k/day
\o/ - Fin.
downloader
service todata-processing
cluster with v2 pipeline.