$customHeader
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.
  • No labels
$customFooter