search

project-lux / lux-marklogic

Code, issues, and resources related to LUX MarkLogic
Other
3 stars 2 forks source link

#149: facilitate multiple LUX instances in the same cluster (a.k.a., "tenants") #199

Closed brent-hartwig closed 23 hours ago

brent-hartwig commented 2 days ago

Role changes:

  1. Deleted the lux-nobody role.
  2. Deleted the lux-admin role.
  3. Deleted the lux-ml-admin role.
  4. Remaining roles now incorporate the value of the mlAppName property in their names.

Deleted roles may be manually deleted after deployment.

Recommend not deleting other roles, specifically ones that documents grant permissions to; else a reload will be necessary.

User accounts for unsecure deployments align with the role changes.

Lots of documentation changes throughout but to test, start with the "Tenant Configuration" section in lux-backend-deployment.md. Documentation distinguishes between shared configuration and tenant-specific configuration. There are more manual steps than I would like for secondary tenants; but, as discussed before, we can wait until circumstances compel better.

Replaced most hard-coded instances of database names. Added a database name variable in some scripts, defaulting to lux-content.

Property changes which will need to propagate to the environment- and tenant-specific properties files:

  1. Explicitly setting mlAppServicesPort, which build.gradle now references.
  2. Renamed luxContentDatabase to tenantContentDatabase
  3. Renamed luxModulesDatabase to tenantModulesDatabase
  4. Changed the value of mlDataPermissions from "lux-endpoint-consumer,read,lux-writer,update" to "YOUR_TENANT_NAME-reader,read,YOUR_TENANT_NAME-writer,update"
  5. No longer setting mlDatabaseNamesAndReplicaCounts; see inline documentation within gradle.properties for guidance,
  6. Introduced backupEnabled

cloud-formation PR for property changes: https://git.yale.edu/lux-its/ml-cluster-formation/pull/29

Removed the (unused) JavaScript Template deployment capability.