Hi All, Earlier today we had our weekly backed-focussed catchup and we talked about the following:
* We're aiming to have train-79 deployment complete by end of day, it got pre-empted by some other operational issues. It also contains a bug where the IP blocklist files are not populated on build, but get pulled in later during a periodic update. We decided this was not a blocker for the release since the lists are only used in monitoring mode for now. * The tags for train-80 will be made today, and it's looking like a low-complexity release from an ops perspective. * We've had to disable some datadog metrics due to the sheer volume of what was being sent. Depending on how much this reduces the data volume, we may need to do some additional review of our use of datadog, e.g. by not sending flow events or by sending fewer tags. * We talked a little about the auth-mailer, whether it needs to run as a standalone server process, and whether we'll proceed with the suggestion of merging it back into the main auth-server repo. The consensus seemed to be that yes, it's useful to have it run as its own server process, and yes, merging it would probably simplify things from a dev P.O.V. with little cost. * There was a surprisingly wide-ranging chat about l10n, and how to best include the latest translations into each deployment. The current scheme of using an environment variable to specify the l10n repo sha has given more flexibility, but it still means you have to rebuild the rpms to pick up any changes. One suggestion was to treat the translations as external data rather than as a code dependency, in a similar way to how we handle e.g. the maxmind geolocation data. Unfortunately this is complicated by the fact that we need the translations at build time, not just runtime. I suspect we'll have some more rounds of this discussion as me move more things over to docker. * We hope to be sending SMSs in production in the next release or two, so we talked about the mechanics of that for an ops perspective. The initial plan is to use a third-party service via simple API call, and you can see the WIP code at [1, 2]. * The last couple of days have seen a marked uptick in db requests to update an existing device record. We need to attempt a bit of user- agent analysis to see whether this is an early warning of changing traffic patterns in client code. * There's an ancient bug to enable pruning of expired tokens from the auth db [3] and after a bit of discussion, we decided to dust it off and try to push it through to completion. We'll follow up in github issues. * :jbuck noted that the oauth and profile servers seem to get much lower bang-for-our-buck in performance, requiring twice as many server instances to serve significantly fewer requests per second. We don't really have any clues as to why this would be so, but it was a good reminder to revisit this old bug on the topic at [4] Cheers, Ryan [1] https://github.com/mozilla/fxa-auth-mailer/compare/phil/send-sms?expand=1 [2] https://github.com/mozilla/fxa-auth-server/compare/master...phil/issue-1628 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1130193 [4] https://github.com/mozilla/fxa-profile-server/issues/181 _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
