As a service provider, I need to configure workflows differently for different tenants

Description

Opencast currently does not support multi-tenancy when it comes to workflow definitions: All workflow definitions are available for all tenants.

We would like to change this with the following approach:

  • A workflow definition might specify an organization

  • If a workflow definition does not specify an organization, it is available to all tenants

  • If a workflow definition does specify an organization, it is available to that organization (tenant) only

  • A workflow definition can only be instantiated on a tenant when it is available to that tenant

  • APIs (External API, Admin UI Facade, REST APIs) will only list workflow definitions available to the tenant that is being requested

  • If is possible to have multiple workflow definitions with the same workflow definition ID but available to different tenants. One of that workflow definition might be the one available to all tenants

  • Tenant-specific workflow definitions take precedence over non-tenant-specific workflow definitions, i.e. if both a tenant-specific workflow definition and a non-tenant-specific workflow definition is available, only the tenant-specific workflow definition counts on the respective tenant (it overrides the more generic workflow definition).

Note: The motivation to allow multiple workflow definitions with the same workflow definition ID is to allow Adopters to use tenant-specific partial workflow definitions (partial = included in another workflow definition). The invariant to only have one workflow definition per workflow definition ID still holds as the tenant-specific WD overrides the generic WD.

Activity

Show:
Greg Logan
May 21, 2019, 4:31 PM

+1 for removing them. Developers/testers should know how to change the
underlying files when they need to, and the endpoints are suboptimal in the
best (single tenant) case.

If someone really needs these they should reimplement them with
multitenancy features, which solves the whole issue

G

–
You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Lars Kiesow
May 20, 2019, 4:04 PM

I'm strongly in favor of removing the endpoints.
–Lars

On Mon, 20 May 2019 07:46:53 -0700 (PDT)

–
You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Sven Stauber
May 20, 2019, 2:46 PM

Dear Opencast Developers

To continue the review of Multitenancy support for workflows [1], we need a decision on how to proceed.
As preparation, I would like to ask you about your opinions.

Background:
adds the ability to have workflow definitions that can be available to all tenants or just a single tenant whereas the more specific workflow definition overrides the other in case both are available. This avoids having literally thousands of workflow definition XML files for larger multi-tenant systems where most tenants share the same workflow definitions.

The Challenge:
While the solution proposed by works perfectly fine considering the workflow configuration using XML files in etc/workflows, it gets a bit smelly in combination with the existing REST queries:

  • DELETE /workflow/definition/{id} to unregister a workflow definition

  • PUT /workflow/definition to add a workflow definition

The smell is that in a multi-tenant setup, HTTP requests always belongs to exactly one tenant and allowing such requests to delete or add workflow definitions that are available to all tenants is undesirable as this would break the idea of multi-tenancy (separation of tenants). Not allowing the requests to do so works but results in unexpected behaviour.

A First Analysis:
Those REST queries are actually quite useless for a production system as the changes to the workflow definitions won't be made persistent, i.e. to configure your system you will end up doing this in etc/workflow anyway. From that point of view, the REST queries could simply just be removed.
On the other hand, the queries might be handy for development/testing purposes if access to the folder etc/workflows is not available or not desired.

Possible Solutions:

1. Remove DELETE /workflow/definition/{id} and PUT /workflow/definition

+ Clean design
+ Less code to maintain / avoid feature creep

  • Changing workflow definitions needs to be done in etc/workflows

2. DELETE /workflow/definition/{id} and PUT /workflow/definition just apply to the current organisation

+ The testing use case still works

  • Smelly design: Deleting the tenant specific workflow definition will cause a fallback to the global workflow definition which is an unexpected behaviour

3. [Your proposed solution that is not 1 or 2]

Personally, I would go for Solution 1 as it results in a clean design and even removes some code/functionality we don't really need.

Admittedly, I've never used those endpoints which makes that easy to say

What would you do here?

Best
Sven

[1] Multitenancy support for workflows, https://github.com/opencast/opencast/pull/864
[2] Remove pseudo-mechanism for workflow definition registration, https://github.com/opencast/opencast/pull/872/files

–
You received this message because you are subscribed to the Google Groups "Opencast Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+unsubscribe@opencast.org.

Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Unassigned

Reporter

Sven Stauber