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

« Previous Version 9 Next »

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 Vendors, 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":

Consider the current tabs within the present-day Settings screen:

  • Applications - Because Applications are instance specific, this page's contents would be limited to show only those Applications for my user's assigned ODS instances. When defining a new Application, the specific instance to add it to would need to be known, either as a new field in the Add Application overlay or as a tab-wide Instance selection/filter showing only those instances associated with the user.
  • Descriptors - We suspect we need an ODS instance selection here, and then show descriptors for that instance. But, if there is a single API, what distinguishes one instance's descriptors from the next? Does the single API combine results from each instance?
  • Education Organizations - Similar concerns as with Applications. The user should only see Education Organizations from their assigned ODS instance, and when they hit Add Local Education Agency, they'll need to have an ODS instance selected. 
    • Risk: This screen raises further questions about terminology. Early discussion of the deployment model displayed in the "Goals" section above tended to equate "District" with each ODS instance database. The sample Education Organization of Grand Bend ISD suggests that Education Organizations may be districts. It's unclear, then, whether there is a strict association between Education Organizations and ODS instances in all cases, or whether there are, say, non-district Education Organizations which might in fact span ODS instances.
  • Bulk Load - Because bulk load hits the API with a specific Key and Secret entered in this screen, we expect no further need for Multi-Instance concerns here. Is this in fact a "global" API-level concern, belonging under Global, or is it somehow in fact ODS instance specific?
  • Learning Standards - Same questions as for Bulk Load.
  • Reports - AA currently adds reporting views to the target ODS database to enable reports. We expect this page to need an ODS Instance selection similar to Applications and Education Organizations.
    • Risk: There's a similar conceptual/vocabulary risk here as with Education Organizations above. This screen has a District drop down list. Given that specific ODS instances have been described in terms of districts so far, it raises the question about how strictly true those examples are, or whether we need to be extra precise in our language: on the reports tab, for instance, would the user select both an ODS Instance and a District, and when would those not be the same apparently selection to the user.
    • Recommendation: When the existing "Select District" dropdown has only one option, autoselect it. The underlying data for this is Local Education Agenecies, so should "Select District" be rephrased to match?
  • Recommendation for any ODS instance selector: when the current user has exactly one instance available to them, autoselect it.


Work in Progress: Early designs for Multi-Instance predated the above deployment recommendation. They involved defining instances in Admin App using a URL / Key / Secret, and then adding an instance selection drop down within the ODS Instances screen. We're beginning to think that design is mistaken, especially in light of the desire for a single API. Therefore, the pivotal design questions come down to the capabilities of the ODS both present day and in the future for this recommended deployment diagram, and whether key/secret therefore need to be per User, or per User+Instance, etc.

User Management: Roles, Permissions, Registration & Login

Because the set of Admin App users are managed by Admin App for use against all the ODS Instances, new user administration features will appear under the "Global" top level navigation.


See User Management for Admin App (Multi-Instance Mode) for technical design of the users/roles/permissions aspects of Multi-Instance.

First-Time Setup

See Multi-Instance First Time Setup for the design of the First-Time Setup aspects of Multi-Instance.


  • No labels