templateを呼び出す側にarguments
呼び出されるtemplate側にinputs
がある。
呼び出し時にargumentsに入力した値は、呼ばれたtemplateのinputsに渡る。
WorkflowTemplateのspec.argumentsはWorkflowTemplateをSUBMITするときにUIやCLIから入力できる。
https://scrapbox.io/files/619702c25f91e7002099fd50.png
/icons/hr.icon
WorkflowTemplatesを設計するための「適切な」方法は何ですか? 具体的には、私が苦労しているのは、WorkflowTemplateのテンプレートレベルのinputsの存在と同様にトップレベルにargumentsが存在することです。 もちろん、templateRefを介してWorkflowTemplateを呼び出す場合は、特定のテンプレートを指定する必要があるため、そのテンプレートのinputsを提供する必要があります。
ただし、奇妙なことに、UIからWorkflowTemplatesを送信すると、この動作が矛盾します。 entrypointを特定のテンプレートとして指定しているにもかかわらず、UIに入力をレンダリングするのは最上位のargumentsのみです。 私が期待するのは、レンダリングされた入力が、WorkflowTemplateレベルのargumentsではなく、選択したentrypointの入力を反映することです。 実際、現在の動作は少し無意味であることがわかりました。entrypointは静的でargumentsを指定するか、entrypointは動的である必要がありますが、選択したentrypointの入力が表示されます。
ただし、元の質問に戻すために、私のチームは組織向けにマネージドArgoプラットフォームを構築しています。 私たちがWorkflowTemplatesにアプローチした方法は、関連する機能のセットをグループ化することです。各機能は、WorkflowTemplateの下の個別のテンプレートです。 例として、リモートクラスターでKubernetes操作を実行するためのテンプレートを作成しました。 したがって、get-resourceテンプレート、create-resourceテンプレートなどがあります。これはお勧めですか? または、それぞれに完全に別個のWorkflowTemplateを用意することをお勧めしますか? templateRefが本質的に機能する方法は、それを実行する方法が論理的であることを示唆しています。 ただし、UIの動作方法は、このようにすべきではないことを示唆しています。
/icons/hr.icon
同意しました。エントリポイントはUIで静的であるか、UIが選択されたエントリポイントを反映するように使用可能な引数を更新する必要があります。
個人的には、WorkflowTemplateを「呼び出し可能なワークフロー」と考えています。 しかし、WorkflowTemplateを考えるもう1つの完全に有効な方法は、「呼び出し可能なテンプレートのライブラリ(小文字のtを強調)」です。
個人的に、私があなただった場合…WorkflowTemplateの各テンプレートが重要な場合(たとえば、40行以上)、それを独自のWorkflowTemplateに配置します。 私はWorkflowTemplateが「できること」であるという考えが好きです。 しかし、各テンプレートがほんの数行である場合、重複した定型YAMLは私を苛立たせます。
/icons/hr.icon
tl; dr-Argo Workflowsは、それ自体の利益のために柔軟性が高すぎる場合があります。 あなたにとって意味のあることをしてください。