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.