Page MenuHomePhabricator

[Sprint 11 GOAL] SDS 2.5.5 Deliver working prototype for MP Instrumentation Configuration
Closed, ResolvedPublic

Description

SDS 2.5.5 Hypothesis:

If we build a service for instrument configuration, we can deliver a prototype that is flexible enough to scale in order to integrate with our future experimentation flagging solution.

Architecture diagram:
https://miro.com/app/board/uXjVMtGrgVc=/?moveToWidget=3458764579792923671&cot=14

Tickets:

  • Development Environment Setup:
    • Create gitlab repos
    • Wire CI
    • Create helm charts
    • Setup documentation
    • Create Dev Docker Env(s)
    • Deployment for each app and extension
    • Setup monitoring and dashboards
  • Authentication
    • openid-client to authenticate users using CAS-SSO
    • We propose authenticating and authorizing users using OpenID Connect, implemented in openid-client, and CAS-SSO as the OpenID Connect Issuer. Because the app will not make API requests to any third parties, we propose implementing the Authorization Code Flow and storing the user identity, session ID, and an HMAC in an httpOnly session cookie (herein “the session cookie”).
  • Security review of openid-client
    • Has it already been security reviewed? >> T358115
    • Request new LDAP group for users of the app
    • Implement Authorization Code Flow in app
    • Implement post-auth flow LDAP group check
    • Implement generic Double Submit Cookie methods for use when displaying forms
      • Generate
      • Validate
  • Backend:
    • Wikimedia’s service-scaffold-node
    • Routing
      • see Instrument Configurator – Design Document
      • All routes require authentication and authorization except where noted otherwise.
    • Logging - mwbot to add entries to the SAL
    • Datastore - knex or pg to query the Data Products PostgreSQL cluster
      • Setup DB see T331516
      • Data Model
      • Access from
        • Backend API
        • Frontend Client
  • Frontend:
  • MediaWiki Extension
    • The Metrics Platform MediaWiki extension will implement a hook handler for the ESC hook. The hook handler will fetch the instrument configuration from the app (via the GET /api/v1/instruments route), adapt the response to match the expected format, and return the result.
    • Deploy the stub as soon as possible(important avoid two week delay)
    • Approval process for deploying everywhere?
    • Hook handler for the hook that EventStreamConfigs will use
    • Fetch instrument config from Backend API
  • EventStreamConfiguration
    • We will update ESC to be able to fetch stream configurations from other sources via a hook. ESC will be responsible for merging the stream configurations.
      • No deep-merge multiple stream configurations
      • Static configuration gets highest priority
  • Caching - Instrument Configurator – Design Document

Related Objects

Event Timeline

cjming updated the task description. (Show Details)
WDoranWMF claimed this task.