Attendees

Materials

Agenda and Notes

• SIG Recap - Features and prioritization discussed at last meetings
  • Dynamic Profiles and Apply profile without requiring special content type in the request
  • Composites
  • Deployment modes and routing
  • API Logging

• API connection for Read Replica
  • Education Analytics - Open ticket requesting implementing ODS-5648
    • Most of our projects are in writing stage
    • Once in steady state, more people will want to read data out
    • Will be helpful to have separate database for read access
  • Stephen
    • Is there a plan to replace nHibernate with Dapper
    • Vinaya - replacing nHibernate with Dapper may not be required for this change
      • SF - Possibly, this change be easier while replacing nHibernate ORM
      • https://www.enterprisedb.com/blog/taking-advantage-write-only-and-read-only-connections-pgbouncer-django
  • EdWire
    
    • We implement read and write replicas by using Azure stackers
    • Azure has SQL pool that allows read and write out-of-box
      • https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tier-business-critical?view=azuresql
    • We implement this currently with separate API containers
      • One connects to read and write
      • Other connects to read replica
    • Just need to change connection string to access the read only replica
      • Routing needs to specify districts read-only
    • Education Analytics - This exists in AWS also
    • EdWire - We have used read replicas (not with the API) with SQL managed instances for reporting purposes
    • Vinaya
      • Switch to read replica connection needs to happen at the request level, while SQL reads to hydrate nHibernate model during a write operation should connect to the primary read-write database.
      • We need to investigate the memory footprint with two nHibernate object models.
  • Education Analytics
    • Even with two separate containers Memory cost would increase.
    • Vinaya - How is the connection string different?
      • Pretty much same with ‘ro’ inserted somewhere in the connectionstring
• Key Rotation
  • Vinaya -  It was brought up in an earlier meeting that key rotation is difficult in large implementations, is there any tooling that could help with that?
  • Education Analytics
    
    • No technical limitation on deploying ODS instructure for 1 year
    • Complexity is with roll-over process and coordination for a new school year and the change of key and secrets. As the number of applications the districts want to connect grows, coordination effort grows.
  • EdWire
    • Why do you need to create a new Admin and Security every year? These databases don’t change much between different API versions. Security database mostly contains even same data.
    • Investigate Admin & security schema for multi instance and multi tenant
  • Marcos
    • API key/secret work across years, I think that is ok but the Admin App UI gives an impression that it is meant for one year. For me it is UI change AA-1617 and not change Ed-Fi ODS platform.
  • Wisconsin
    • We built a portal for districts to self-serve credentials. We have 1400 districts that connect to it. We have about 2700 different API keys and secrets.
    • We discussed forcing yearly key rotation. However it would be a huge effort to ensure all 1400 districts have the correct key and secret for the correct year.
    • Stephen - Maybe need a self-service portal to retrieve your new key
  • Education Analytics
    
    • Consider adding a ExpirelyDate on the key/secret so that Hosts can set it according to contract end or on yearly basis ODS-5678
  • EdWise
    • Consider wrapping admin and security into one Ed-Fi database to reduce cost
  • Wisconsin -  ODS-1368
  • EdWire - make admin database single one to be more efficient
    • Combine security and admin and use single one for multiple yearly ODSs
    • We currently recreate all three databases every year to keep security data segregated. If that kind of segregation is built into the schema it would simplify management and reduce hosting cost.
  • Education Analytics
    
    • Agree with combining Admin and Security databases. Not sure if a multi-instance/multi-year solution would be helpful due to removal of upgrade support. Now we redeploy full infrastructure with new version, if Admin or Security schema changes between versions - muti-year/multi instances support wouldn't work
  • EdWise
    
    • Admin database and security database schema have minor changes as compared to the old ODS. If re-architected, it will stay for a while.
• OAuth Implementation
  • EdWire - Should we consider including claims inside the token, so that the token has information on what access it has?
  • Vinaya -
    • Including claims in the token would probably help in avoiding cache issues with security metadata.
    • Increases token size
  • Stephen
    • Meadowlark is using Json web token
      • Everything for authorization data is in the token
    • I would like to see this happen, but we need to careful about token size
  • EdWire
    
    • Don’t have to have everything in the token, we can investigate existing open source implementations.
    • https://solliance.net/products/policyserver
    • I am looking for the ability to plugin in a alternative OpenID implementation

Action Items

• Vinaya will post a report out
• SF - host future Meadowlark SIG cross-feature presentation