工作流命名空间

概述

Mistral 允许在命名空间内创建工作流。因此，只要它们位于不同的命名空间中，就可以创建许多具有相同名称的工作流。当用户已经拥有许多相互连接的工作流（有些是其他工作流的子工作流），并且其中一个工作流名称已被使用，而用户又不想编辑该工作流及其所有引用它的工作流，或者将它们合并到工作簿中时，这非常有用。这是可能的，因为命名空间不是 Mistral 工作流语言的一部分。

如果想要使用命名空间，需要在通过 REST API 或 CLI 运行的相应操作中提供额外的参数。如果未提供，Mistral 将在默认命名空间内运行。

REST API 参数

为了使用命名空间，Mistral 的许多 REST API 方法都具有可选的 namespace 参数

• 在命名空间内创建工作流定义

  POST /v2/workflows?namespace=<namespace>
  
  <Workflow YAML text>
  

• 在命名空间内删除工作流定义

  DELETE /v2/workflows/<workflow id>?namespace=<namespace>
  

• 在命名空间内获取工作流定义

  GET /v2/workflows/<workflow id>?namespace=<namespace>
  

• 获取给定命名空间内的所有工作流定义

  GET /v2/workflows?namespace=<namespace>
  

• 更新给定命名空间内的工作流定义

  PUT /v2/workflows?namespace=<namespace>
  
  <Workflow YAML text>
  

• 创建属于非默认命名空间的工作流的执行

  POST /v2/executions
  
  {
    "workflow_name": "<workflow id or name>",
    "workflow_namespace": "<namespace>",
    ...
  }
  

解析工作流定义

了解 Mistral 在运行工作流时如何考虑命名空间解析工作流定义，以及工作流层次结构中的命名空间如何工作非常重要。

规则如下

• 如果用户通过 API（或 CLI）启动工作流，则明确提供了工作流名称和相应的命名空间，因此 Mistral 将在提供的命名空间下查找具有给定名称的工作流定义。如果未指定命名空间，则将使用默认命名空间（空命名空间值）。如果 Mistral 未找到具有给定名称和命名空间的工作流定义，它将返回错误响应。

• 如果工作流作为子工作流启动，即它在不同工作流中具有父任务，则 Mistral 使用父工作流的命名空间来解析工作流定义。换句话说，Mistral 将命名空间传播到其子工作流。但是，如果工作流定义不存在于父工作流的命名空间中，则 Mistral 将尝试在默认命名空间中找到它。 这与通过 API 启动工作流的情况不同，Mistral 会返回错误，而不是尝试在默认命名空间中查找工作流定义。

• 作为工作簿一部分声明的工作流始终位于默认命名空间中。

为了说明所有这些工作原理，让我们看一下以下工作流定义

---
version: '2.0'

wf1:
  tasks:
    t1:
      workflow: wf2

---
version: '2.0'

wf2:
  tasks:
    t2:
      workflow: wf3

---
version: '2.0'

wf3:
  tasks:
    t3:
      action: std.noop

---
version: '2.0'

wf3:
  tasks:
    should_not_run:
      action: std.fail

因此，调用链如下所示

wf1 -> wf2 -> wf3

但是，请注意，我们有两个名为“wf3”的工作流。

假设这些工作流定义上传到 Mistral 的命名空间如下

ID	name	namespace
1	wf1	abc
2	wf2
3	wf3	abc
4	wf3

然后我们通过 API 创建一个工作流执行，如下所示

POST /v2/executions

{
  "workflow_name": "wf1",
  "workflow_namespace": "abc"
}

在这种情况下，Mistral 将

• 在命名空间“abc”中找到“wf1”（它反正不在默认命名空间中）

• 尝试在命名空间“abc”中找到“wf2”，由于它不存在，Mistral 将在默认命名空间中找到它

• 因为它是从“wf1”传播过来的，所以在命名空间“abc”中找到“wf3”

但是，如果我们像这样启动一个工作流

POST /v2/executions

{
  "workflow_name": "wf2"
}

我们将获得调用链

wf2 -> wf3

因为未向端点提供非默认命名空间，所以两个工作流定义都将从默认命名空间获取。