From 6169c1edb71ae07c60a60d1e51b4275a13179d25 Mon Sep 17 00:00:00 2001 From: Pawel Kosiec Date: Fri, 20 Aug 2021 12:42:12 +0200 Subject: [PATCH 1/2] Update documentation after required TypeInstance syntax change in Policy --- docs/content-development/terraform-manifests.md | 2 +- docs/example/mattermost-installation.md | 6 ++---- docs/feature/policies/global-policy.md | 10 +++++----- docs/feature/policies/overview.md | 12 ++++++------ 4 files changed, 14 insertions(+), 16 deletions(-) diff --git a/docs/content-development/terraform-manifests.md b/docs/content-development/terraform-manifests.md index 80cde57..d7e2bd8 100644 --- a/docs/content-development/terraform-manifests.md +++ b/docs/content-development/terraform-manifests.md @@ -99,6 +99,6 @@ To make sure the Terraform-based Implementation is selected, you may use additio requires: - path: "cap.type.gcp.auth.service-account" inject: - typeInstances: + requiredTypeInstances: # (...) ``` diff --git a/docs/example/mattermost-installation.md b/docs/example/mattermost-installation.md index 7f708db..fd95c16 100644 --- a/docs/example/mattermost-installation.md +++ b/docs/example/mattermost-installation.md @@ -221,11 +221,9 @@ To change the Mattermost installation, we need to adjust our Global policy to pr requires: - path: "cap.type.gcp.auth.service-account" inject: - typeInstances: + requiredTypeInstances: - id: ${TI_ID} - typeRef: - path: "cap.type.gcp.auth.service-account" - revision: "0.1.0" + description: "GCP Service Account" - interface: path: cap.* oneOf: diff --git a/docs/feature/policies/global-policy.md b/docs/feature/policies/global-policy.md index fd1e82e..5d84445 100644 --- a/docs/feature/policies/global-policy.md +++ b/docs/feature/policies/global-policy.md @@ -27,12 +27,12 @@ rules: # Configures the following behavior for Engine during rendering Action - path: "cap.type.gcp.auth.service-account" # in any revision inject: - typeInstances: # For such Implementation, inject the following TypeInstances: + requiredTypeInstances: # For such Implementation, inject the following TypeInstances if matching Type Reference is used in `Implementation.spec.requires` property along with `alias`: + + # Find Type Reference for the given TypeInstance ID. Then, find the alias of the Type reference in `spec.requires` property. + # If it is defined, inject the TypeInstance with ID `9038dcdc-e959-41c4-a690-d8ebf929ac0c` under this alias. - id: 9038dcdc-e959-41c4-a690-d8ebf929ac0c - typeRef: # Find the alias of the Type reference in `spec.requires` property. - # If it is defined, inject the TypeInstance with ID `9038dcdc-e959-41c4-a690-d8ebf929ac0c` under this alias. - path: "cap.type.gcp.auth.service-account" - revision: "0.1.0" + description: "GCP Service Account" # optional - implementationConstraints: # In second place find and select Implementation which: attributes: # contains the following attributes diff --git a/docs/feature/policies/overview.md b/docs/feature/policies/overview.md index 47354b8..6cc524b 100644 --- a/docs/feature/policies/overview.md +++ b/docs/feature/policies/overview.md @@ -122,9 +122,11 @@ You can also deny all Implementations for a given Interface with the following s oneOf: [] # deny all Implementations for a given Interface ``` -### TypeInstance injection +### Required TypeInstance injection -Along with Implementation constraints, Cluster Admin may configure TypeInstances, which are downloaded and injected in the Implementation workflow. This can be helpful for example, in case you are using Implementations, which are deploying infrastructure on a public cloud (like AWS or GCP) and you want to ensure that everything is deployed in the same account. For example: +Along with Implementation constraints, Cluster Admin may configure TypeInstances, which are downloaded and injected in the Implementation workflow. The prerequisite is that the Implementation must contain matching Type Reference in `spec.requires` property, along with defined `alias` for such requirement. + +This can be helpful, for example, in case you are using Implementations, which are deploying infrastructure on a public cloud (like AWS or GCP) and you want to ensure that everything is deployed in the same account. For example: ```yaml rules: @@ -135,11 +137,9 @@ rules: requires: - path: "cap.type.gcp.auth.service-account" inject: - typeInstances: + requiredTypeInstances: - id: 9038dcdc-e959-41c4-a690-d8ebf929ac0c - typeRef: - path: "cap.type.gcp.auth.service-account" - revision: "0.1.0" + description: "GCP Service Account" # optional ``` > **NOTE:** Instructions how to create a TypeInstance using the Capact CLI can be found [here](./../../cli/commands/capact_typeinstance_create.md). From bcca3bc6b6e87d7bde37a021fcb1d9a52e2a95cb Mon Sep 17 00:00:00 2001 From: Pawel Kosiec Date: Fri, 20 Aug 2021 16:46:04 +0200 Subject: [PATCH 2/2] Fix typos --- docs/feature/policies/overview.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/feature/policies/overview.md b/docs/feature/policies/overview.md index 6cc524b..151a26f 100644 --- a/docs/feature/policies/overview.md +++ b/docs/feature/policies/overview.md @@ -161,7 +161,7 @@ Even if the Implementation satisfies the constraints, and the `alias` is not def ### Additional parameter injection -You can also provide additional parameters to tweak the Implementation. The Implementation parameters Type is specified in the Implementation manifest in `.spec.additionalInput.parameters`. For example, for AWS RDS for Postgresql Implementation you can provide additional parameters of Type `cap.type.aws.rds.postgresql.install-input`: +You can also provide additional parameters to tweak the Implementation. The Implementation parameters Type is specified in the Implementation manifest in `.spec.additionalInput.parameters`. For example, for AWS RDS for PostgreSQL Implementation you can provide additional parameters of Type `cap.type.aws.rds.postgresql.install-input`: ```yaml metadata: @@ -191,7 +191,7 @@ rules: ## Merging of different policies -There are three different policies, which are merged together, when rendering the Action: Global, Action and Workflow step policies. Merging is necessary to calculate the final policy, which is used to select an Implementation and inject TypeInstaces and parameters. The priority order of the policies is configurable by the Capact Admin. The default order is (highest to lowest): +There are three different policies, which are merged together, when rendering the Action: Global, Action and Workflow step policies. Merging is necessary to calculate the final policy, which is used to select an Implementation and inject TypeInstances and parameters. The priority order of the policies is configurable by the Capact Admin. The default order is (highest to lowest): 1. Action policy 2. Global policy 3. Workflow step policy