diff --git a/lib/.github/workflows/ci.yml b/.github/workflows/ci.yml similarity index 100% rename from lib/.github/workflows/ci.yml rename to .github/workflows/ci.yml diff --git a/lib/src/TES/models/mod.rs b/lib/src/TES/models/mod.rs new file mode 100644 index 0000000..232b43a --- /dev/null +++ b/lib/src/TES/models/mod.rs @@ -0,0 +1,34 @@ +pub mod service; +pub use self::service::Service; +pub mod service_organization; +pub use self::service_organization::ServiceOrganization; +pub mod service_type; +pub use self::service_type::ServiceType; +pub mod tes_create_task_response; +pub use self::tes_create_task_response::TesCreateTaskResponse; +pub mod tes_executor; +pub use self::tes_executor::TesExecutor; +pub mod tes_executor_log; +pub use self::tes_executor_log::TesExecutorLog; +pub mod tes_file_type; +pub use self::tes_file_type::TesFileType; +pub mod tes_input; +pub use self::tes_input::TesInput; +pub mod tes_list_tasks_response; +pub use self::tes_list_tasks_response::TesListTasksResponse; +pub mod tes_output; +pub use self::tes_output::TesOutput; +pub mod tes_output_file_log; +pub use self::tes_output_file_log::TesOutputFileLog; +pub mod tes_resources; +pub use self::tes_resources::TesResources; +pub mod tes_service_info; +pub use self::tes_service_info::TesServiceInfo; +pub mod tes_service_type; +pub use self::tes_service_type::TesServiceType; +pub mod tes_state; +pub use self::tes_state::TesState; +pub mod tes_task; +pub use self::tes_task::TesTask; +pub mod tes_task_log; +pub use self::tes_task_log::TesTaskLog; diff --git a/lib/src/TES/models/service.rs b/lib/src/TES/models/service.rs new file mode 100644 index 0000000..1943618 --- /dev/null +++ b/lib/src/TES/models/service.rs @@ -0,0 +1,67 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// Service : GA4GH service +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct Service { + /// Unique ID of this service. Reverse domain name notation is recommended, though not required. The identifier should attempt to be globally unique so it can be used in downstream aggregator services e.g. Service Registry. + #[serde(rename = "id")] + pub id: String, + /// Name of this service. Should be human readable. + #[serde(rename = "name")] + pub name: String, + #[serde(rename = "type")] + pub r#type: Box, + /// Description of the service. Should be human readable and provide information about the service. + #[serde(rename = "description", skip_serializing_if = "Option::is_none")] + pub description: Option, + #[serde(rename = "organization")] + pub organization: Box, + /// URL of the contact for the provider of this service, e.g. a link to a contact form (RFC 3986 format), or an email (RFC 2368 format). + #[serde(rename = "contactUrl", skip_serializing_if = "Option::is_none")] + pub contact_url: Option, + /// URL of the documentation of this service (RFC 3986 format). This should help someone learn how to use your service, including any specifics required to access data, e.g. authentication. + #[serde(rename = "documentationUrl", skip_serializing_if = "Option::is_none")] + pub documentation_url: Option, + /// Timestamp describing when the service was first deployed and available (RFC 3339 format) + #[serde(rename = "createdAt", skip_serializing_if = "Option::is_none")] + pub created_at: Option, + /// Timestamp describing when the service was last updated (RFC 3339 format) + #[serde(rename = "updatedAt", skip_serializing_if = "Option::is_none")] + pub updated_at: Option, + /// Environment the service is running in. Use this to distinguish between production, development and testing/staging deployments. Suggested values are prod, test, dev, staging. However this is advised and not enforced. + #[serde(rename = "environment", skip_serializing_if = "Option::is_none")] + pub environment: Option, + /// Version of the service being described. Semantic versioning is recommended, but other identifiers, such as dates or commit hashes, are also allowed. The version should be changed whenever the service is updated. + #[serde(rename = "version")] + pub version: String, +} + +impl Service { + /// GA4GH service + pub fn new(id: String, name: String, r#type: models::ServiceType, organization: models::ServiceOrganization, version: String) -> Service { + Service { + id, + name, + r#type: Box::new(r#type), + description: None, + organization: Box::new(organization), + contact_url: None, + documentation_url: None, + created_at: None, + updated_at: None, + environment: None, + version, + } + } +} + diff --git a/lib/src/TES/models/service_organization.rs b/lib/src/TES/models/service_organization.rs new file mode 100644 index 0000000..ea658ca --- /dev/null +++ b/lib/src/TES/models/service_organization.rs @@ -0,0 +1,33 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// ServiceOrganization : Organization providing the service +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct ServiceOrganization { + /// Name of the organization responsible for the service + #[serde(rename = "name")] + pub name: String, + /// URL of the website of the organization (RFC 3986 format) + #[serde(rename = "url")] + pub url: String, +} + +impl ServiceOrganization { + /// Organization providing the service + pub fn new(name: String, url: String) -> ServiceOrganization { + ServiceOrganization { + name, + url, + } + } +} + diff --git a/lib/src/TES/models/service_type.rs b/lib/src/TES/models/service_type.rs new file mode 100644 index 0000000..c325103 --- /dev/null +++ b/lib/src/TES/models/service_type.rs @@ -0,0 +1,37 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// ServiceType : Type of a GA4GH service +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct ServiceType { + /// Namespace in reverse domain name format. Use `org.ga4gh` for implementations compliant with official GA4GH specifications. For services with custom APIs not standardized by GA4GH, or implementations diverging from official GA4GH specifications, use a different namespace (e.g. your organization's reverse domain name). + #[serde(rename = "group")] + pub group: String, + /// Name of the API or GA4GH specification implemented. Official GA4GH types should be assigned as part of standards approval process. Custom artifacts are supported. + #[serde(rename = "artifact")] + pub artifact: String, + /// Version of the API or specification. GA4GH specifications use semantic versioning. + #[serde(rename = "version")] + pub version: String, +} + +impl ServiceType { + /// Type of a GA4GH service + pub fn new(group: String, artifact: String, version: String) -> ServiceType { + ServiceType { + group, + artifact, + version, + } + } +} + diff --git a/lib/src/TES/models/tes_create_task_response.rs b/lib/src/TES/models/tes_create_task_response.rs new file mode 100644 index 0000000..618d8ef --- /dev/null +++ b/lib/src/TES/models/tes_create_task_response.rs @@ -0,0 +1,29 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesCreateTaskResponse : CreateTaskResponse describes a response from the CreateTask endpoint. It will include the task ID that can be used to look up the status of the job. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesCreateTaskResponse { + /// Task identifier assigned by the server. + #[serde(rename = "id")] + pub id: String, +} + +impl TesCreateTaskResponse { + /// CreateTaskResponse describes a response from the CreateTask endpoint. It will include the task ID that can be used to look up the status of the job. + pub fn new(id: String) -> TesCreateTaskResponse { + TesCreateTaskResponse { + id, + } + } +} + diff --git a/lib/src/TES/models/tes_executor.rs b/lib/src/TES/models/tes_executor.rs new file mode 100644 index 0000000..f440d88 --- /dev/null +++ b/lib/src/TES/models/tes_executor.rs @@ -0,0 +1,57 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesExecutor : Executor describes a command to be executed, and its environment. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesExecutor { + /// Name of the container image. The string will be passed as the image argument to the containerization run command. Examples: - `ubuntu` - `quay.io/aptible/ubuntu` - `gcr.io/my-org/my-image` - `myregistryhost:5000/fedora/httpd:version1.0` + #[serde(rename = "image")] + pub image: String, + /// A sequence of program arguments to execute, where the first argument is the program to execute (i.e. argv). Example: ``` { \"command\" : [\"/bin/md5\", \"/data/file1\"] } ``` + #[serde(rename = "command")] + pub command: Vec, + /// The working directory that the command will be executed in. If not defined, the system will default to the directory set by the container image. + #[serde(rename = "workdir", skip_serializing_if = "Option::is_none")] + pub workdir: Option, + /// Path inside the container to a file which will be piped to the executor's stdin. This must be an absolute path. This mechanism could be used in conjunction with the input declaration to process a data file using a tool that expects STDIN. For example, to get the MD5 sum of a file by reading it into the STDIN ``` { \"command\" : [\"/bin/md5\"], \"stdin\" : \"/data/file1\" } ``` + #[serde(rename = "stdin", skip_serializing_if = "Option::is_none")] + pub stdin: Option, + /// Path inside the container to a file where the executor's stdout will be written to. Must be an absolute path. Example: ``` { \"stdout\" : \"/tmp/stdout.log\" } ``` + #[serde(rename = "stdout", skip_serializing_if = "Option::is_none")] + pub stdout: Option, + /// Path inside the container to a file where the executor's stderr will be written to. Must be an absolute path. Example: ``` { \"stderr\" : \"/tmp/stderr.log\" } ``` + #[serde(rename = "stderr", skip_serializing_if = "Option::is_none")] + pub stderr: Option, + /// Enviromental variables to set within the container. Example: ``` { \"env\" : { \"ENV_CONFIG_PATH\" : \"/data/config.file\", \"BLASTDB\" : \"/data/GRC38\", \"HMMERDB\" : \"/data/hmmer\" } } ``` + #[serde(rename = "env", skip_serializing_if = "Option::is_none")] + pub env: Option>, + /// Default behavior of running an array of executors is that execution stops on the first error. If `ignore_error` is `True`, then the runner will record error exit codes, but will continue on to the next tesExecutor. + #[serde(rename = "ignore_error", skip_serializing_if = "Option::is_none")] + pub ignore_error: Option, +} + +impl TesExecutor { + /// Executor describes a command to be executed, and its environment. + pub fn new(image: String, command: Vec) -> TesExecutor { + TesExecutor { + image, + command, + workdir: None, + stdin: None, + stdout: None, + stderr: None, + env: None, + ignore_error: None, + } + } +} + diff --git a/lib/src/TES/models/tes_executor_log.rs b/lib/src/TES/models/tes_executor_log.rs new file mode 100644 index 0000000..7af295b --- /dev/null +++ b/lib/src/TES/models/tes_executor_log.rs @@ -0,0 +1,45 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesExecutorLog : ExecutorLog describes logging information related to an Executor. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesExecutorLog { + /// Time the executor started, in RFC 3339 format. + #[serde(rename = "start_time", skip_serializing_if = "Option::is_none")] + pub start_time: Option, + /// Time the executor ended, in RFC 3339 format. + #[serde(rename = "end_time", skip_serializing_if = "Option::is_none")] + pub end_time: Option, + /// Stdout content. This is meant for convenience. No guarantees are made about the content. Implementations may chose different approaches: only the head, only the tail, a URL reference only, etc. In order to capture the full stdout client should set Executor.stdout to a container file path, and use Task.outputs to upload that file to permanent storage. + #[serde(rename = "stdout", skip_serializing_if = "Option::is_none")] + pub stdout: Option, + /// Stderr content. This is meant for convenience. No guarantees are made about the content. Implementations may chose different approaches: only the head, only the tail, a URL reference only, etc. In order to capture the full stderr client should set Executor.stderr to a container file path, and use Task.outputs to upload that file to permanent storage. + #[serde(rename = "stderr", skip_serializing_if = "Option::is_none")] + pub stderr: Option, + /// Exit code. + #[serde(rename = "exit_code")] + pub exit_code: i32, +} + +impl TesExecutorLog { + /// ExecutorLog describes logging information related to an Executor. + pub fn new(exit_code: i32) -> TesExecutorLog { + TesExecutorLog { + start_time: None, + end_time: None, + stdout: None, + stderr: None, + exit_code, + } + } +} + diff --git a/lib/src/TES/models/tes_file_type.rs b/lib/src/TES/models/tes_file_type.rs new file mode 100644 index 0000000..c517a37 --- /dev/null +++ b/lib/src/TES/models/tes_file_type.rs @@ -0,0 +1,38 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesFileType : Define if input/output element is a file or a directory. It is not required that the user provide this value, but it is required that the server fill in the value once the information is avalible at run time. +/// Define if input/output element is a file or a directory. It is not required that the user provide this value, but it is required that the server fill in the value once the information is avalible at run time. +#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)] +pub enum TesFileType { + #[serde(rename = "FILE")] + File, + #[serde(rename = "DIRECTORY")] + Directory, + +} + +impl ToString for TesFileType { + fn to_string(&self) -> String { + match self { + Self::File => String::from("FILE"), + Self::Directory => String::from("DIRECTORY"), + } + } +} + +impl Default for TesFileType { + fn default() -> TesFileType { + Self::File + } +} + diff --git a/lib/src/TES/models/tes_input.rs b/lib/src/TES/models/tes_input.rs new file mode 100644 index 0000000..1a86574 --- /dev/null +++ b/lib/src/TES/models/tes_input.rs @@ -0,0 +1,50 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesInput : Input describes Task input files. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesInput { + #[serde(rename = "name", skip_serializing_if = "Option::is_none")] + pub name: Option, + #[serde(rename = "description", skip_serializing_if = "Option::is_none")] + pub description: Option, + /// REQUIRED, unless \"content\" is set. URL in long term storage, for example: - s3://my-object-store/file1 - gs://my-bucket/file2 - file:///path/to/my/file - /path/to/my/file + #[serde(rename = "url", skip_serializing_if = "Option::is_none")] + pub url: Option, + /// Path of the file inside the container. Must be an absolute path. + #[serde(rename = "path")] + pub path: String, + #[serde(rename = "type", skip_serializing_if = "Option::is_none")] + pub r#type: Option, + /// File content literal. Implementations should support a minimum of 128 KiB in this field and may define their own maximum. UTF-8 encoded If content is not empty, \"url\" must be ignored. + #[serde(rename = "content", skip_serializing_if = "Option::is_none")] + pub content: Option, + /// Indicate that a file resource could be accessed using a streaming interface, ie a FUSE mounted s3 object. This flag indicates that using a streaming mount, as opposed to downloading the whole file to the local scratch space, may be faster despite the latency and overhead. This does not mean that the backend will use a streaming interface, as it may not be provided by the vendor, but if the capacity is avalible it can be used without degrading the performance of the underlying program. + #[serde(rename = "streamable", skip_serializing_if = "Option::is_none")] + pub streamable: Option, +} + +impl TesInput { + /// Input describes Task input files. + pub fn new(path: String) -> TesInput { + TesInput { + name: None, + description: None, + url: None, + path, + r#type: None, + content: None, + streamable: None, + } + } +} + diff --git a/lib/src/TES/models/tes_list_tasks_response.rs b/lib/src/TES/models/tes_list_tasks_response.rs new file mode 100644 index 0000000..545457f --- /dev/null +++ b/lib/src/TES/models/tes_list_tasks_response.rs @@ -0,0 +1,33 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesListTasksResponse : ListTasksResponse describes a response from the ListTasks endpoint. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesListTasksResponse { + /// List of tasks. These tasks will be based on the original submitted task document, but with other fields, such as the job state and logging info, added/changed as the job progresses. + #[serde(rename = "tasks")] + pub tasks: Vec, + /// Token used to return the next page of results. This value can be used in the `page_token` field of the next ListTasks request. + #[serde(rename = "next_page_token", skip_serializing_if = "Option::is_none")] + pub next_page_token: Option, +} + +impl TesListTasksResponse { + /// ListTasksResponse describes a response from the ListTasks endpoint. + pub fn new(tasks: Vec) -> TesListTasksResponse { + TesListTasksResponse { + tasks, + next_page_token: None, + } + } +} + diff --git a/lib/src/TES/models/tes_output.rs b/lib/src/TES/models/tes_output.rs new file mode 100644 index 0000000..f627425 --- /dev/null +++ b/lib/src/TES/models/tes_output.rs @@ -0,0 +1,48 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesOutput : Output describes Task output files. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesOutput { + /// User-provided name of output file + #[serde(rename = "name", skip_serializing_if = "Option::is_none")] + pub name: Option, + /// Optional users provided description field, can be used for documentation. + #[serde(rename = "description", skip_serializing_if = "Option::is_none")] + pub description: Option, + /// URL at which the TES server makes the output accessible after the task is complete. When tesOutput.path contains wildcards, it must be a directory; see `tesOutput.path_prefix` for details on how output URLs are constructed in this case. For Example: - `s3://my-object-store/file1` - `gs://my-bucket/file2` - `file:///path/to/my/file` + #[serde(rename = "url")] + pub url: String, + /// Absolute path of the file inside the container. May contain pattern matching wildcards to select multiple outputs at once, but mind implications for `tesOutput.url` and `tesOutput.path_prefix`. Only wildcards defined in IEEE Std 1003.1-2017 (POSIX), 12.3 are supported; see https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13 + #[serde(rename = "path")] + pub path: String, + /// Prefix to be removed from matching outputs if `tesOutput.path` contains wildcards; output URLs are constructed by appending pruned paths to the directory specfied in `tesOutput.url`. Required if `tesOutput.path` contains wildcards, ignored otherwise. + #[serde(rename = "path_prefix", skip_serializing_if = "Option::is_none")] + pub path_prefix: Option, + #[serde(rename = "type", skip_serializing_if = "Option::is_none")] + pub r#type: Option, +} + +impl TesOutput { + /// Output describes Task output files. + pub fn new(url: String, path: String) -> TesOutput { + TesOutput { + name: None, + description: None, + url, + path, + path_prefix: None, + r#type: None, + } + } +} + diff --git a/lib/src/TES/models/tes_output_file_log.rs b/lib/src/TES/models/tes_output_file_log.rs new file mode 100644 index 0000000..282dd7c --- /dev/null +++ b/lib/src/TES/models/tes_output_file_log.rs @@ -0,0 +1,37 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesOutputFileLog : OutputFileLog describes a single output file. This describes file details after the task has completed successfully, for logging purposes. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesOutputFileLog { + /// URL of the file in storage, e.g. s3://bucket/file.txt + #[serde(rename = "url")] + pub url: String, + /// Path of the file inside the container. Must be an absolute path. + #[serde(rename = "path")] + pub path: String, + /// Size of the file in bytes. Note, this is currently coded as a string because official JSON doesn't support int64 numbers. + #[serde(rename = "size_bytes")] + pub size_bytes: String, +} + +impl TesOutputFileLog { + /// OutputFileLog describes a single output file. This describes file details after the task has completed successfully, for logging purposes. + pub fn new(url: String, path: String, size_bytes: String) -> TesOutputFileLog { + TesOutputFileLog { + url, + path, + size_bytes, + } + } +} + diff --git a/lib/src/TES/models/tes_resources.rs b/lib/src/TES/models/tes_resources.rs new file mode 100644 index 0000000..8c6286d --- /dev/null +++ b/lib/src/TES/models/tes_resources.rs @@ -0,0 +1,53 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesResources : Resources describes the resources requested by a task. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesResources { + /// Requested number of CPUs + #[serde(rename = "cpu_cores", skip_serializing_if = "Option::is_none")] + pub cpu_cores: Option, + /// Define if the task is allowed to run on preemptible compute instances, for example, AWS Spot. This option may have no effect when utilized on some backends that don't have the concept of preemptible jobs. + #[serde(rename = "preemptible", skip_serializing_if = "Option::is_none")] + pub preemptible: Option, + /// Requested RAM required in gigabytes (GB) + #[serde(rename = "ram_gb", skip_serializing_if = "Option::is_none")] + pub ram_gb: Option, + /// Requested disk size in gigabytes (GB) + #[serde(rename = "disk_gb", skip_serializing_if = "Option::is_none")] + pub disk_gb: Option, + /// Request that the task be run in these compute zones. How this string is utilized will be dependent on the backend system. For example, a system based on a cluster queueing system may use this string to define priorty queue to which the job is assigned. + #[serde(rename = "zones", skip_serializing_if = "Option::is_none")] + pub zones: Option>, + /// Key/value pairs for backend configuration. ServiceInfo shall return a list of keys that a backend supports. Keys are case insensitive. It is expected that clients pass all runtime or hardware requirement key/values that are not mapped to existing tesResources properties to backend_parameters. Backends shall log system warnings if a key is passed that is unsupported. Backends shall not store or return unsupported keys if included in a task. If backend_parameters_strict equals true, backends should fail the task if any key/values are unsupported, otherwise, backends should attempt to run the task Intended uses include VM size selection, coprocessor configuration, etc. Example: ``` { \"backend_parameters\" : { \"VmSize\" : \"Standard_D64_v3\" } } ``` + #[serde(rename = "backend_parameters", skip_serializing_if = "Option::is_none")] + pub backend_parameters: Option>, + /// If set to true, backends should fail the task if any backend_parameters key/values are unsupported, otherwise, backends should attempt to run the task + #[serde(rename = "backend_parameters_strict", skip_serializing_if = "Option::is_none")] + pub backend_parameters_strict: Option, +} + +impl TesResources { + /// Resources describes the resources requested by a task. + pub fn new() -> TesResources { + TesResources { + cpu_cores: None, + preemptible: None, + ram_gb: None, + disk_gb: None, + zones: None, + backend_parameters: None, + backend_parameters_strict: None, + } + } +} + diff --git a/lib/src/TES/models/tes_service_info.rs b/lib/src/TES/models/tes_service_info.rs new file mode 100644 index 0000000..3747a85 --- /dev/null +++ b/lib/src/TES/models/tes_service_info.rs @@ -0,0 +1,73 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesServiceInfo { + /// Unique ID of this service. Reverse domain name notation is recommended, though not required. The identifier should attempt to be globally unique so it can be used in downstream aggregator services e.g. Service Registry. + #[serde(rename = "id")] + pub id: String, + /// Name of this service. Should be human readable. + #[serde(rename = "name")] + pub name: String, + #[serde(rename = "type")] + pub r#type: Box, + /// Description of the service. Should be human readable and provide information about the service. + #[serde(rename = "description", skip_serializing_if = "Option::is_none")] + pub description: Option, + #[serde(rename = "organization")] + pub organization: Box, + /// URL of the contact for the provider of this service, e.g. a link to a contact form (RFC 3986 format), or an email (RFC 2368 format). + #[serde(rename = "contactUrl", skip_serializing_if = "Option::is_none")] + pub contact_url: Option, + /// URL of the documentation of this service (RFC 3986 format). This should help someone learn how to use your service, including any specifics required to access data, e.g. authentication. + #[serde(rename = "documentationUrl", skip_serializing_if = "Option::is_none")] + pub documentation_url: Option, + /// Timestamp describing when the service was first deployed and available (RFC 3339 format) + #[serde(rename = "createdAt", skip_serializing_if = "Option::is_none")] + pub created_at: Option, + /// Timestamp describing when the service was last updated (RFC 3339 format) + #[serde(rename = "updatedAt", skip_serializing_if = "Option::is_none")] + pub updated_at: Option, + /// Environment the service is running in. Use this to distinguish between production, development and testing/staging deployments. Suggested values are prod, test, dev, staging. However this is advised and not enforced. + #[serde(rename = "environment", skip_serializing_if = "Option::is_none")] + pub environment: Option, + /// Version of the service being described. Semantic versioning is recommended, but other identifiers, such as dates or commit hashes, are also allowed. The version should be changed whenever the service is updated. + #[serde(rename = "version")] + pub version: String, + /// Lists some, but not necessarily all, storage locations supported by the service. + #[serde(rename = "storage", skip_serializing_if = "Option::is_none")] + pub storage: Option>, + /// Lists all tesResources.backend_parameters keys supported by the service + #[serde(rename = "tesResources_backend_parameters", skip_serializing_if = "Option::is_none")] + pub tes_resources_backend_parameters: Option>, +} + +impl TesServiceInfo { + pub fn new(id: String, name: String, r#type: models::TesServiceType, organization: models::ServiceOrganization, version: String) -> TesServiceInfo { + TesServiceInfo { + id, + name, + r#type: Box::new(r#type), + description: None, + organization: Box::new(organization), + contact_url: None, + documentation_url: None, + created_at: None, + updated_at: None, + environment: None, + version, + storage: None, + tes_resources_backend_parameters: None, + } + } +} + diff --git a/lib/src/TES/models/tes_service_type.rs b/lib/src/TES/models/tes_service_type.rs new file mode 100644 index 0000000..efd7386 --- /dev/null +++ b/lib/src/TES/models/tes_service_type.rs @@ -0,0 +1,46 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesServiceType { + /// Namespace in reverse domain name format. Use `org.ga4gh` for implementations compliant with official GA4GH specifications. For services with custom APIs not standardized by GA4GH, or implementations diverging from official GA4GH specifications, use a different namespace (e.g. your organization's reverse domain name). + #[serde(rename = "group")] + pub group: String, + #[serde(rename = "artifact")] + pub artifact: Artifact, + /// Version of the API or specification. GA4GH specifications use semantic versioning. + #[serde(rename = "version")] + pub version: String, +} + +impl TesServiceType { + pub fn new(group: String, artifact: Artifact, version: String) -> TesServiceType { + TesServiceType { + group, + artifact, + version, + } + } +} +/// +#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)] +pub enum Artifact { + #[serde(rename = "tes")] + Tes, +} + +impl Default for Artifact { + fn default() -> Artifact { + Self::Tes + } +} + diff --git a/lib/src/TES/models/tes_state.rs b/lib/src/TES/models/tes_state.rs new file mode 100644 index 0000000..3c6d627 --- /dev/null +++ b/lib/src/TES/models/tes_state.rs @@ -0,0 +1,65 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesState : Task state as defined by the server. - `UNKNOWN`: The state of the task is unknown. The cause for this status message may be dependent on the underlying system. The `UNKNOWN` states provides a safe default for messages where this field is missing so that a missing field does not accidentally imply that the state is QUEUED. - `QUEUED`: The task is queued and awaiting resources to begin computing. - `INITIALIZING`: The task has been assigned to a worker and is currently preparing to run. For example, the worker may be turning on, downloading input files, etc. - `RUNNING`: The task is running. Input files are downloaded and the first Executor has been started. - `PAUSED`: The task is paused. The reasons for this would be tied to the specific system running the job. An implementation may have the ability to pause a task, but this is not required. - `COMPLETE`: The task has completed running. Executors have exited without error and output files have been successfully uploaded. - `EXECUTOR_ERROR`: The task encountered an error in one of the Executor processes. Generally, this means that an Executor exited with a non-zero exit code. - `SYSTEM_ERROR`: The task was stopped due to a system error, but not from an Executor, for example an upload failed due to network issues, the worker's ran out of disk space, etc. - `CANCELED`: The task was canceled by the user, and downstream resources have been deleted. - `CANCELING`: The task was canceled by the user, but the downstream resources are still awaiting deletion. - `PREEMPTED`: The task is stopped (preempted) by the system. The reasons for this would be tied to the specific system running the job. Generally, this means that the system reclaimed the compute capacity for reallocation. +/// Task state as defined by the server. - `UNKNOWN`: The state of the task is unknown. The cause for this status message may be dependent on the underlying system. The `UNKNOWN` states provides a safe default for messages where this field is missing so that a missing field does not accidentally imply that the state is QUEUED. - `QUEUED`: The task is queued and awaiting resources to begin computing. - `INITIALIZING`: The task has been assigned to a worker and is currently preparing to run. For example, the worker may be turning on, downloading input files, etc. - `RUNNING`: The task is running. Input files are downloaded and the first Executor has been started. - `PAUSED`: The task is paused. The reasons for this would be tied to the specific system running the job. An implementation may have the ability to pause a task, but this is not required. - `COMPLETE`: The task has completed running. Executors have exited without error and output files have been successfully uploaded. - `EXECUTOR_ERROR`: The task encountered an error in one of the Executor processes. Generally, this means that an Executor exited with a non-zero exit code. - `SYSTEM_ERROR`: The task was stopped due to a system error, but not from an Executor, for example an upload failed due to network issues, the worker's ran out of disk space, etc. - `CANCELED`: The task was canceled by the user, and downstream resources have been deleted. - `CANCELING`: The task was canceled by the user, but the downstream resources are still awaiting deletion. - `PREEMPTED`: The task is stopped (preempted) by the system. The reasons for this would be tied to the specific system running the job. Generally, this means that the system reclaimed the compute capacity for reallocation. +#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)] +pub enum TesState { + #[serde(rename = "UNKNOWN")] + Unknown, + #[serde(rename = "QUEUED")] + Queued, + #[serde(rename = "INITIALIZING")] + Initializing, + #[serde(rename = "RUNNING")] + Running, + #[serde(rename = "PAUSED")] + Paused, + #[serde(rename = "COMPLETE")] + Complete, + #[serde(rename = "EXECUTOR_ERROR")] + ExecutorError, + #[serde(rename = "SYSTEM_ERROR")] + SystemError, + #[serde(rename = "CANCELED")] + Canceled, + #[serde(rename = "PREEMPTED")] + Preempted, + #[serde(rename = "CANCELING")] + Canceling, + +} + +impl ToString for TesState { + fn to_string(&self) -> String { + match self { + Self::Unknown => String::from("UNKNOWN"), + Self::Queued => String::from("QUEUED"), + Self::Initializing => String::from("INITIALIZING"), + Self::Running => String::from("RUNNING"), + Self::Paused => String::from("PAUSED"), + Self::Complete => String::from("COMPLETE"), + Self::ExecutorError => String::from("EXECUTOR_ERROR"), + Self::SystemError => String::from("SYSTEM_ERROR"), + Self::Canceled => String::from("CANCELED"), + Self::Preempted => String::from("PREEMPTED"), + Self::Canceling => String::from("CANCELING"), + } + } +} + +impl Default for TesState { + fn default() -> TesState { + Self::Unknown + } +} + diff --git a/lib/src/TES/models/tes_task.rs b/lib/src/TES/models/tes_task.rs new file mode 100644 index 0000000..68355cc --- /dev/null +++ b/lib/src/TES/models/tes_task.rs @@ -0,0 +1,71 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesTask : Task describes an instance of a task. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesTask { + /// Task identifier assigned by the server. + #[serde(rename = "id", skip_serializing_if = "Option::is_none")] + pub id: Option, + #[serde(rename = "state", skip_serializing_if = "Option::is_none")] + pub state: Option, + /// User-provided task name. + #[serde(rename = "name", skip_serializing_if = "Option::is_none")] + pub name: Option, + /// Optional user-provided description of task for documentation purposes. + #[serde(rename = "description", skip_serializing_if = "Option::is_none")] + pub description: Option, + /// Input files that will be used by the task. Inputs will be downloaded and mounted into the executor container as defined by the task request document. + #[serde(rename = "inputs", skip_serializing_if = "Option::is_none")] + pub inputs: Option>, + /// Output files. Outputs will be uploaded from the executor container to long-term storage. + #[serde(rename = "outputs", skip_serializing_if = "Option::is_none")] + pub outputs: Option>, + #[serde(rename = "resources", skip_serializing_if = "Option::is_none")] + pub resources: Option>, + /// An array of executors to be run. Each of the executors will run one at a time sequentially. Each executor is a different command that will be run, and each can utilize a different docker image. But each of the executors will see the same mapped inputs and volumes that are declared in the parent CreateTask message. Execution stops on the first error. + #[serde(rename = "executors")] + pub executors: Vec, + /// Volumes are directories which may be used to share data between Executors. Volumes are initialized as empty directories by the system when the task starts and are mounted at the same path in each Executor. For example, given a volume defined at `/vol/A`, executor 1 may write a file to `/vol/A/exec1.out.txt`, then executor 2 may read from that file. (Essentially, this translates to a `docker run -v` flag where the container path is the same for each executor). + #[serde(rename = "volumes", skip_serializing_if = "Option::is_none")] + pub volumes: Option>, + /// A key-value map of arbitrary tags. These can be used to store meta-data and annotations about a task. Example: ``` { \"tags\" : { \"WORKFLOW_ID\" : \"cwl-01234\", \"PROJECT_GROUP\" : \"alice-lab\" } } ``` + #[serde(rename = "tags", skip_serializing_if = "Option::is_none")] + pub tags: Option>, + /// Task logging information. Normally, this will contain only one entry, but in the case where a task fails and is retried, an entry will be appended to this list. + #[serde(rename = "logs", skip_serializing_if = "Option::is_none")] + pub logs: Option>, + /// Date + time the task was created, in RFC 3339 format. This is set by the system, not the client. + #[serde(rename = "creation_time", skip_serializing_if = "Option::is_none")] + pub creation_time: Option, +} + +impl TesTask { + /// Task describes an instance of a task. + pub fn new(executors: Vec) -> TesTask { + TesTask { + id: None, + state: None, + name: None, + description: None, + inputs: None, + outputs: None, + resources: None, + executors, + volumes: None, + tags: None, + logs: None, + creation_time: None, + } + } +} + diff --git a/lib/src/TES/models/tes_task_log.rs b/lib/src/TES/models/tes_task_log.rs new file mode 100644 index 0000000..90d219e --- /dev/null +++ b/lib/src/TES/models/tes_task_log.rs @@ -0,0 +1,49 @@ +/* + * Task Execution Service + * + * ## Executive Summary The Task Execution Service (TES) API is a standardized schema and API for describing and executing batch execution tasks. A task defines a set of input files, a set of containers and commands to run, a set of output files and some other logging and metadata. TES servers accept task documents and execute them asynchronously on available compute resources. A TES server could be built on top of a traditional HPC queuing system, such as Grid Engine, Slurm or cloud style compute systems such as AWS Batch or Kubernetes. ## Introduction This document describes the TES API and provides details on the specific endpoints, request formats, and responses. It is intended to provide key information for developers of TES-compatible services as well as clients that will call these TES services. Use cases include: - Deploying existing workflow engines on new infrastructure. Workflow engines such as CWL-Tes and Cromwell have extentions for using TES. This will allow a system engineer to deploy them onto a new infrastructure using a job scheduling system not previously supported by the engine. - Developing a custom workflow management system. This API provides a common interface to asynchronous batch processing capabilities. A developer can write new tools against this interface and expect them to work using a variety of backend solutions that all support the same specification. ## Standards The TES API specification is written in OpenAPI and embodies a RESTful service philosophy. It uses JSON in requests and responses and standard HTTP/HTTPS for information transport. HTTPS should be used rather than plain HTTP except for testing or internal-only purposes. ### Authentication and Authorization Is is envisaged that most TES API instances will require users to authenticate to use the endpoints. However, the decision if authentication is required should be taken by TES API implementers. If authentication is required, we recommend that TES implementations use an OAuth2 bearer token, although they can choose other mechanisms if appropriate. Checking that a user is authorized to submit TES requests is a responsibility of TES implementations. ### CORS If TES API implementation is to be used by another website or domain it must implement Cross Origin Resource Sharing (CORS). Please refer to https://w3id.org/ga4gh/product-approval-support/cors for more information about GA4GH’s recommendations and how to implement CORS. + * + * The version of the OpenAPI document: 1.1.0 + * + * Generated by: https://openapi-generator.tech + */ + +use crate::models; + +/// TesTaskLog : TaskLog describes logging information related to a Task. +#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)] +pub struct TesTaskLog { + /// Logs for each executor + #[serde(rename = "logs")] + pub logs: Vec, + /// Arbitrary logging metadata included by the implementation. + #[serde(rename = "metadata", skip_serializing_if = "Option::is_none")] + pub metadata: Option>, + /// When the task started, in RFC 3339 format. + #[serde(rename = "start_time", skip_serializing_if = "Option::is_none")] + pub start_time: Option, + /// When the task ended, in RFC 3339 format. + #[serde(rename = "end_time", skip_serializing_if = "Option::is_none")] + pub end_time: Option, + /// Information about all output files. Directory outputs are flattened into separate items. + #[serde(rename = "outputs")] + pub outputs: Vec, + /// System logs are any logs the system decides are relevant, which are not tied directly to an Executor process. Content is implementation specific: format, size, etc. System logs may be collected here to provide convenient access. For example, the system may include the name of the host where the task is executing, an error message that caused a SYSTEM_ERROR state (e.g. disk is full), etc. System logs are only included in the FULL task view. + #[serde(rename = "system_logs", skip_serializing_if = "Option::is_none")] + pub system_logs: Option>, +} + +impl TesTaskLog { + /// TaskLog describes logging information related to a Task. + pub fn new(logs: Vec, outputs: Vec) -> TesTaskLog { + TesTaskLog { + logs, + metadata: None, + start_time: None, + end_time: None, + outputs, + system_logs: None, + } + } +} + diff --git a/lib/src/service.rs b/lib/src/service.rs new file mode 100644 index 0000000..e69de29