Attendees

Materials

Open

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