workflow rules
This commit is contained in:
parent
b31134c6cd
commit
faa21b5da9
@ -1,27 +1,33 @@
|
||||
# General architecture
|
||||
## General architecture
|
||||
|
||||
Each OpenCloud instance will provide an OpenId interface. This interface may be connected to an existing LDAP Server or a dedicated one.
|
||||
The main advanytage of this distributed solution is that each partner will manage it's own iusers and profiles. It simplifies access control management as each peer does not have to be aware of other peers users, but will only define access rules globally for the peers.
|
||||
The main advantage of this distributed solution is that each partner will manage it's own users and profiles. It simplifies access control management as each peer does not have to be aware of other peers users, but will only define access rules globally for the peer.
|
||||
|
||||
# Users / roles / groups
|
||||
## Users / roles / groups
|
||||
Users in opencloud belong to a peer (company), they may be part of groups within the company (organisational unit, project, ...).
|
||||
Within those groups or globally for the peer, they may have different roles (project manager, workflow designer, accountant,...).
|
||||
Roles will define the list of permissions granted to that role.
|
||||
|
||||
## User permissions definition
|
||||
|
||||
# User permissions definition
|
||||
Each OpenCloud instance will manage it's users and their permissions though the user/group/role scheme defined in the previous chapter.
|
||||
On a local instance basic permissions are :
|
||||
* a user has permission to start a distributed workflow using remote peers
|
||||
* a user has permissions to view financial information on the instance
|
||||
* a user has permissions to change the service exchange rates
|
||||
|
||||
Each OpenCloud instance will manage it's users and their permissions :
|
||||
On a local instance :
|
||||
* a user has permission to start a distributed workflow in using remote peers
|
||||
* a user has administrative rights and may change the service exchenge rates
|
||||
* a user is limited to view financial information on the instance
|
||||
* a user belongs to a group (that may represent a project, a department,...)
|
||||
On a remote instance basic permission are :
|
||||
* exceute workflow (quota + peers subset ?)
|
||||
* store data (quota + peers subset ?)
|
||||
|
||||
|
||||
# Authentication process
|
||||
## Authentication process
|
||||
|
||||
Each OpenCloud peer will accept a company as a whole.
|
||||
Upon user connection, it will receive user rights form the origninating OpenId connect server and apply them. ex: specific pricing for a group (company agreement, project agreement, ...)
|
||||
Each OpenCloud peer will accept a company/group as a whole.
|
||||
Upon user connection, it will receive user rights form the originating OpenId connect server and apply them. ex: specific pricing for a group (company agreement, project agreement, ...)
|
||||
A collaborative workspace
|
||||
|
||||
|
||||
# Resources don't have an url
|
||||
## Resources don't have a static url
|
||||
They will map to an internal url of the service
|
||||
Once a workflow is initialized and ready for launch temporary urls proxying to the real service will be provided to the wokflow at booking time
|
||||
Once a workflow is initialized and ready for launch temporary urls proxying to the real service will be provided to the wokflow at booking time/
|
70
docs/WP/workflow_design.md
Normal file
70
docs/WP/workflow_design.md
Normal file
@ -0,0 +1,70 @@
|
||||
## Workflow design rules
|
||||
|
||||
1. A data resource may be directly linked to a processing
|
||||
1. A processing resource is linked always linked to the next processing resource.
|
||||
1. If two processing resources need to exchange file data, they need to be connected to the same file storage(s)
|
||||
1. A processing shall be linked to a computing resource
|
||||
|
||||
|
||||
### Data - Resource link
|
||||
|
||||
A data resource may be linked to a processing resource.
|
||||
The processing resource shall be compatible with the data resource format and API.
|
||||
|
||||
#### Example 1 : Trivial download
|
||||
For a simple example :
|
||||
* the data resource will provide an http url to download a file.
|
||||
* the processing resource is the simple curl command that will download the file in the current computing resource
|
||||
|
||||
|
||||
#### Example 2 : Advanced download processing resource
|
||||
|
||||
For a more specific example :
|
||||
* the data resource is a complex data archive
|
||||
* the processing resource is a complex download component that can be configured to retrieve specific data or datasets from the archive
|
||||
|
||||
|
||||
### Processing - Processing link
|
||||
|
||||
Dependant processings must be graphically linked, those links allow build the workflow's acyclic diagram.
|
||||
|
||||
|
||||
### Processing - Storage link
|
||||
|
||||
A processing may be linked to one or several storage resources.
|
||||
|
||||
#### Basic storage resource types
|
||||
|
||||
Storage resource types generally require a list source - destination information tha describe reaw/write operations.
|
||||
This information is associated to the link between the processing and the storage resources.
|
||||
|
||||
*In the case of a write to storage operation :*
|
||||
* the source information specifies the local path/filename in the container where the file is created by the processing.
|
||||
* the destination information contains the url/path/filename where the file shall be stored
|
||||
|
||||
*In the case of a read from storage operation :*
|
||||
* the source information specifies the url/path/filename where the file is stored
|
||||
* the destination information contains local path/filename in the container where the file shall be created for the processing to use it.
|
||||
|
||||
##### Local cluster storage
|
||||
|
||||
The generated Argo workflow defines a local storage available to all containers in the current cluster
|
||||
This storage is available from every container under the path defined in the $LOCALSTORAGE environment varlable.
|
||||
On this special storage, as it is mounted in all container, the source - destination information is implicit.
|
||||
Any data can be read or written directly.
|
||||
|
||||
##### S3 type storages
|
||||
|
||||
Several S3 compatible storage may be used in a workflow
|
||||
* OCS3 : The global MinIO deployed in the local OpenCloud instance
|
||||
* Generic S3 : Any external accessible S3 compatible service
|
||||
* WFS3 : An internal MinIO instance deployed for the workflow duration, that instance might be exposed outside the current cluster
|
||||
|
||||
##### Custom storage types
|
||||
|
||||
|
||||
|
||||
### Processing - Computing link
|
||||
|
||||
A processing shall be connected to a computing link.
|
||||
|
@ -32,4 +32,6 @@ A collaborative area is an environment for shariung wokspaces / workflows / serv
|
||||
|
||||
## Rule book
|
||||
|
||||
List of rules that a shareds workspace shall conform to
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user