2015.09.16 review of Programs

Owned by Ned Batchelder (Deactivated)
Last updated: Nov 23, 2016 by Mark Haseltine (Deactivated)
5 min read
Collected action items:

Attendees:
in-room: Joel, Peter, Ned, Andy, Jim, Nimisha, Clinton, Ed, Mark, Zach
hangout: Felipe, Cale, Dave

  • Questions collected from the review document:
    • Open questions (fundamental)
      • is this big enough for an IDA? [joel]
      • feature flags: Waffle vs ConfigurationModel [andy]
      • replicating users into Programs [andy]
      • database ids vs synthetic ids [andy]
      • course vs course_key/course_id meaning run [nimisha]
    • Open questions (programs)
      • Can existing/closed/archived course runs be linked to a Program? [peter] NO
      • multi-LMS? [peter] NO
      • soft deletions? [andy]
      • error recovery and frequency of async signals from LMS to Programs [will]
      • new opaque keys? [andy]
      • API: public or private? [nimisha]
      • constancy of programs: "If someone passes a program with v1 of course1 and another student passes the program with v231 of course1 is that the same program?" [ed]
      • /organizations/: integer id? [clinton]
      • child orgs? [ed]
      • roles for Program Admin UX in studio? [peter]

  • Is this big enough for an IDA?
    • jim: "borderline", things get bigger once you roll them out.
    • things could move out of the LMS into here.
    • joel: is this just the first part of a larger IDA?
      • Can we imagine what that IDA would be, instead of "Programs"?
      • Renaming it is fine.
    • is there another IDA in the works which would logically be part of this?
      • certificates perhaps
      • "course about" project? Not an IDA, an API in the LMS
      • "organizations" app? Not an IDA
    • Criteria for IDA:
      • Is it useful to have an LMS without Programs? yes.
      • Django apps are another option
        • Always in-process model
        • or, more elaborately, an optional in-process model.
      • We have lots of in-process Django apps
        • Optional in-process: known examples use deep baked-in frameworks or languages to hide the network/in-process switch.
    • "Is grouping courses fundamental enough that doing it in an IDA will be more of a problem than a help?"
    • How far are we from being able to deploy django apps installed with edx-platform?
      • ed: very complex question requiring touching lots of things
        • asset pipeline
        • wheel deployment
        • test latency
        • etc
        • lots of cross-cutting efforts that need to converge
        • definitely months of calendar time
    • Classic IDA tradeoff:
      • in-process ties you to edx-platform deploy schedules
      • in-process is easier to debug
    • [ ] Mark will schedule a discussion about how to decide what is an IDA and what is not.
  • Waffle vs ConfigurationModel
    • Tracking changes: waffle doesn't do that.
    • Waffle is tied to the session
      • so might not be appropriate for API use
    • Clinton has used waffle flags, not waffle switches.
    • This needs to get solved.
      • Needs one DevOps and one Engineer to sit down and work it out.
      • Does waffle replace feature flags?
      • Rationalize how Waffle and ConfigurationModel coexist
      • [ ] Mark will schedule Cale and Ed to work it out.
    • Why not both? They do different things.
  • Replicating users into Programs
    • Jim: data isn't really replicated, the id and a pointer to another source is stored.
      • this is needed for foreign keys
    • this is due to lacking a user service.
      • if we want to relate users to courses, we need user data in our db for foreign keys,
      • and because Django relies on the user table.
    • this isn't really replication, it's a pointer back to the real source of truth.
    • most of these tables exist in the LMS
    • would all of this be much easier running in-process?
      • yes, because we'd have access to the LMS models
    • it's a tradeoff:
      • separation and isolation,
      • but have to have copies of some data.
    • What has to be kept up-to-date between the source and the copy?
      • existence: records should be one-to-one
      • whatever comes over in the JWT is stored
      • user names: are they immutable?
        • we get requests for changing user names, but we never(?) change them.
        • user anonymous id is immutable
        • there's a per-course anon id, and a global anon id.
        • oops: none of our other APIs use anonymous id
      • user names have always been considered immutable,
        • but this feels wrong
        • some feel that immutable user names are good
        • multi-tenancy would really benefit from separating the visible user name from an internal immutable id.
        • everyone agrees that getting to mutable user names is a lot of work
      • JWT can adapt to future ids
    • Decided: we'll keep the status quo (replicated pointers to users elsewhere), but some are uncomfortable with it.
    • Perhaps only admin users need to be stored locally?
      • Students are not accessing the UI directly.
      • The student-facing API for JavaScript could be built without Django permissions.
    • [  ] Jim will look into only storing admin users.
  • Database ids vs human-readable slug for programs and organizations
    • Decided: Jim will slugify
  • Course independent of run:  what do we call it?
    • edx.org will be getting a course page, independent of course runs.
    • self-paced courses: what is the run?
    • [  ] Jim will gather people to decide on the terminology. Include marketing
  • Can existing/closed/archived course runs be linked to a program?
    • [  ] Open question: how do we get old XSeries into this system?
  • Not multi-LMS.
    • How to store pointers to users if multi-LMS.
    • Single LMS only
    • Felipe has a prototype of separating users into multiple databases
    • How hard would it be to add an LMS column to the tables?
      • this is not for MVP
      • but straightforward enough
  • Microsites: will this work with them?
    • Programs would have to add a column to their data so that series could be subsetting by microsite.
    • [  ] Figure out how to support microsites in Programs.
  • Soft deletions:
    • this slowed down teams significantly, so they removed it.
    • Keep soft deletions, but keep an eye out.
  • Signals from LMS to Programs to keep sync'd data up-to-date
    • There will be a management command to sync data completely
      • this will be used initially, and then to recover from outages.
    • [  ] Include this in performance testing
    • if the signal is too frequent, we can make a new less-frequent signal 
  • New opaque keys?
    • could opaque keys be used for slugifying programs?
      • "programv1" would be a key identifying a program
    • [  ] Jim will investigate and decide whether to use opaque keys
  • Public API or private?
    • Matt is in charge of our public-facing APIs.
    • Not every API needs to be public.
    • This was designed to be private.
  • Constancy of programs:
    • Jim wants to keep it simple.
    • This is really a product question
    • This is the same problem with certificates: two students can earn "the same" certificate, but the courses they took were different.
    • [  ] Zach will talk to product about it.
  • What role is needed for Program administration?
    • For MVP, global staff.
    • And it will be part of E-commerce, not Studio.