Multi-tenancy - master requirements

[sanand0]

• Objective: Create a framework and provide support for building multi-tenancy apps
  • Users can create accounts for themselves.
  • Users can create organizations (namespaces) themselves. Call them namespace admins
  • Namespace admins can add people to these namespaces themselves (and manage them)
  • Users can create projects / datasets (call them project owners) that they can share with access control, within and across organizations
  • None of the above requires intervention by the app developer (self-service)
  • App developers can build such apps on Gramex with a consistent framework
• Terminology
  • Gramex: Base platform for all apps
  • App: E.g. Insight Tree, Cluster, SlideSense, ...
  • Namespace: E.g. Accenture, Dell, Sales, Anand, Sandeep, ...
  • Project: E.g. Sales data, Customer data, ...
• Roles:
  • App developer: E.g. Annamalai who builds SlideSense
  • Namespace admin: E.g. Dell IT Admin
  • Project owner: E.g. Dell Sales Manager for Sales data
• Base URL structure: APP.gramener.com/NAMESPACE/PROJECT/
  • The URL can have any structure that uses /NAMESPACE/PROJECT/ in the middle. The structure below is recommended
  • APP.gramener.com/ is the app landing page
  • APP.gramener.com/NAMESPACE/ is the namespace landing page
  • APP.gramener.com/NAMESPACE/PROJECT/ is the project landing page
  • APP.gramener.com/settings is for the app developer to specify app settings (e.g. default clustering algorithm)
  • APP.gramener.com/NAMESPACE/settings is for namespace admin to edit namespace-level config
  • APP.gramener.com/NAMESPACE/PROJECT/settings is for project owner to edit project config
• NAMESPACE/settings are stored in a common storelocation.settings in gramex.yaml with the schema:
  • app -- app for which we're defining settings
  • namespace -- namespace for which we're defining settings
  • project -- project for which we're defining settings
  • path -- the location where the org's data is stored
  • license -- license type (e.g. enterprise / free) or license settings (JSON)
  • settings -- the settings (JSON)
• Role definitions stored in a common storelocation.roles in gramex.yaml with the schema:
  • app -- need a sensible default (where 1 Gramex instance, like UAT, serves multiple multi-tenancy apps)
  • namespace -- the namespace for which the role is defined (e.g. a namespace)
  • project -- the project for which the role is defined (e.g. a project)
  • user -- the user ID for whom we're looking up the role
  • role -- each person may have 1 or more roles in a fnmatch-like hierarchy "dataset/excel", "dataset/csv", "doc/pdf", "dataset/*" that we can SQL query by, and the most recent permission overriding the previous ones
• Permissions are stored in a common storelocation.permissions in gramex.yaml with the schema:
  • role: the role for which we're defining permissions. 1 role per row
  • permission: the permissions allowed for this role. 1 permission per row
    • App level permissions for namespaces
    • Namespace level permissions:
      • read-all-projects
      • update-all-projects
      • create-project
      • list-namespace
      • update-namespace (edit) all project settings, roles, permissions
      • delete-namespace
    • Project level permissions:
      • read-project
      • update-project (edit) the project settings, roles, permissions
      • delete-project
  • Will be available in handler.current_user.roles (roles can be changed to something else via a config)
    • Structure: { roles: [role, role, ...], permissions: [permission, ...]}
  • Editing
    • Revised version of FormHandler table
    • How to allow users to create standard values (e.g. standard permissions / settings)?
• Org setup flow
  • App developer can import the Org setup app at an endpoint, etc /setup
  • The app, org, path, license fields are pre-filled
  • The app accepts a set of configurations (flat key-value pairs) as YAML settings, with defaults
  • This has a single page that displays the configurations and allows the owner to edit them
  • On submit, it created the entry in the org definitions AND role definitions (creating the owner for the app)

@jaidevd @shraddheya -- do take a look. Thanks!

[jaidevd]

Usecases:

• File viewer
• JSON / XML API
• Python functions aaS

Ensure that the spec above is obeyed for:

• settings
• role definitions
• permissions