Get rid of implementation specific Interfaces

[mszostok]

Description

1. We allow referencing Implementation
   1. By Content Developer: In workflow
   2. By User: Running specific Implementation directly
2. Still, Implementation always Implements at least one Interface
   1. It cannot be a generic Interface. For now, it will be assured by content review and written down in our best practices guide. Later we can add automated checks, e.g. the cap.core.type.generic.value Type is not used in Interfaces.
      1. It can be just a warning in the same way how the Helm lint does e.g. with iconURL “enforcement”.
3. Add option to specify additionalInput parameters which can be used in: advanced rendering mode and when referencing Implementation directly (e.g. via CLI when creating an Action or in umbrella workflows).

Option B: Nested Policy support

1. Renderer: Inject additionalInput into workflow as Argo artifact
   1. Populate it similarly as e.g. input parameters
   2. If empty, create output empty artifact (to avoid rendering fail)
2. Support One-time policy from User
   1. Engine: Extend Action CR with One time policy ref
   2. Allow passing users one-time Policy - store in ConfigMap/Secret
   3. Support it via CLI and GraphQL API
      1. Interactive and passing policy from file
3. Support nested Policy in workflow (Content Developer uses that) \<MD: 5MD>
   1. In the future, they could be overridden by advanced rendering.
   2. Support passing additionalInput in Policy
   3. To discuss: Per step or per Implementation manifest

1. [DRAFT - to discuss] Policy priorities

   1. Cluster Policy
   2. User Policy for first Action (before running workfow)
   3. Workflow Policy (created by Content Developer)
   4. User Policy for step (in advanced rendering)
   5. make the Policy priorities order configurable
      1. All policies on different levels are merged into one single Policy
   6. To discuss - see how Helm it does
      1. UX → naming
      2. Property naming
      3. Feature naming (policy or something else)
      4. How to define it with as little boilerplate as possible
      5. Update docs and describe clearly how the policies on different level work
      6. CLI: Naming --user-policy-from-file?
   1. OCH manifests
      1. OCF Schema: Add additionalInput for Implementation to OCF JSON schema
      2. Cleanup Interface parameters for RocketChat, BitBucket, Jira, Crowd, Confluence etc. Move all K8s specific params to Implementation.additionalInput with dedicated JSON schema
      3. Remove Impl-specific Interfaces and Implementations for RDS and Elasticsearch
         1. Reduce the Implementations to single one with additionalInput with dedicated JSON schema
         2. You don’t need to install all apps to verify - just compare values.yaml
      4. Create one Type with shared k8s parameters - If possible
         1. If there are common parameters from additionalInput for different Implementations, extract them to dedicated Type
      5. Update tutorials if needed

---

Discarded option

Click to expand

Option A: Static imports for Implementation 1. Modify Action CR and add ability to pass multiple parameters 1. list/map of input parameters - save all in Secret 1. update GraphQL API for Engine 1. Update CLI - add option to pass multiple different params 1. Renderer - iterate over input params and output them as multiple artifacts 1. update renderer unit tests - test multiple params 1. Engine: Allow running Implementation as Action by User 1. Modify Renderer to not assume that we run Interface every time 1. As we need to query Interface, pick first one from the `implements` list 1. Get Impl/Interface based on prefix (`cap.implementation`, `cap.interface`) 1. Policy: get Interface for a given Implementation and inject TypeInstances based on policy 1. For now we support just a single item on `implements` list, so take just first Interface from the list 1. Engine/Renderer: Allow referring Implementation in `action` field in workflow 1. Implementation will be imported (in `imports` ) in the same way as Interface currently 1. Rename `imports.interfaceGroupPath` → `imports.pathPrefix` 1. Additional input parameters are passed as input artifact similarly to current `input-parameters` (with different name) ```yaml artifacts: - name: input-parameters from: "`steps.fill-aws-params-in-module-args.outputs.artifacts.render`" - name: additional-input # dedicated name specified in `Implementation.additionalInput`? from: ""``` ```

Reason

Currently, Interfaces are implementation specific which violates one of our main paradigm

Subtasks

• https://github.com/capactio/capact/issues/329
• https://github.com/capactio/capact/issues/330
• https://github.com/capactio/capact/issues/331

[Trojan295]

Closed after finishing #329, #330, #331.