Goal
Admin App currently supports a single target ODS instance. The goal is to support management of multiple ODS instances in a collaborative scenario, to minimize the need for "home grown" management workarounds in the field, and to exhibit & promote Ed-Fi's recommended approach. Once Admin App has the ability to manage multiple ODS instances, per-user roles and permissions become a vital new concern: users should only be able to access the particular ODS instances they have been assigned to manage.
The reference architecture is Indiana/INSITE as seen in Multi-Instance Reference Architectures:
- One EdFi_Admin
- One EdFi_Security
- One API
- Mulitple ODS databases (ie one per district). "Multiple Instance" refers to these multiple ODS databases behind the single API.
- One Admin App installation, capable of managing all the defined ODS instances.
- A given Admin App user is limited to which ODS instance databases they access.
Solution Considerations
Given that users in the field have a number of deployment scenarios and workarounds already, it's important that this design respect and leverage existing ODS Platform concepts where applicable, rather than mistakenly "reinvent the wheel". The desire for "One API" for instance, strongly suggests that part of the user-to-instance routing and security would naturally be performed by the ODS itself.
This design should allow for a reasonable degree of developer parallelism, and should allow each planned piece to be developed and merged in a state that could be released at any moment without harm. Implemented as one large Pull Request, for instance, would be a high-risk mistake.
Although this work is to support multi-instance, not all end users find themselves in a multi-instance scenario. The experience for simpler deployment scenarios should not be harmed, but we also need to strive for a singular implementation rather than a sort of "internal fork" of the project. Therefore, this work may change the experience for simple deployment scenarios, such as the precise steps taken from installation to first time setup of a singular ODS instance, so long as that experience is still sound.
Assumptions
This design is about enabling users to administer the multi-instance scenario depicted above under "Goal". Just as Admin App today does not deploy its singular ODS instance, a Multi-Instance enabled Admin App would not deploy ODS instances. Rather, it would gain support for administering the deployed ODS instances just as it does today for its singular ODS instance. That new multi-instance support therefore largely focus on configuring the connections to each ODS instance, performing the "first time setup" work for each, and configuring/controlling which users are allowed access to the instances.
Recommendation
"Settings" & "Global" Sections
Top Level Navigation: Admin App users in prior releases first select "Settings" (features against their single ODS instance such as Applications, Descriptors, Reports) or "Global" (Vendors and Claim Sets). The Vendors page already suggests, even, the natural workflow: define Vendors, define Applications within those Vendoers, obtains Keys. Given the natural order of that workflow, we recommend swapping the order of the "Settings" and "Global" navigation items, and then renaming "Settings" to "ODS Instances":
