Open brent-hartwig opened 1 month ago
@clarkepeterf, I submitted PR https://github.com/project-lux/lux-marklogic/pull/153 for your review. It's description summarizes the changes. I'd also like to address a topic we discussed but I did not end up implementing: base roles. Unless we want all tenants to have base roles, I do not see the need for them until we need to vary permissions within a tenant, as will be the need for data slices (#73). In that case, there are multiple service accounts where document permissions vary by service account. That said, we can introduce base roles now or later.
New PR is https://github.com/project-lux/lux-marklogic/pull/199, which is based off of the release1.20 branch. ~I also need to create a cloud-formation PR for the property changes.~ The associated cloud-formation PR is https://git.yale.edu/lux-its/ml-cluster-formation/pull/29.
cc: @clarkepeterf
Update: the following was addressed in PR https://github.com/project-lux/lux-marklogic/pull/209, which made it into release1.20. release1.20 deployments should no longer experience a timeout.
@clarkepeterf, @kamerynB, and @xinjianguo, part of this ticket's implementation may result in the generateDataConstants
task timing out. This ticket forces the task to execute through the [tenant]-request-group-1
app server and does not attempt to override the 20 second default timeout. First identified workaround:
generateRemainingSearchTerms
task.I'll look into a resolution --RESOLVED!
How can this be tested?
While one could test frontends configured to different DEV tenants, we could also consider this tested enough by developers. We have it at the point that deployers are to update their copy of a tenant-specific properties file, add their username, set the password, and run Gradle tasks.
Description
We're looking for a consistent and relatively straight-forward means to deploy multiple instances of LUX within the DEV environment. Each tenant is to have its own set of MarkLogic resources, specifically: content database, modules database, application servers, and roles. The implementation should be compatible with single- and multi-tenant environments.
This ticket's scope is to facilitate (and document) multiple tenants. The scope excludes preventing one tenant from modifying another tenant's resources. Initially, a single team will manage all tenants and will need to coordinate / take care.