Global Gathering 2019 - Day 2 - Technical meetup


1. SysAdmin Standardization

  • We reviewed the sysadmin standardisation epic, the objective is to complete what we started back in Australia. There is a small issue missing: Move database.yml out of ofn-install

  • About Scandinavia, should we spend more time in it? We need to have a discussion with the whole team.

  • We need to migrate Austalia and Canada instances to ofn-install. Canada should be pretty straight-forward although we’re missing a schedule that we can communicate to Theresa. Australia needs a few things to deal with:

    • Check application.yml file
    • Deal with Feature Toogle and Feature Slug
    • Deal with log_before_timeout.rb. We decided we don’t need it.
  • No need of logrotate so far, it is integrated into backups. It’s an issue that is still in the backlog but outside of the scope of the standarization.

  • There are also specific setups on Katuma side:

    • Custom Reports: We’ll kill it ASAP.
    • HTTP Redirection: It can easily be merged into ofn-install and other instances could have their own.
  • About moving to Ubuntu 18.04 LTS, we could work on it later this year, last quarter. A playbook could be very useful. But before this, let’s deploy Canada and finish v2 roll-out. It’s worth working on the playbook while we’re at it.

2. Operations

  • Affiliates have global team support.
  • We could enhance communication between tech team and other teams, for better understanding of the devops issues.
  • It’s not 24/7 support, SysAdmin will do their best, the app is down for sometimes, you can still buy potatoes at the market :slight_smile:
  • We could improve the 500 error pages, for better communication to our users, to explain them our situation.
  • When there’s an operations problem, like one of those French downtimes, we create an issue like.

3. v2 Rollout plan

  • Done for Katuma:
    • Cache inconsistencies
    • v2.1.0 to go on
  • Next Belgium and Canada
  • Stop support for 1.3x (expect for S1 bugs)

More details in OFN v2 rollout plan

4. Performance action plan

  • Pagination issue
    • We are often loading all the data, it is too much.
    • We already use a gem for it.
    • Evaluate the different pagination implementations and come up with a standard way. The last one added and we’re happy with is the admin orders index.
    • In terms of UX the classic pagination with the numbers and prev/next might be less suited than a load-more style.
  • JSON serialization and injection
    • The issue is about insane data serialization that happens with AMS on some pages.
    • We need to fix the queries related to this, Matt has worked on it already. Sometimes is just about little tweaks.
    • We could also try replacing injection with API calls when reviewing slow pages. It might feel faster to load the page and request async than rendering it all.
  • Database issue
    • We are still missing indexes but we need to check monitoring to see which are we need to add. It can’t brainless.
    • We need to make the Postgres monitoring graphs work. Most of them show empty.
    • When working on specific pages, we need to check long queries and EXPLAIN them in order to optimize them. Skylight displays these per endpoint, while Datadog shows their impact on the DB server among other performance .details
  • Reports
    • Pau found out that the Order & Fulfilments report could be probably written in a single query quite easily.
  • After working on that one, we’ll see what we can do with the others and if it’s worth refactoring them.

5. Bye Bye Spree

@luisramos0 shared the agreements in Bye bye Spree :-) (or Spree v2.1 and beyond)

6. Security

  • Check for free trial.
  • Let’s do it to see where we are.
  • We will have gems vulnerabilities for sure, but also other insights.
  • It has affordable pricing so no need to hurry. We’ll create the issues for the vulnerabilities we can fix. If we need to review again, we can probably pay a subscription.
  • We’ll do a first run on a staging server and see what comes up.

7. About Metabase

  • We are wasting tons of time and resources on filling up spreadsheets while we could have more insights and in real time with a BI solution. I’d open up funding opportunities.
  • We need Static reports and also BI reports. We agreed that replication is mandatory for BI reports.
  • Luis talked about Talent which is a known ETL solution. He talked also of Kafka Event Sourcing, but maybe too early.
  • Talent could put all the data from all instances into a single database with a enterpriese_id column, and also simplify a lot the data modelization (denormalisation), helping people to use these data. The issue is the learning curve. There are lots of ETL solutions so it’d be good to investigate.
  • Metabase can be installed on one server while we replicate all instance DBs to that same server. The main issue is anonymization, which should be solved separately with something like Masquerade.
  • These replicated databases could then be used for Zappier and Reporting tools.

I may have missed information or copied mistakes, please tell me and I will update the post.