diff --git a/docs/admin-guide/configurations.md b/docs/admin-guide/configurations.md
index 290596843..3d596dfa3 100644
--- a/docs/admin-guide/configurations.md
+++ b/docs/admin-guide/configurations.md
@@ -11,10 +11,10 @@ The Configuration page consolidates key system settings and administrative confi
### 1. White Labeling
-Customize the Torque interface with your organization's branding by uploading a custom logo. This ensures a **consistent and professional** look throughout the platform.
+Customize the interface with your organization's branding by uploading a custom logo. This ensures a **consistent and professional** look throughout the platform.
This feature allows you to:
-- Replace the default Torque logo across the system.
+- Replace the default logo across the system.
- Upload three logo types: Favicon, Wide Logo, and Square Logo.
**How to upload your logo**
@@ -55,13 +55,13 @@ This feature allows you to create and manage announcement banners to notify user
### 3. Audit Logs
-Torque’s **Audit Logs** provide comprehensive tracking of key platform activities, helping you monitor user behavior, investigate security risks, and maintain compliance.
+’s **Audit Logs** provide comprehensive tracking of key platform activities, helping you monitor user behavior, investigate security risks, and maintain compliance.
Options include:
- ElasticSearch: With built-in **Elastic Stack integration**, you can forward audit data for real-time analysis and reporting.
-- Torque Audit: Forward logs to Torque, and retain for 18 months..
+- Audit: Forward logs to , and retain for 18 months..
**How to set up an Audit Log destination**
-📖 Learn more about [Torque Audit](/governance/audit-log/audit-log-configuration)
+📖 Learn more about [ Audit](/governance/audit-log/audit-log-configuration)
info 🔒 Audit log integration is available for **Enterprise plans only** and requires a specific licensing feature.
@@ -69,29 +69,30 @@ info 🔒 Audit log integration is available for **Enterprise plans only** and
### 4. Copilot Settings
-Enable Torque’s AI-powered assistant to provide recommendations and enhance workflow automation, within your account.
+Enable ’s AI-powered assistant to provide recommendations and enhance workflow automation, within your account.
These settings include 2 features:
-**1. Torque Copilot** – Easily navigate Torque with our AI chatbot, always accessible and leveraging the official documentation for swift exploration.
+**1. Copilot** – Easily navigate with our AI chatbot, always accessible and leveraging the official documentation for swift exploration.
(This feature is based on a 3rd party tool called DocsBot)
-**How to enable Torque Copilot**
+**How to enable Copilot**
1. Navigate to **Configuration > Copilot Settings**.
-2. Toggle on the ‘Torque Copilot’ toggle to show the AI chatbot button at the top header, next to the rest of the utilities.
+2. Toggle on the ‘ Copilot’ toggle to show the AI chatbot button at the top header, next to the rest of the utilities.
3. Toggle off to hide the AI chatbot and to prevent access from all users.
**2. Cloud Copilot** – Your internal AI assistance to create and customize Blueprints, auto-generate descriptions, and resolve live environment errors.
-This AI assistant tool is subject to the [Torque MSA](https://www.quali.com/legal-torque-master-subscription-agreement/) and requires user consent.
+This AI assistant tool is subject to the [ MSA](https://www.quali.com/legal-torque-master-subscription-agreement/) and requires user consent.
With this feature you can:
- **Auto-generate descriptions** for blueprints, to effortlessly expand the details on every blueprint in the account.
- **(Blueprint) Cloud Copilot** - Create and customize blueprints from your Building Blocks Library, using simple language prompts and the power of AI.
-
+ 
-- **AI Insights** - Get AI assistant when you need it. Resolve issues in live environments, by clicking the “Get AI Insights” button, on every error log in your environment.
-
+- **AI Insights** - Get AI assistant when you need it. Resolve issues in live environments, by clicking the “Get AI Insights” button, on every error log in your environment.
+
+ 
@@ -99,7 +100,7 @@ With this feature you can:
1. Navigate to **Configuration > Copilot Settings**.
2. Under the ‘Cloud Copilot’ section > click on the **‘AI Provider’ button** to select where to host your AI Data while using Copilot:
- - Host in **Torque’s Open AI
+ - Host in **’s Open AI
**There’s no further configuration, just click ‘Connect’
- Host in your own **Azure OpenAI service
**You’ll have to provide: API key, Endpoint URL, GPT-4o deployment name, and GPT-4o mini deployment name.
@@ -133,16 +134,18 @@ info 🔒 SSO Login is optionally available for **Enterprise plans only**.
### 6. Email Reports
Subscribe to the ‘Weekly Digest’, a summary email providing key account activity insights.
-Torque's weekly digest reports condense the most important information from a week's worth of data collected in Torque, making it easier for Torque administrators to quickly understand the most critical developments.
-Torque ‘Weekly Digest’ emails are being sent to Torque administrators and will highlight:
+'s weekly digest reports condense the most important information from a week's worth of data collected in , making it easier for administrators to quickly understand the most critical developments.
+The ‘Weekly Digest’ emails are being sent to administrators and will highlight:
- Cloud usage
-- Torque users activity
+- Users activity
- Environments usage
- Cloud Cost
- Top used IaC modules
- Top contributors to the operation
+Example:
+
**How to Enable Email Reports**
@@ -187,9 +190,9 @@ When enabled by the account admin:
### 9. Experimental Features
-Experimental Features give account administrators early access to upcoming capabilities in Torque that are still in development. These features are in a **beta** or **testing phase** and may not yet be fully supported or stable.
+Experimental Features give account administrators early access to upcoming capabilities in that are still in development. These features are in a **beta** or **testing phase** and may not yet be fully supported or stable.
-This settings gives **Torque administrators early visibility and hands-on access** to major upcoming features and UI changes—allowing them to explore, prepare, and influence what’s coming before it rolls out to all users.
+This settings gives ** administrators early visibility and hands-on access** to major upcoming features and UI changes—allowing them to explore, prepare, and influence what’s coming before it rolls out to all users.
**What You Need to Know**
@@ -199,7 +202,7 @@ This settings gives **Torque administrators early visibility and hands-on access
- 📆 Each experiment includes a defined **trial period** with a description of what’s new.
- 📩 Admins can provide feedback via:
-> A **survey form** linked within the experiment.
- -> A **support ticket** submitted through the Torque support system.
+ -> A **support ticket** submitted through the support system.
**How to Use Experimental Features**
@@ -218,7 +221,7 @@ Once the experiment ends:
- You’ll receive updates in the product and via release notes.
-🛠 **Note**: Enabling experimental features is a great way to influence Torque’s roadmap and help improve future releases.
+🛠 **Note**: Enabling experimental features is a great way to influence ’s roadmap and help improve future releases.
info 🔒 Experimental Features are optionally available for **Enterprise plans only**.
diff --git a/docs/admin-guide/credentials.md b/docs/admin-guide/credentials.md
index 990fdde72..74b94f2bf 100644
--- a/docs/admin-guide/credentials.md
+++ b/docs/admin-guide/credentials.md
@@ -3,7 +3,7 @@ sidebar_position: 6
title: Credentials
---
-The Torque __Credentials__ store is a built-in capability for Torque to securely store your Public Cloud authentication details in order for CloudFormation and Terraform type grains to securely access them. Credentials are similar in usage to [Parameters](/admin-guide/params), but unlike parameters which are single-value, credentials are specialized objects that contain multiple values with different structure depending on the credential type. Torque Credentials are supported for AWS (role based and access key based) and Azure (secret based) authentication.
+The __Credentials__ store is a built-in capability for to securely store your Public Cloud authentication details in order for CloudFormation and Terraform type grains to securely access them. Credentials are similar in usage to [Parameters](/admin-guide/params), but unlike parameters which are single-value, credentials are specialized objects that contain multiple values with different structure depending on the credential type. Credentials are supported for AWS (role based and access key based) and Azure (secret based) authentication.
__To add a credential:__
@@ -13,7 +13,7 @@ __To add a credential:__
1. Give the credential a name and optionally a description.
2. Select the cloud provider (AWS / Azure).
3. Select the credential type and enter the authentication details.
- * For AWS, role assumption and access key credentials are supported. Make sure you have a Role Arn that allows Torque access. For details, see the [Get Role ARN and external ID](#get-role-arn-and-external-id) section below.
+ * For AWS, role assumption and access key credentials are supported. Make sure you have a Role Arn that allows access. For details, see the [Get Role ARN and external ID](#get-role-arn-and-external-id) section below.
> 
* For Azure, only Service Principle Client ID and Secret are supported.
> 
@@ -34,7 +34,7 @@ Once created, you can reference the credentials in the grain's ```authentication
3. In the navigation pane of the IAM console, select __Roles__, and then click __Create Role__.
1. From __Select trusted entity__, choose __AWS Account__.
- 2. Under An AWS account ID, select __An AWS account__ and enter 349148204654. (This is the Torque AWS account from which we will query the cost).
+ 2. Under An AWS account ID, select __An AWS account__ and enter 349148204654. (This is the AWS account from which we will query the cost).
3. Select __Require external ID__.
4. Enter an __External ID__ of your choosing. The External Id will be used to validate the Consumer of the ARN Role. __Keep note of the external ID as you will need it later in the configuration step__.
5. In __Next:Permissions__, select the policy you have just created in step 1 for cost exploration permission.
diff --git a/docs/admin-guide/input-sources.md b/docs/admin-guide/input-sources.md
index 7dfb2ad5a..5bb500d4a 100644
--- a/docs/admin-guide/input-sources.md
+++ b/docs/admin-guide/input-sources.md
@@ -6,7 +6,7 @@ title: Input Sources
# Input Sources
## Overview
-The **Input Sources** feature is a significant enhancement for Torque users, providing a more dynamic and flexible way to retrieve and manage input values from external data sources. Whether you're dealing with multiple S3 buckets or preparing for future integrations with other external sources, this feature streamlines your workflow and ensures your configurations are always up-to-date.
+The **Input Sources** feature is a significant enhancement for users, providing a more dynamic and flexible way to retrieve and manage input values from external data sources. Whether you're dealing with multiple S3 buckets or preparing for future integrations with other external sources, this feature streamlines your workflow and ensures your configurations are always up-to-date.
During the launch environment process, this feature simplifies the handling of multiple data sources by using a single configuration template, and allowing real-time listing of S3 bucket objects.
## Key Benefits
@@ -110,7 +110,7 @@ Below is an example SVG diagram illustrating the architecture for using an HTTP
### Creating an Input Source
-Torque role: Account admin
+ role: Account admin
:::tip __Important__
Modifying or deleting an Input Source may cause blueprints that use the Input Source to fail.
@@ -118,7 +118,7 @@ Modifying or deleting an Input Source may cause blueprints that use the Input So
#### General Steps
-1. **Navigate to Input Sources:** Access the Input Sources section in your Torque Account Settings.
+1. **Navigate to Input Sources:** Access the Input Sources section in your Account Settings.
2. **Add New Source:** Click on the "Connect a new Input Source" button.
3. **Select preferred provider:** Choose between AWS S3 bucket, Azure Blob Storage, or HTTP Server.
@@ -193,7 +193,7 @@ Modifying or deleting an Input Source may cause blueprints that use the Input So
### Using an Input Source in Blueprints
-Torque role: Space Developer
+ role: Space Developer
To use an input source in a blueprint:
diff --git a/docs/admin-guide/notifications.md b/docs/admin-guide/notifications.md
index 6c7e5c348..1705dc285 100644
--- a/docs/admin-guide/notifications.md
+++ b/docs/admin-guide/notifications.md
@@ -3,7 +3,7 @@ sidebar_position: 15
title: Notifications
---
-Torque Notifications enable space admins to define notifications for environment lifecycle events and environment owner/collaborator changes. The notifications will be sent to your email address, Teams or Slack chats, or the automation tool of your choice. You can define multiple notifications for different communication tools, and for different channels in the same communication tool.
+ Notifications enable space admins to define notifications for environment lifecycle events and environment owner/collaborator changes. The notifications will be sent to your email address, Teams or Slack chats, or the automation tool of your choice. You can define multiple notifications for different communication tools, and for different channels in the same communication tool.
Supported events:
@@ -35,8 +35,8 @@ Supported events:
**Space Events:**
* Agent Disconnected
-__To configure Torque notifications:__
-1. In Torque, access the suitable space.
+__To configure notifications:__
+1. In , access the suitable space.
2. Click __Settings > Notifications__.
3. Click __+ Add Notification__.
4. Select the suitable communication tool (Slack, Teams, or generic webhook).
@@ -49,6 +49,6 @@ __To configure Torque notifications:__
* This step is not needed for Email, as we'll configure the notifications to be sent to the logged-in user's email address.
7. For generic webhooks, optionally provide a token from the tool to send with the notification, and select the desired event to test.
8. Test the configuration.
-9. Click __Send Test Message__ and make sure you receive a Torque notification message in the chat or generic tool.
+9. Click __Send Test Message__ and make sure you receive a notification message in the chat or generic tool.
10. Click __Select Notifications__ to select the notifications to send.
11. Click __Apply__.
diff --git a/docs/admin-guide/params.md b/docs/admin-guide/params.md
index ecb4ea683..4a67f60cb 100644
--- a/docs/admin-guide/params.md
+++ b/docs/admin-guide/params.md
@@ -3,13 +3,13 @@ sidebar_position: 2
title: Parameters
---
-The Torque parameter store is a repository of key-value pairs, which can be used and reused in blueprint YAMLs across all spaces in Torque. Two types of parameters are supported:
-* Account-level parameters are defined by the Torque account admin and can be used across all spaces. As such, these parameters are typically used to store data that applies to multiple spaces.
+The parameter store is a repository of key-value pairs, which can be used and reused in blueprint YAMLs across all spaces in . Two types of parameters are supported:
+* Account-level parameters are defined by the account admin and can be used across all spaces. As such, these parameters are typically used to store data that applies to multiple spaces.
* Space-level parameters are defined by space admins and apply to specific spaces.
## Creating Account-level parameters
-Torque role: Account admin
+ role: Account admin
:::tip __Important__
Modifying or deleting a parameter may cause blueprints that use the parameter to fail.
@@ -31,7 +31,7 @@ __To add an account-level parameter:__
## Creating space-level parameters
-Torque role: Space admin
+ role: Space admin
__To add a space-level parameter:__
diff --git a/docs/admin-guide/source-control/Self Hosted Repositories/overview.md b/docs/admin-guide/source-control/Self Hosted Repositories/overview.md
index 12a5e25d6..cac080566 100644
--- a/docs/admin-guide/source-control/Self Hosted Repositories/overview.md
+++ b/docs/admin-guide/source-control/Self Hosted Repositories/overview.md
@@ -2,16 +2,16 @@
sidebar_position: 1
title: Using Self-Managed source control providers
---
-Torque can integrate with any source control provider, whether it's a public SaaS platform (e.g., github.com) or a self-managed instance running on your premises. When using a self-managed source control provider, the communication between Torque and the source control server is fully contained within your site, happening between the Torque agent installed on your cluster and the source control server installed on your premises.
+ can integrate with any source control provider, whether it's a public SaaS platform (e.g., github.com) or a self-managed instance running on your premises. When using a self-managed source control provider, the communication between and the source control server is fully contained within your site, happening between the agent installed on your cluster and the source control server installed on your premises.
> 
-There are three steps when configuring Torque to read from a self-hosted source control provider:
+There are three steps when configuring to read from a self-hosted source control provider:
1. **Install an Agent**
2. **Generate a Personal Access Token**
-3. **Add your repositories to Torque** (Can be done from the Torque UI, API, or Torque Terraform Provider)
+3. **Add your repositories to ** (Can be done from the UI, API, or Terraform Provider)
See the following sections with specific details how to configure each self-managed source control provider:
@@ -21,4 +21,4 @@ See the following sections with specific details how to configure each self-mana
3. [BitBucket Enterprise (on-premise)](/admin-guide/source-control/Self%20Hosted%20Repositories/self-managed-bitbucket)
4. Azure Repositories on-premise - Supported, Please contact support for detailed instructions
-With a self-managed source control provider configured in Torque, you can securely manage and version control your assets stored in your on-premises source control system, while keeping all communication within your network boundaries.
\ No newline at end of file
+With a self-managed source control provider configured in , you can securely manage and version control your assets stored in your on-premises source control system, while keeping all communication within your network boundaries.
\ No newline at end of file
diff --git a/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-bitbucket.md b/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-bitbucket.md
index c4265c4c9..7bc039bc1 100644
--- a/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-bitbucket.md
+++ b/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-bitbucket.md
@@ -3,11 +3,11 @@ sidebar_position: 3
title: Self-Managed BitBucket
---
-Torque supports connecting to self-managed BitBucket repositories, allowing you to discover and manage assets stored in your on-premises BitBucket instance.
+ supports connecting to self-managed BitBucket repositories, allowing you to discover and manage assets stored in your on-premises BitBucket instance.
## Prerequisites
-1. **Agent Installation**: You must have the Torque Agent installed with access to your self-managed BitBucket instance.
+1. **Agent Installation**: You must have the Agent installed with access to your self-managed BitBucket instance.
2. **BitBucket Access Token**: You will need a BitBucket Personal Access Token with the following permission scopes:
1. `api`
2. `read.api`
@@ -23,4 +23,4 @@ Torque supports connecting to self-managed BitBucket repositories, allowing you
> 
-With a self-managed BitBucket repository configured in Torque, you can seamlessly manage and version control your assets stored in your on-premises BitBucket instance.
\ No newline at end of file
+With a self-managed BitBucket repository configured in , you can seamlessly manage and version control your assets stored in your on-premises BitBucket instance.
\ No newline at end of file
diff --git a/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-github.md b/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-github.md
index 2d3004b1b..511ad92ae 100644
--- a/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-github.md
+++ b/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-github.md
@@ -3,7 +3,7 @@ sidebar_position: 4
title: Self-Managed GitHub
---
-Torque supports connecting to self-managed GitHub repositories, allowing you to discover and manage assets stored in your on-premises GitHub instance.
+ supports connecting to self-managed GitHub repositories, allowing you to discover and manage assets stored in your on-premises GitHub instance.
## Prerequisites
* GitHub personal access token with read access for repositories in the server
diff --git a/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-gitlab.md b/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-gitlab.md
index 20a0adcc2..633c63eee 100644
--- a/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-gitlab.md
+++ b/docs/admin-guide/source-control/Self Hosted Repositories/self-managed-gitlab.md
@@ -3,11 +3,11 @@ sidebar_position: 2
title: Self-Managed GitLab
---
-Torque supports connecting to self-managed GitLab repositories, allowing you to discover and manage assets stored in your on-premises GitLab instance.
+ supports connecting to self-managed GitLab repositories, allowing you to discover and manage assets stored in your on-premises GitLab instance.
## Prerequisites
-1. **Agent Installation**: You must have the Torque Agent installed with access to your self-managed GitLab instance.
+1. **Agent Installation**: You must have the Agent installed with access to your self-managed GitLab instance.
2. **GitLab Access Token**: You will need a GitLab Personal Access Token with the following permission scopes:
1. `api`
2. `read_api`
@@ -26,4 +26,4 @@ Torque supports connecting to self-managed GitLab repositories, allowing you to
> 
-With a self-managed GitLab repository configured in Torque, you can seamlessly manage and version control your assets stored in your on-premises GitLab instance.
\ No newline at end of file
+With a self-managed GitLab repository configured in , you can seamlessly manage and version control your assets stored in your on-premises GitLab instance.
\ No newline at end of file
diff --git a/docs/admin-guide/source-control/secret-manager-git-integration.md b/docs/admin-guide/source-control/secret-manager-git-integration.md
index 0880de655..c1fe1276c 100644
--- a/docs/admin-guide/source-control/secret-manager-git-integration.md
+++ b/docs/admin-guide/source-control/secret-manager-git-integration.md
@@ -6,13 +6,13 @@ title: AWS Secrets Manager for Git Integration
# Using AWS Secrets Manager for Git Repository Access
## Overview
-This guide explains how to use AWS Secrets Manager to manage and retrieve credentials for accessing a Git repository within the Torque platform. By using Secrets Manager, you can securely store and retrieve access tokens, which are then utilized by Torque's asset discovery (agent) and provisioning (runner) components, simplifying repository credential management while adhering to organizational security policies.
+This guide explains how to use AWS Secrets Manager to manage and retrieve credentials for accessing a Git repository within the platform. By using Secrets Manager, you can securely store and retrieve access tokens, which are then utilized by 's asset discovery (agent) and provisioning (runner) components, simplifying repository credential management while adhering to organizational security policies.
## Scope
-This guide supports the use of third-party secret management services, specifically AWS Secrets Manager, to retrieve repository tokens for use in the Torque platform. This provides a flexible and secure way to manage repository credentials during asset discovery and provisioning processes.
+This guide supports the use of third-party secret management services, specifically AWS Secrets Manager, to retrieve repository tokens for use in the platform. This provides a flexible and secure way to manage repository credentials during asset discovery and provisioning processes.
## Motivation
-Integrating AWS Secrets Manager into Torque allows users to manage repository credentials in a more secure manner, facilitating seamless integration with Torque's asset discovery and provisioning capabilities. It enhances adaptability to customer policies on secrets storage and management, thus streamlining secure repository access within Torque.
+Integrating AWS Secrets Manager into allows users to manage repository credentials in a more secure manner, facilitating seamless integration with 's asset discovery and provisioning capabilities. It enhances adaptability to customer policies on secrets storage and management, thus streamlining secure repository access within .
## Steps to Configure AWS Secrets Manager for Repository Access
@@ -37,7 +37,7 @@ Integrating AWS Secrets Manager into Torque allows users to manage repository cr
]
}
```
-2. **Add Trust Relationship**: Add a trust relationship policy to allow the Torque cluster to assume this role.
+2. **Add Trust Relationship**: Add a trust relationship policy to allow the cluster to assume this role.
```json
{
"Effect": "Allow",
@@ -48,9 +48,9 @@ Integrating AWS Secrets Manager into Torque allows users to manage repository cr
}
```
-### Step 3: Configure Git Credentials in Torque
-1. **Install the Agent**: Ensure that the Torque agent is installed.
-2. **Navigate to Torque Credentials**: In the Torque portal, navigate to the **Account Admin** -> **Credentials** page.
+### Step 3: Configure Git Credentials in
+1. **Install the Agent**: Ensure that the agent is installed.
+2. **Navigate to Credentials**: In the portal, navigate to the **Account Admin** -> **Credentials** page.
3. **Add New Git Credential**: Click on **Add New Credential** and select the credential type as **Gitlab**. In the dropdown list, choose the **Secret Manager** option.
import pic1 from '/img/git-secret-manager.png';
@@ -67,7 +67,7 @@ import pic1 from '/img/git-secret-manager.png';
- **Secret Path**: Represents the hierarchy of fields inside the secret's value.
- **External ID** is optional but can be provided if required by your security policies.
- The secret will be used by Torque's asset discovery (agent) or provisioning (runner) components to interact securely with the Git repository.
+ The secret will be used by 's asset discovery (agent) or provisioning (runner) components to interact securely with the Git repository.
## Troubleshooting
1. **Verify Secret Retrieval**: You can manually verify that the secret can be retrieved using the AWS CLI or SDK to ensure proper configuration.
@@ -96,5 +96,5 @@ import pic1 from '/img/git-secret-manager.png';
- **Audit and Monitoring**: Enable AWS CloudTrail to monitor access to your secrets and ensure compliance with your organization’s security policies.
## Summary
-By utilizing AWS Secrets Manager, you can securely store and manage Git repository credentials for use within the Torque platform, improving the security and compliance of your asset discovery and provisioning workflows. Follow the above steps to integrate Secrets Manager seamlessly with your Git operations in Torque.
+By utilizing AWS Secrets Manager, you can securely store and manage Git repository credentials for use within the platform, improving the security and compliance of your asset discovery and provisioning workflows. Follow the above steps to integrate Secrets Manager seamlessly with your Git operations in .
diff --git a/docs/admin-guide/source-control/source-control-azure-repos.md b/docs/admin-guide/source-control/source-control-azure-repos.md
index afc6ff90b..66643cd80 100644
--- a/docs/admin-guide/source-control/source-control-azure-repos.md
+++ b/docs/admin-guide/source-control/source-control-azure-repos.md
@@ -3,31 +3,31 @@ sidebar_position: 3
title: Azure Repos Source Control
---
-Torque supports connecting asset/blueprint repositories on Azure Repos out of the box. However, to connect a repository, you must have access to the repository and grant Torque permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
+ supports connecting asset/blueprint repositories on Azure Repos out of the box. However, to connect a repository, you must have access to the repository and grant permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
**This article refers to the SAAS version of Azure Repos. If you're using Azure Repos behind your firewall, check [here](/admin-guide/source-control/Self%20Hosted%20Repositories/overview)**.
-When connecting a repository, Torque’s OAuth app (**QTorque Portal**) asks for permissions to access repositories on your organization.
-If Torque doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the Azure Applications page (https://dev.azure.com/{you_org}/_usersSettings/authorizations).
+When connecting a repository, ’s OAuth app (**QTorque Portal**) asks for permissions to access repositories on your organization.
+If doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the Azure Applications page (https://dev.azure.com/{you_org}/_usersSettings/authorizations).
-1. In Torque, go to the space's Settings > Repositories area and connect the repository. Note that the repository URL should be in the correct format: https://dev.azure.com/{org_name}/{project_name}/_git/{repo_name}
+1. In , go to the space's Settings > Repositories area and connect the repository. Note that the repository URL should be in the correct format: https://dev.azure.com/{org_name}/{project_name}/_git/{repo_name}
2. Authorize the organization.
> 
-3. Go to Azure Applications (see above) and make sure the Torque application has been authorized.
+3. Go to Azure Applications (see above) and make sure the application has been authorized.
> 
-At this point, the Torque app was given the necessary permissions to the organization.
-4. Return to Torque and continue setting up the connection.
+At this point, the app was given the necessary permissions to the organization.
+4. Return to and continue setting up the connection.
#### Troubleshooting
In some cases, repository access might be restricted or limited due to several seasons. Following the below steps and retry to onboard your repository once you apply the changes.
-1. Make sure your Azure DevOps instance is open for accepting external communication - make sure no security/networking rule is applied between Torque and Azure DevOps.
+1. Make sure your Azure DevOps instance is open for accepting external communication - make sure no security/networking rule is applied between and Azure DevOps.
2. In the Azure DevOps security organization settings - make sure that "Third-party application access via OAuth" is enabled
> 
diff --git a/docs/admin-guide/source-control/source-control-bitbucket.md b/docs/admin-guide/source-control/source-control-bitbucket.md
index fe4b7e431..768b3b327 100644
--- a/docs/admin-guide/source-control/source-control-bitbucket.md
+++ b/docs/admin-guide/source-control/source-control-bitbucket.md
@@ -3,22 +3,22 @@ sidebar_position: 4
title: BitBucket Source Control
---
-Torque supports connecting asset/blueprint repositories on BitBucket out of the box. However, to connect a repository, you must have access to the repository and grant Torque permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
+ supports connecting asset/blueprint repositories on BitBucket out of the box. However, to connect a repository, you must have access to the repository and grant permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
**This article refers to the SAAS version of BitBucket. If you're using self-hosted BitBucket, check [here](/admin-guide/source-control/Self%20Hosted%20Repositories/overview)**.
-When connecting a repository, Torque’s OAuth app (QTorque Portal) asks for permissions to access repositories on your organization.
-If Torque doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the [Bitbucket Applications](https://bitbucket.org/account/settings/app-authorizations/) page.
+When connecting a repository, ’s OAuth app (QTorque Portal) asks for permissions to access repositories on your organization.
+If doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the [Bitbucket Applications](https://bitbucket.org/account/settings/app-authorizations/) page.
-1. In Torque, go to the space's Settings > Repositories area and connect the repository.
-2. Authorize the organization Quali Torque
+1. In , go to the space's Settings > Repositories area and connect the repository.
+2. Authorize the organization Quali
> 
-3. Go to Azure Applications (see above) and make sure the Torque application has been authorized.
+3. Go to Azure Applications (see above) and make sure the application has been authorized.
> 
-At this point, the Torque app was given the necessary permissions to the organization.
+At this point, the app was given the necessary permissions to the organization.
-4. Return to Torque and continue setting up the connection.
+4. Return to and continue setting up the connection.
diff --git a/docs/admin-guide/source-control/source-control-codecommit.md b/docs/admin-guide/source-control/source-control-codecommit.md
index 40d74e4f1..8ac55dd42 100644
--- a/docs/admin-guide/source-control/source-control-codecommit.md
+++ b/docs/admin-guide/source-control/source-control-codecommit.md
@@ -3,11 +3,11 @@ sidebar_position: 5
title: CodeCommit Source Control
---
-Torque supports connecting assets, blueprints and policies repositories on CodeCommit out of the box. To connect a repository, you need to grant Torque access to your repository of interest. Torque will access the repo (read only) both from the Torque SAAS application on AWS as well as from the runners on your cluster.
+ supports connecting assets, blueprints and policies repositories on CodeCommit out of the box. To connect a repository, you need to grant access to your repository of interest. will access the repo (read only) both from the SAAS application on AWS as well as from the runners on your cluster.
## Prerequisites
-1. Create a role for Torque to use which has permissions to connect to CodeCommit. To do that, follow the instructions:
+1. Create a role for to use which has permissions to connect to CodeCommit. To do that, follow the instructions:
1. Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/.
2. In the IAM console, in the navigation pane, choose "Roles", and then choose "Create Role".
3. In Select trusted entities, choose "AWS account", and select "Another AWS account".
@@ -32,7 +32,7 @@ Torque supports connecting assets, blueprints and policies repositories on CodeC
2. 📝***Take note of the the user name and password***.📝
4. Initialize your CodeCommit Repository
- 1. CodeCommit does not have default files or a default branch until a file is committed, blocking Torque from adding this repo
+ 1. CodeCommit does not have default files or a default branch until a file is committed, blocking from adding this repo
> 
> 
2. We recommend making a "blueprints" folder at the root of the repo with a single dummy yaml file. Please note the file extensions in the image below.
@@ -40,9 +40,9 @@ Torque supports connecting assets, blueprints and policies repositories on CodeC
3. Now we will verify the file is there and that the main branch has created.
> 
> 
- 4. Finally we can now onboard the repo into Torque!
+ 4. Finally we can now onboard the repo into !
-## Connecting a CodeCommit Repository to Torque
+## Connecting a CodeCommit Repository to
In your space, navigate to "Repositories" and click on "Add Repositories".
Choose the CodeCommit icon and fill in the requested details from the pre-requisites. For region, use the region where the CodeCommit hosting this repo is.
diff --git a/docs/admin-guide/source-control/source-control-github.md b/docs/admin-guide/source-control/source-control-github.md
index f2c95c0e7..6ce16c1a7 100644
--- a/docs/admin-guide/source-control/source-control-github.md
+++ b/docs/admin-guide/source-control/source-control-github.md
@@ -3,11 +3,11 @@ sidebar_position: 1
title: GitHub Source Control
---
-Torque supports connecting asset/blueprint repositories on GitHub out of the box. However, to connect a repository, you must have access to the repository and grant Torque permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
+ supports connecting asset/blueprint repositories on GitHub out of the box. However, to connect a repository, you must have access to the repository and grant permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
**In this article:**
- [Ensure your account is added to the GitHub organization you're connecting](#ensure-your-account-is-added-to-the-github-organization-youre-connecting)
-- [Ensure your organization has granted access to Torque](#ensure-your-organization-has-granted-access-to-torque)
+- [Ensure your organization has granted access to ](#ensure-your-organization-has-granted-access-to-torque)
- [Token expiration and revocation](#token-expiration-and-revocation)
**This article refers to the SAAS version of GitHub (github.com). If you're using self hosted GitHub Enterprise, check [here](/admin-guide/source-control/Self%20Hosted%20Repositories/overview)**.
@@ -18,26 +18,26 @@ Torque supports connecting asset/blueprint repositories on GitHub out of the box
1. Go to [https://github.com/orgs/\{YOUR_ORG\}/people](https://github.com/orgs/\{YOUR_ORG\}/people).
2. Make sure your user is listed in the organization. If not, make sure the user is added as a member with global read access.
-## Ensure your organization has granted access to Torque
+## Ensure your organization has granted access to
-When connecting a repository, Torque installs an OAuth app called __Torque Control Plane__ on the organization. This app provides Torque with the necessary permissions to the organization's repositories. If Torque doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the [GitHub Applications](https://github.com/settings/applications) page.
+When connecting a repository, installs an OAuth app called __Torque Control Plane__ on the organization. This app provides with the necessary permissions to the organization's repositories. If doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the [GitHub Applications](https://github.com/settings/applications) page.
1. Go to [GitHub Applications](https://github.com/settings/applications).
2. Revoke any existing access to the __Quali Torque__ app.
> 
- 3. In Torque, go to the space's __Settings > Repositories__ area and connect the repository.
+ 3. In , go to the space's __Settings > Repositories__ area and connect the repository.
4. Authorize the organization.
> 
- At this point, the Torque app is installed in the organization without permissions.
+ At this point, the app is installed in the organization without permissions.
5. Enter your account's password and confirm the action.
* If you're not an administrator in the organization, ask the administrator to grant access to the app in the [GitHub Applications](https://github.com/settings/applications) page.
* If you already authorized the __Torque Control Plane__ app without also granting access to an organization with repositories you want to connect, click the app's name in the GitHub Applications page, and in the __Organization access__ section, click the organization's __Request__ button.
> 
- The Torque app is granted the necessary permissions and the repository is connected.
- 6. Return to Torque and continue setting up the connection.
+ The app is granted the necessary permissions and the repository is connected.
+ 6. Return to and continue setting up the connection.
## Token expiration and revocation
diff --git a/docs/admin-guide/source-control/source-control-gitlab.md b/docs/admin-guide/source-control/source-control-gitlab.md
index f974564b7..c2786d11a 100644
--- a/docs/admin-guide/source-control/source-control-gitlab.md
+++ b/docs/admin-guide/source-control/source-control-gitlab.md
@@ -3,30 +3,30 @@ sidebar_position: 2
title: GitLab Source Control
---
-Torque supports connecting asset/blueprint repositories on GitLab out of the box. To connect a repository, you must have access to the repository and grant Torque permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
+ supports connecting asset/blueprint repositories on GitLab out of the box. To connect a repository, you must have access to the repository and grant permission to the repository's organization, as explained below. For details about connecting a repository, see [Discover Your Assets](/getting-started/asset-discovery). You should be able to sign in with an account on any one of these online services and immediately get going with connecting asset repositories and launching environments.
**This article refers to the SAAS version of GitLab. If you're using self hosted GitLab, check [here](/admin-guide/source-control/Self%20Hosted%20Repositories/overview)**.
-## Ensure the Torque application was added to the GitLab organization you're connecting
+## Ensure the application was added to the GitLab organization you're connecting
1. Go to [https://gitlab.com/-/profile/applications](https://gitlab.com/-/profile/applications).
2. Scroll down to the __Authorized application__ section and make sure __Qtorque.io-Social__ has the __openid profile email read_user__ scope.
-## Ensure your organization has granted access to Torque
+## Ensure your organization has granted access to
-When connecting a repository, Torque installs an OAuth app called __Qtorque__ on the organization. This app provides Torque with the necessary permissions to the organization's repositories. If Torque doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the [GitLab Applications](https://gitlab.com/-/profile/applications) page.
+When connecting a repository, installs an OAuth app called __Qtorque__ on the organization. This app provides with the necessary permissions to the organization's repositories. If doesn't have access, you will be prompted to grant the proper authorizations when connecting the asset repository. The approved applications are listed in the [GitLab Applications](https://gitlab.com/-/profile/applications) page.
- 1. In Torque, go to the space's __Settings > Repositories__ area and connect the repository.
+ 1. In , go to the space's __Settings > Repositories__ area and connect the repository.
2. Authorize the organization.
> 
- 3. Go to [GitLab Applications](https://gitlab.com/-/profile/applications) and make sure the Torque application has been authorized.
+ 3. Go to [GitLab Applications](https://gitlab.com/-/profile/applications) and make sure the application has been authorized.
> 
- At this point, the Torque app is installed in the organization with the necessary permissions.
+ At this point, the app is installed in the organization with the necessary permissions.
* If you're not an administrator in the organization, ask the administrator to grant access to the app in the [GitLab Applications](https://gitlab.com/-/profile/applications) page.
* If you already authorized the __Qtorque__ app without also granting access to a group with repositories you want to connect, make sure your GitLab user is added to that group (__Guest__ role is enough).
- 6. Return to Torque and continue setting up the connection.
+ 6. Return to and continue setting up the connection.
diff --git a/docs/admin-guide/source-control/source-managed-cloudshell.md b/docs/admin-guide/source-control/source-managed-cloudshell.md
index 9b2fc58ab..33a0cd52a 100644
--- a/docs/admin-guide/source-control/source-managed-cloudshell.md
+++ b/docs/admin-guide/source-control/source-managed-cloudshell.md
@@ -3,17 +3,17 @@ sidebar_position: 10
title: Self-Managed Quali CloudShell
---
-Torque supports connecting Quali CloudShell as an asset repository. CloudShell blueprints are treated as assets in Torque and can be referenced using the 'CloudShell' grain type.
+ supports connecting Quali CloudShell as an asset repository. CloudShell blueprints are treated as assets in and can be referenced using the 'CloudShell' grain type.
## Prerequisites
1. CloudShell user with at least "External Extended" permissions in the CloudShell Domains that you want to use.
-2. A self-hosted Torque agent that can reach the Sandbox Api of your CloudShell instance.
+2. A self-hosted agent that can reach the Sandbox Api of your CloudShell instance.
3. CloudShell version 2021.2 and higher.
## Configuration
-1. Register CloudShell as a Repository Provider via Torque REST API. If the API call is successful it will return a GUID representing the ID of the new repository provider. Save this ID for the next step.
+1. Register CloudShell as a Repository Provider via REST API. If the API call is successful it will return a GUID representing the ID of the new repository provider. Save this ID for the next step.
```jsx
curl -L 'https://portal.qtorque.io/api/settings/repository_providers' \
@@ -33,9 +33,9 @@ curl -L 'https://portal.qtorque.io/api/settings/repository_providers' \
}'
```
- * Replace __<TOKEN>__ with a valid Torque token with Torque Admin permissions
+ * Replace __<TOKEN>__ with a valid token with Admin permissions
* Replace __<PROVIDER_NAME>__ with a display name for the CloudShell instance. Example: "CloudShell_Dev"
- * Replace __<CLOUDSHELL_SERVER_URL>__ with the IP or DNS of your CloudShell instance. The CloudShell instance needs to be reachable from at least one of your self-hosted Torque agents. Torque will automatically select an agent for communicating with CloudShell
+ * Replace __<CLOUDSHELL_SERVER_URL>__ with the IP or DNS of your CloudShell instance. The CloudShell instance needs to be reachable from at least one of your self-hosted agents. will automatically select an agent for communicating with CloudShell
* Replace __<SANDBOX_API_PORT>__ with the port of the CloudShell Sandbox API. The default port is 82
* Replace __<CLOUDSHELL_USER>__ and __<CLOUDSHELL_PASSWORD>__ with a valid CloudShell username and password
* Replace __<CLOUDSHELL_DOMAIN>__ with the CloudShell Domain that will be used as the default Domain. If needed you can later set a different Domain per each space
@@ -55,12 +55,12 @@ curl -L 'https://portal.qtorque.io/api/spaces//repositories/clouds
}'
```
- * Replace __<SPACE_NAME>__ with the relevant Torque space
- * Replace __<TOKEN>__ with a valid Torque token with Torque Admin permissions
+ * Replace __<SPACE_NAME>__ with the relevant space
+ * Replace __<TOKEN>__ with a valid token with Admin permissions
* Replace __<PROVIDER_ID>__ with the GUID received from the API in step #1
* Replace __<CLOUDSHELL_SERVER_URL>__ with the IP or DNS of your CloudShell instance.
* Replace __<SANDBOX_API_PORT>>__ with the port of the CloudShell Sandbox API. The default port is 82
- * Replace __<REPOSITORY_NAME>__ with the name you would like to assign to this repository. This name will be used in Torque Blueprints to reference this repo
+ * Replace __<REPOSITORY_NAME>__ with the name you would like to assign to this repository. This name will be used in Blueprints to reference this repo
* [Optional] Replace __<CLOUDSHELL_DOMAIN>__ with the domain name to use for this repository. If omitted, the default Domain name provided in step #1 will be used.
__Note__: The user provided in step #1 must have correct access to the provided Domain.
diff --git a/docs/admin-guide/sso.md b/docs/admin-guide/sso.md
index a480be304..5d8755445 100644
--- a/docs/admin-guide/sso.md
+++ b/docs/admin-guide/sso.md
@@ -3,34 +3,34 @@ sidebar_position: 39
title: SSO Configuration
---
-With just a few simple steps, your organization’s employees can log into Torque with their corporate accounts using SSO.
+With just a few simple steps, your organization’s employees can log into with their corporate accounts using SSO.
-SSO integration provides enhanced security and significant cost-savings as you no longer need to manage your user accounts in Torque and your employees don’t need to remember another set of credentials. Quick, easy and hassle-free.
+SSO integration provides enhanced security and significant cost-savings as you no longer need to manage your user accounts in and your employees don’t need to remember another set of credentials. Quick, easy and hassle-free.
-This is done by integrating your organization's identity provider with Torque's identity management system. Torque uses Okta for identity management and supports integration with all identity providers (IdPs).
+This is done by integrating your organization's identity provider with 's identity management system. uses Okta for identity management and supports integration with all identity providers (IdPs).
**In this article:**
* [How this works](/admin-guide/sso#how-this-works)
-* [Integrating your IdP with Torque](/admin-guide/sso#integrating-your-idp-with-torque)
+* [Integrating your IdP with ](/admin-guide/sso#integrating-your-idp-with-torque)
* [Associating a user to multiple spaces](/admin-guide/sso#associating-a-user-to-multiple-spaces)
-* [Mapping Torque user groups to IdP groups](/admin-guide/sso#mapping-torque-user-groups-to-idp-groups)
+* [Mapping user groups to IdP groups](/admin-guide/sso#mapping-torque-user-groups-to-idp-groups)
* [User provisioning with SCIM](/admin-guide/sso#user-provisioning-with-scim)
## How this works
1. Your Idp admin creates an application on your IdP that defines the relevant users, as explained in the section below.
-2. We map your IdP's client application to Torque's identity management and provide you with an SSO-enabled account.
+2. We map your IdP's client application to 's identity management and provide you with an SSO-enabled account.
3. A member of your organization uses this account to log in.
-4. The user is redirected to Torque's Corporate Account SSO (Single Sign On) login page.
+4. The user is redirected to 's Corporate Account SSO (Single Sign On) login page.
5. The user enters their corporate email address and password.
-6. We authenticate the user against your IdP and grant access to Torque.
+6. We authenticate the user against your IdP and grant access to .
-## Integrating your IdP with Torque
+## Integrating your IdP with
1. On your IdP, create a new client application.
2. In the application, do the following:
- 1. Include the users that will access Torque.
+ 1. Include the users that will access .
2. For each user, specify the following:
- * __space_name__: Torque Space in which the user will operate.
+ * __space_name__: Space in which the user will operate.
* __space_role__: User's role in that space, as defined in __Administration > Roles > Space Roles__. To add a user to multiple spaces, see Associating a user to multiple spaces section below.
* (Optional) __timezone__ : The user's timezone in IANA format (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)
3. Save the application.
@@ -45,9 +45,9 @@ This is done by integrating your organization's identity provider with Torque's
4. Enter a __Subject__. For example: "SSO integration for Quali", and in the description, request SSO integration, and provide the names of the custom user attributes and the application details.
5. Click __Submit__.
- Once SSO integration is set up, the application’s users will be able to use your SSO-enabled account to log in to Torque, as explained in Login to Torque.
+ Once SSO integration is set up, the application’s users will be able to use your SSO-enabled account to log in to , as explained in Login to .
-> NOTE: When the user first logs in via SSO, Torque sets up the user's profile, including contact details, space associations and space/account role settings. However, it is possible to update the user's profile on subsequent SSO logins as well. For details, contact Torque Support.
+> NOTE: When the user first logs in via SSO, sets up the user's profile, including contact details, space associations and space/account role settings. However, it is possible to update the user's profile on subsequent SSO logins as well. For details, contact Support.
## Associating a user to multiple spaces
You can also add a user to multiple spaces, each with a different role. To do so, provide comma-separated values of the space names and corresponding space roles. For example, you could add a user as Space Member to the Trial space and Space Developer to the DevOps space.
@@ -56,16 +56,16 @@ __Points to consider:__
* If there are multiple spaces and only one role, reuse that role in all specified spaces.
* If there are multiple roles for the same space, use the first valid one.
-* If the role name is invalid (unknown value in Torque), assign the Space Member role.
+* If the role name is invalid (unknown value in ), assign the Space Member role.
* If there are more spaces than roles, assign Space Member to the extra spaces.
* If there are more roles than spaces, ignore those extra roles.
-* If the space name is invalid (unknown value in Torque), ignore that space and its corresponding role.
+* If the space name is invalid (unknown value in ), ignore that space and its corresponding role.
-## Mapping Torque user groups to IdP groups
+## Mapping user groups to IdP groups
-Each group in Torque as an ‘IdP identifier’ field. For SSO users to be assigned to the group automatically, the field must contain the same identifier (usually a GUID) as the group in the IdP (the groups don’t have to have the exact same name)
+Each group in as an ‘IdP identifier’ field. For SSO users to be assigned to the group automatically, the field must contain the same identifier (usually a GUID) as the group in the IdP (the groups don’t have to have the exact same name)
-In Torque, this is can be set by editing a group in the ‘Groups’ page under account settings.
+In , this is can be set by editing a group in the ‘Groups’ page under account settings.
> 
@@ -85,7 +85,7 @@ Add the groups claim (using the default settings)
> 
-On the next login, users should be assigned automatically to groups they belong to in Azure and are mapped in Torque (note it sometimes takes a short time before the claims start being sent by AAD after this change)
+On the next login, users should be assigned automatically to groups they belong to in Azure and are mapped in (note it sometimes takes a short time before the claims start being sent by AAD after this change)
### Troubleshooting
@@ -95,7 +95,7 @@ one of the calls will be to ‘idp-callback’, inspect the payload of this call
> 
-The call should contain an id_token field, the contents is a JWT token containing all the claims (user information) sent from the IdP to Torque (through the browser).
+The call should contain an id_token field, the contents is a JWT token containing all the claims (user information) sent from the IdP to (through the browser).
Copy the entire contents of this field (without the field name) and paste it into a JWT token decoder (e.d., on https://jwt.io) to view the contents.
> 
@@ -106,7 +106,7 @@ You can also look for log entries 'Valid login through AzureAD Idp detected' tha
### Configuring Okta to include group information.
-Assuming a working Okta configuration, to get group sync working we need to have group information passed to Okta from the IdP and forwarded from it to Torque with each user login.
+Assuming a working Okta configuration, to get group sync working we need to have group information passed to Okta from the IdP and forwarded from it to with each user login.
This document will show how this is done when the IdP behind Okta happens to be Azure AD (in a SAML 2 configuration and not the OIDC/JWT flow as above), but it is probably similar for other IdPs.
@@ -130,7 +130,7 @@ In Okta, create a new attribute in the profile editor for groups (note the type
> 
-Next, we need to map the groups attribute we just created (that will be filled with group data on login) to a ‘Groups’ field in the user profile that is sent to Torque. Open the ‘mappings’ screen:
+Next, we need to map the groups attribute we just created (that will be filled with group data on login) to a ‘Groups’ field in the user profile that is sent to . Open the ‘mappings’ screen:
> 
@@ -147,20 +147,20 @@ This shows what to expect when using SAML-tracer:
> 
## User provisioning with SCIM
-Torque supports the SCIM protocol for user provisioning and deprovisioning (group provisioning is currently not supported).
-User provisioning is the ability to create and delete users in your Torque account in real-time as they are created and deleted in the IdP (identity provider). When SCIM is configured, an http call will be issued from the IdP to Torque with each new user that is added or removed from the app on the IdP that is used to manage Torque users in the basic SSO process.
+ supports the SCIM protocol for user provisioning and deprovisioning (group provisioning is currently not supported).
+User provisioning is the ability to create and delete users in your account in real-time as they are created and deleted in the IdP (identity provider). When SCIM is configured, an http call will be issued from the IdP to with each new user that is added or removed from the app on the IdP that is used to manage users in the basic SSO process.
-User provisioning with SCIM is optional when configuring SSO. When it is not configured, users can still SSO login normally and their Torque user will be created "just in time" at the moment of login. details about the user are updated with each subsequent login. There are advantage to configuring User provisioning though.
-* Users are created in Torque when added in the IdP, potentially before their first log in. - This allows an admin to get a better picture of who are the users in the Torque account and to perform actions on them before the first time they logged in such as already associating them to spaces, setting them as collaborators on some environments and so on.
-* Users are deprovisioned - Normally, when a user is removed from the IdP, he can no longer login to the Torque account, but the Torque user still appears in the account. Deprovisioning means that one a user cannot SSO into a Torque account, he is removed from it.
+User provisioning with SCIM is optional when configuring SSO. When it is not configured, users can still SSO login normally and their user will be created "just in time" at the moment of login. details about the user are updated with each subsequent login. There are advantage to configuring User provisioning though.
+* Users are created in when added in the IdP, potentially before their first log in. - This allows an admin to get a better picture of who are the users in the account and to perform actions on them before the first time they logged in such as already associating them to spaces, setting them as collaborators on some environments and so on.
+* Users are deprovisioned - Normally, when a user is removed from the IdP, he can no longer login to the account, but the user still appears in the account. Deprovisioning means that one a user cannot SSO into a account, he is removed from it.
-The process of user provisioning/deprovisioning is one directional. changes to users in Torque do not affect the IdP.
+The process of user provisioning/deprovisioning is one directional. changes to users in do not affect the IdP.
### Relation to SSO
-User provisioning (SCIM) is an optional component of SSO and can be omitted, as mentioned above, but when active, it would create a new user in Torque to match a user created or associated in the IdP.
+User provisioning (SCIM) is an optional component of SSO and can be omitted, as mentioned above, but when active, it would create a new user in to match a user created or associated in the IdP.
The new user created is considered 'pending', meaning that this user has never actually logged in before and also that the only way for that user to login is via SSO (pending users do not have a password).
-When that same user later logins with SSO for the first time, Torque identifies that this is the same user as the one created via provisioning and performs a normal login.
-When a user is removed from the IdP, they can no longer login to Torque, if user provisioning was enabled at the time of deletion, then he is deleted from Torque. Regardless, that user can no longer login to the account.
+When that same user later logins with SSO for the first time, identifies that this is the same user as the one created via provisioning and performs a normal login.
+When a user is removed from the IdP, they can no longer login to , if user provisioning was enabled at the time of deletion, then he is deleted from . Regardless, that user can no longer login to the account.
The same app in the IdP is used for both SSO (e.g., using SAML) and for user provisioning.
Note that while SSO is usually
@@ -168,14 +168,14 @@ Note that while SSO is usually
In order to set up user provisioning with SCIM, the following is needed.
* SSO is configured and working in the account.
* Access to the IdP and app that is used for SSO.
-* A long token from Torque with the account level permission of "Manage Users" (e.g., a token generated by an account admin)
+* A long token from with the account level permission of "Manage Users" (e.g., a token generated by an account admin)
-See [**Torque API Tokens**](/rest-api/torque_api_tokens) for generating a token.
+See [** API Tokens**](/rest-api/torque_api_tokens) for generating a token.
The process itself is slightly different for different identity providers, two example are provided below on how to configure SCIM in Okta and in Azure.
### Okta
-Login to Okta's admin console and locate the application that is used for SSO with Torque under "Applications" and then "Applications" again under it.
+Login to Okta's admin console and locate the application that is used for SSO with under "Applications" and then "Applications" again under it.
Under the 'General' tab, set the checkbox on "Enable SCIM provisioning"
> 
@@ -207,10 +207,10 @@ Click 'Edit' under "Provisioning to App" and Enable the checkboxes on "Create Us
> 
-At this point, user provisioning should be working. Associate a user to the app normally (under the "Assignments" tab) and observe that it gets created in the Torque account. in case of an error, a red mark will appear next to the user, this links to the "Dashboard" / "Tasks" page where additional information can be found and the operation can be retried.
+At this point, user provisioning should be working. Associate a user to the app normally (under the "Assignments" tab) and observe that it gets created in the account. in case of an error, a red mark will appear next to the user, this links to the "Dashboard" / "Tasks" page where additional information can be found and the operation can be retried.
### Azure active directory (Entra)
-Login to Azure and navigate to "Enterprise applications", then locate the application used for SSO with your Torque account.
+Login to Azure and navigate to "Enterprise applications", then locate the application used for SSO with your account.
On the left hand side menu pick "Provisioning" and click "Get started"
Set "Provisioning Mode" to Automatic.
Under Admin Credential set the following.
@@ -232,7 +232,7 @@ Click the X at the top right to return to the screen in the screenshot above and
Return to the Overview tab and click "Start provisioning"
At this point, user provisioning should be working.
-Associate a user to the app normally (under the "Users and groups" tab) and observe that it gets created in the Torque account.
+Associate a user to the app normally (under the "Users and groups" tab) and observe that it gets created in the account.
* __Important note__: User provisioning is an offline process in Azure. Changes to user association may take up to 40 minutes to be provisioned. Provisioning logs may also take minutes to show changes.
> 
@@ -262,7 +262,7 @@ In the app's 'Authentication' section, add a redirect URL matching your applicat
```https://your_app_instance.qtorque.io/api/accounts/idp-callback```
### Configurations needed
-To complete the configuration, once successfully registered an AzureAD application, you'll need to provider the following to your Torque Account Manager/Tech support:
+To complete the configuration, once successfully registered an AzureAD application, you'll need to provider the following to your Account Manager/Tech support:
* `Tenant ID`: Your Azure AD tenant ID
* `Client ID`: The client ID of your Azure AD app registration
diff --git a/docs/blueprint-designer-guide/autogenerated-blueprints.md b/docs/blueprint-designer-guide/autogenerated-blueprints.md
index 52350003e..a0cfd6c51 100644
--- a/docs/blueprint-designer-guide/autogenerated-blueprints.md
+++ b/docs/blueprint-designer-guide/autogenerated-blueprints.md
@@ -3,30 +3,30 @@ sidebar_position: 5
title: Auto-generated Blueprints
---
-## Torque auto-generated blueprints
-Torque auto-generated blueprints based on your assets (Terraform modules, Helm Charts). However, you may need to adjust these blueprints to your specific needs. You can modify auto-generated blueprints directly in Torque or in your preferred editor.
+## auto-generated blueprints
+ auto-generated blueprints based on your assets (Terraform modules, Helm Charts). However, you may need to adjust these blueprints to your specific needs. You can modify auto-generated blueprints directly in or in your preferred editor.
### Common fields
- **spec_version** should not be changed.
- **description** may be changed to a better description for your blueprint.
-- **inputs**: Torque generates the inputs based on the inputs in your module. The blueprint inputs are presented to the end user when they launch the blueprint, so they can fill out the inputs and/or override any defaults. These inputs will be the module's inputs upon deployment.
+- **inputs**: generates the inputs based on the inputs in your module. The blueprint inputs are presented to the end user when they launch the blueprint, so they can fill out the inputs and/or override any defaults. These inputs will be the module's inputs upon deployment.
Remove any inputs you don't want to expose in the deployed environment.
### Terraform-specific fields
-Torque currently supports only simple types as blueprint inputs for Terraform (string, boolean and numbers). The inputs that have been auto-generated for you are all "simple type" inputs from your module.
+ currently supports only simple types as blueprint inputs for Terraform (string, boolean and numbers). The inputs that have been auto-generated for you are all "simple type" inputs from your module.
### agent
- **agent**: The kubernetes execution agent that will deploy the environment.
-- **outputs**: Torque generates the outputs based on the outputs of your module. The blueprint's outputs are presented to the end user when they are ready (in the deployed environment).
+- **outputs**: generates the outputs based on the outputs of your module. The blueprint's outputs are presented to the end user when they are ready (in the deployed environment).
Remove any outputs you don't want to expose when the environment is deployed.
- **tf-version**: The terraform version to be used to deploy the module. Change it according to your needs.
### Helm auto-generated blueprints
-Torque currently supports only simple types as blueprint inputs for Helm (string, boolean and numbers). The inputs that have been auto-generated for you are all "simple type" inputs from your Helm chart.
+ currently supports only simple types as blueprint inputs for Helm (string, boolean and numbers). The inputs that have been auto-generated for you are all "simple type" inputs from your Helm chart.
- **commands**: A list of Helm commands to run before installing the chart.
No need to specify the Helm command itself.
@@ -50,18 +50,18 @@ If you have dependencies, add the command `dep up`.
### Editing auto-generated blueprints
-In this section, we'll learn how to edit our auto-generated blueprints in Torque. While Torque conveniently auto-generated blueprints out of your assets, these blueprints may be missing some minor details, like the cluster namespace and execution agent to use, Terraform version, Helm commands to run, etc.
+In this section, we'll learn how to edit our auto-generated blueprints in . While conveniently auto-generated blueprints out of your assets, these blueprints may be missing some minor details, like the cluster namespace and execution agent to use, Terraform version, Helm commands to run, etc.
:::tip __Note__
-Torque only saves the latest version. So if you need versioning, you're welcome to add the modified blueprint to your __/blueprints__ repository.
+ only saves the latest version. So if you need versioning, you're welcome to add the modified blueprint to your __/blueprints__ repository.
:::
-1. In the __Blueprints__ page, click the suitable auto-generated blueprint. Auto-generated blueprints have "Torque" as their modifier.
-2. Make your changes. You can modify the blueprint YAML directly in Torque, or use the __Copy__ / __Download__ buttons to edit the file using your preferred editor. For details, see [Auto-generated Blueprints](/blueprint-designer-guide/autogenerated-blueprints).
+1. In the __Blueprints__ page, click the suitable auto-generated blueprint. Auto-generated blueprints have "" as their modifier.
+2. Make your changes. You can modify the blueprint YAML directly in , or use the __Copy__ / __Download__ buttons to edit the file using your preferred editor. For details, see [Auto-generated Blueprints](/blueprint-designer-guide/autogenerated-blueprints).
> 
-3. Update the blueprint in Torque (if you modified it externally).
+3. Update the blueprint in (if you modified it externally).
4. Click __Save Changes__.
- Torque validates the blueprint and immediately displays any errors in a tooltip next to the blueprint's name.
+ validates the blueprint and immediately displays any errors in a tooltip next to the blueprint's name.
> 
5. Launch the blueprint from the __Catalog__ to make sure it runs as expected.
\ No newline at end of file
diff --git a/docs/blueprint-designer-guide/blueprint-quickstart-guide.md b/docs/blueprint-designer-guide/blueprint-quickstart-guide.md
index e1c0e4344..8fd6208f6 100644
--- a/docs/blueprint-designer-guide/blueprint-quickstart-guide.md
+++ b/docs/blueprint-designer-guide/blueprint-quickstart-guide.md
@@ -3,17 +3,17 @@ sidebar_position: 1
title: Blueprint Design
---
-## What is a Torque blueprint?
+## What is a blueprint?
A blueprint is a template for provisioning an environment that contains references to different IaC Components ("Grains") that together define the applications, cloud infrastructure, networking and policies that make up a specific environment to be deployed. Blueprints are stored as source-controlled YAML files, and each grain in a blueprint is a reference to one IaC or automation file (for example, a Terraform module or a Helm chart) that will be deployed as part of the environment, and the component's designated inputs, outputs and execution information.
A blueprint also contains the orchestration between the grains (provisioning order and dependencies, shared parameter storage, environment duration policies, tag values, etc.), and when launched, deploys a whole environment, from the infrastructure layer to the application itself.
-You can have Torque discover (i.e. generate) blueprints out of your existing Terraform, Helm, CloudFormation, or other supported IaC assets, or you can develop more sophisticated blueprints that deploy a complex environment comprising multiple grains and/or nested blueprints.
+You can have discover (i.e. generate) blueprints out of your existing Terraform, Helm, CloudFormation, or other supported IaC assets, or you can develop more sophisticated blueprints that deploy a complex environment comprising multiple grains and/or nested blueprints.
-## Option A: Let Torque generate blueprints from your assets
-When developing a new blueprint, Torque provides you with the ability to automatically discover the different IaC and Automation assets in your connected source control repository, and generate a blueprint for a single asset (or generate multiple single-asset blueprints in one go).
+## Option A: Let generate blueprints from your assets
+When developing a new blueprint, provides you with the ability to automatically discover the different IaC and Automation assets in your connected source control repository, and generate a blueprint for a single asset (or generate multiple single-asset blueprints in one go).
-These generated blueprints are stored in Torque's backend, and you can customize their inputs, outputs and other details as needed inside an embedded VSCode style IDE from within the Torque Portal. For details on what you can do with generated blueprints, see [Auto-generated Blueprints](./autogenerated-blueprints.md).
+These generated blueprints are stored in 's backend, and you can customize their inputs, outputs and other details as needed inside an embedded VSCode style IDE from within the Portal. For details on what you can do with generated blueprints, see [Auto-generated Blueprints](./autogenerated-blueprints.md).
1. In your space, go to __Settings > Repositories__ and discover your assets.
@@ -23,13 +23,13 @@ import pic1 from '/img/discover-assets.png';
-2. Select one or more assets you want Torque to discover and click __Generate Blueprints__.
+2. Select one or more assets you want to discover and click __Generate Blueprints__.
import pic2 from '/img/select-assets.png';
-Torque creates a blueprint YAML for each selected asset, and lists the blueprints in your space’s __Blueprints__ page.
+ creates a blueprint YAML for each selected asset, and lists the blueprints in your space’s __Blueprints__ page.
3. You can click the blueprint to open it in the embedded VSCode editor. In this editor you can view the blueprint's contents, modify it, preview changes after modification, save the changes, and launch an environment from the blueprint.
@@ -40,21 +40,21 @@ Torque creates a blueprint YAML for each selected asset, and lists the blueprint
You and your space’s users can now launch environments from these blueprints via the **Catalog**.
## Option B: Create a multi-asset blueprint in your source control repository
-So far, we’ve learned how to create single-asset blueprints via auto-generation. But what if you want to create an application-stack environment? This is easily done by having multiple grains in a single blueprint or nesting an existing blueprint within a master blueprint as a grain. To create such a blueprint, you will need an IDE environment that has access to a clone of your repository, in which you can create the new blueprint's YAML file and edit it, and then commit it into your repository and push the changes to the remote repository from which Torque will automatically synchronize the new blueprint.
+So far, we’ve learned how to create single-asset blueprints via auto-generation. But what if you want to create an application-stack environment? This is easily done by having multiple grains in a single blueprint or nesting an existing blueprint within a master blueprint as a grain. To create such a blueprint, you will need an IDE environment that has access to a clone of your repository, in which you can create the new blueprint's YAML file and edit it, and then commit it into your repository and push the changes to the remote repository from which will automatically synchronize the new blueprint.
-By enforcing usage of a source control repository, each blueprint in Torque will have:
+By enforcing usage of a source control repository, each blueprint in will have:
* A full history of tracked changes
* The ability to identify which developer authored those changes
* The ability to retrieve or rollback to the contents of previous versions of the blueprint file
:::tip __Tips__
* If you are using VSCode to create and edit your blueprint file, we recommend using our official VSCode plugin (link here). For other IDEs, you can download our [official JSON schema](https://github.com/QualiTorque/torque-vs-code-extensions/blob/master/client/schemas/blueprint-spec2-schema.json) for the blueprint YAML and enforce it with your plugin of choice.
-* When connecting a repository containing blueprint files to Torque, it is possible to reference a branch of the repository and not its main, allowing designers the ability to test changes to blueprints before pushing them to the main/master branch and affecting the production catalog.
+* When connecting a repository containing blueprint files to , it is possible to reference a branch of the repository and not its main, allowing designers the ability to test changes to blueprints before pushing them to the main/master branch and affecting the production catalog.
:::
__To create a multi-asset blueprint:__
-1. Generate a single-asset blueprint for the first grain in your blueprint, as explained in [Let Torque auto-generate blueprints from your assets](#option-a-let-torque-generate-blueprints-from-your-assets).
-2. Download the blueprint as a file from Torque.
+1. Generate a single-asset blueprint for the first grain in your blueprint, as explained in [Let auto-generate blueprints from your assets](#option-a-let-torque-generate-blueprints-from-your-assets).
+2. Download the blueprint as a file from .
> 
3. Save the file in the "/blueprints" folder in your cloned repository (create it if it doesn't exist) and rename it to the name of the new blueprint.
4. Modify the grain type and spec to reflect the new component of your environment. For example:
@@ -77,10 +77,10 @@ grains:
8. Customize the ```inputs``` and ```outputs``` sections of the blueprint to contain only the relevant inputs that the entire environment needs, and to reflect the outputs from the grains that you would like to make available to the environment's end-user.
## Removing a blueprint
-As mentioned above, there are two types of blueprints, auto-generated blueprints (stored in Torque) and source-controlled blueprints (stored in your repository).
+As mentioned above, there are two types of blueprints, auto-generated blueprints (stored in ) and source-controlled blueprints (stored in your repository).
* To delete a stored-in-torque Blueprint, in the **Blueprints** tab, click on the Blueprint and then click the __Delete__ button on the top right corner.
-* To delete a "repository" Blueprint, simply delete the blueprint file from the repository's branch that the Torque space is connected to.
+* To delete a "repository" Blueprint, simply delete the blueprint file from the repository's branch that the space is connected to.
## Example multi-grain blueprint 1: Helm Application with MySQL and S3 Deployed by Terraform
This blueprint is available in the __Sample__ space [here](https://portal.qtorque.io/Sample/blueprints/[Sample]Helm%20Application%20with%20MySql%20and%20S3%20Deployed%20by%20Terraform), which deploys 2 Terraform modules and a Helm chart:
diff --git a/docs/blueprint-designer-guide/blueprints/ansible-grain.md b/docs/blueprint-designer-guide/blueprints/ansible-grain.md
index 3d9c3f049..20ca0c342 100644
--- a/docs/blueprint-designer-guide/blueprints/ansible-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/ansible-grain.md
@@ -3,7 +3,7 @@ sidebar_position: 5
title: The Ansible Grain
---
-The Ansible grain is Torque’s native support for orchestrating the execution of Ansible playbooks as part of a Torque blueprint. The referenced playbook can rely on vars or inventory-hosts that are dynamically provided by Torque, and then utilize them to perform configuration management, updates, a health check or any other flow that is executable from Ansible.
+The Ansible grain is ’s native support for orchestrating the execution of Ansible playbooks as part of a blueprint. The referenced playbook can rely on vars or inventory-hosts that are dynamically provided by , and then utilize them to perform configuration management, updates, a health check or any other flow that is executable from Ansible.
## Tools and technologies
@@ -45,7 +45,7 @@ variable3:
test3: '{{ name }}'
```
-Below is an example of an auto-generated blueprint based on a discovered playbook and its variables file. This demonstrates how Torque can help you quickly scaffold a working Ansible blueprint:
+Below is an example of an auto-generated blueprint based on a discovered playbook and its variables file. This demonstrates how can help you quickly scaffold a working Ansible blueprint:
```yaml
spec_version: 2
@@ -98,11 +98,11 @@ Always validate and adjust the generated blueprint YAML before running it, espec
## Installing Ansible Requirements
-Torque is designed to streamline the installation of your module’s dependencies. It accomplishes this by automatically detecting and installing the requirements specified in a ``requirements.yaml`` or ``requirements.yml`` file. This file should be located in the root directory of your module.
+ is designed to streamline the installation of your module’s dependencies. It accomplishes this by automatically detecting and installing the requirements specified in a ``requirements.yaml`` or ``requirements.yml`` file. This file should be located in the root directory of your module.
For instance, if your module’s main file is located at ``ansible/my-module/main.yaml``, the corresponding requirements file should be placed in the same directory, i.e., ``ansible/my-module/``.
-By adhering to this structure, you can ensure that Torque correctly identifies and installs all necessary requirements for your module.
+By adhering to this structure, you can ensure that correctly identifies and installs all necessary requirements for your module.
## Usage example
@@ -135,7 +135,7 @@ grains:
## Grain Spec Reference
### `source`
-The source section of an Ansible grain provides Torque with the information on where the Ansible playbook is stored and should be retrieved from. This could be either a direct source URL to an Ansible playbook YAML file, or it can be a reference from a Torque-connected git repository.
+The source section of an Ansible grain provides with the information on where the Ansible playbook is stored and should be retrieved from. This could be either a direct source URL to an Ansible playbook YAML file, or it can be a reference from a -connected git repository.
__Example - direct:__
@@ -198,7 +198,7 @@ grains:
```
:::info
-Torque supports playbooks which use ansible roles.
+ supports playbooks which use ansible roles.
:::
**Playbook:**
@@ -213,7 +213,7 @@ Torque supports playbooks which use ansible roles.
…
```
-Torque will create a JSON file containing the grain inputs under the path: /var/run/ansible/inputs/inputs.json.
+ will create a JSON file containing the grain inputs under the path: /var/run/ansible/inputs/inputs.json.
```json
{
@@ -281,7 +281,7 @@ ok: [host2] => {
}
```
-Any section of the “inventory-file:” can contain dynamic values from dependent grains, from the blueprint’s inputs or from Torque’s parameter storage. For more information, see [Torque Templating engine](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#torque-templating-engine).
+Any section of the “inventory-file:” can contain dynamic values from dependent grains, from the blueprint’s inputs or from ’s parameter storage. For more information, see [ Templating engine](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#torque-templating-engine).
__Example:__ Below is an example of a grains section of a blueprint, containing an Ansible grain:
```yaml
@@ -306,11 +306,11 @@ __Example:__ Below is an example of a grains section of a blueprint, containing
### `outputs`
-Ansible does not support outputs from playbooks natively so Torque adds this support on top of the ansible capabilities.
+Ansible does not support outputs from playbooks natively so adds this support on top of the ansible capabilities.
Why would you need outputs from your ansible grain?
Output from the ansible grain can be passed to another grain (ansible or not) or to become one of the blueprint outputs so can be provided to the blueprint consumer (the end user).
-For this purpose, we have developed the Torque ansible module "export-torque-outputs".
+For this purpose, we have developed the ansible module "export-torque-outputs".
The module accepts a dictionary of output names and values.
@@ -444,7 +444,7 @@ The `command-arguments` value can include any valid arguments that could be pass
### `scripts`
-Torque allows you to run scripts before executing the Ansible playbook. This can be useful for various purposes, such as setting up the environment or performing prerequisite tasks.
+ allows you to run scripts before executing the Ansible playbook. This can be useful for various purposes, such as setting up the environment or performing prerequisite tasks.
To run a script before the Ansible playbook execution, you can define it under the `scripts` section of the Ansible grain. The `pre-ansible-run` key is used to specify the script to be executed.
@@ -489,7 +489,7 @@ The pre-Ansible run scripts are executed within the same environment as the Ansi
- If a script fails (non-zero exit code), the Ansible playbook execution will be aborted.
- Make sure to include any required dependencies or libraries for the scripts within the script repository or the Ansible repository.
-By using pre-Ansible run scripts, you can enhance the flexibility and functionality of your Ansible playbooks within the Torque ecosystem.
+By using pre-Ansible run scripts, you can enhance the flexibility and functionality of your Ansible playbooks within the ecosystem.
### `on-destroy`
diff --git a/docs/blueprint-designer-guide/blueprints/argocd-grain.md b/docs/blueprint-designer-guide/blueprints/argocd-grain.md
index 377ca2ac3..cd2299f43 100644
--- a/docs/blueprint-designer-guide/blueprints/argocd-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/argocd-grain.md
@@ -3,20 +3,20 @@ sidebar_position: 6
title: The ArgoCD Grain
---
-ArgoCD is a popular GitOps continuous delivery tool for Kubernetes. Integrating ArgoCD as a grain in Torque enables a **single pane of glass** for life-cycle management of your Kubernetes applications. With the ArgoCD grain, you can automate deployment, monitor application health, and manage the full application lifecycle directly from your Torque blueprints, alongside other grains such as Helm, Terraform, and Ansible.
+ArgoCD is a popular GitOps continuous delivery tool for Kubernetes. Integrating ArgoCD as a grain in enables a **single pane of glass** for life-cycle management of your Kubernetes applications. With the ArgoCD grain, you can automate deployment, monitor application health, and manage the full application lifecycle directly from your blueprints, alongside other grains such as Helm, Terraform, and Ansible.
## Configuring a Deployment Engine
-Before using the ArgoCD grain, you must configure a Deployment Engine in Torque. This engine represents your ArgoCD server and is used to connect and manage applications.
+Before using the ArgoCD grain, you must configure a Deployment Engine in . This engine represents your ArgoCD server and is used to connect and manage applications.
The following fields are required:
-- **Engine Name**: A unique name for your ArgoCD engine in Torque.
+- **Engine Name**: A unique name for your ArgoCD engine in .
- **Engine Description**: (Optional) A description for easy identification.
- **Server URL**: The URL of your ArgoCD server (e.g., `https://argocd.example.com`).
- **Token**: The authentication token for accessing the ArgoCD API.
-- **Discovery Agent**: The Torque agent responsible for ongoing monitoring of tracked applications.
-- **Polling Interval (seconds)**: How often Torque polls ArgoCD for application status and health.
+- **Discovery Agent**: The agent responsible for ongoing monitoring of tracked applications.
+- **Polling Interval (seconds)**: How often polls ArgoCD for application status and health.
### Obtaining the ArgoCD Token
@@ -28,7 +28,7 @@ argocd account generate-token
```
- Replace ``, ``, and `` with your actual server and credentials.
-- The output token can be used in the Torque Deployment Engine configuration.
+- The output token can be used in the Deployment Engine configuration.
## Use Cases
@@ -52,7 +52,7 @@ argo-app (ArgoCD grain)
-> monitoring (Helm/ArgoCD grain)
```
-This approach allows you to build complex, multi-step environments where ArgoCD manages the core application, and Torque blueprints extend and enhance the deployment with additional resources and integrations.
+This approach allows you to build complex, multi-step environments where ArgoCD manages the core application, and blueprints extend and enhance the deployment with additional resources and integrations.
## Usage example
@@ -93,7 +93,7 @@ Please see [the grain agent](/blueprint-designer-guide/blueprints/blueprints-yam
### `deployment-engine`
-The name of the configured Deployment Engine in Torque. This field links the grain to a specific ArgoCD server configuration (see [Configuring a Deployment Engine](#configuring-a-deployment-engine)).
+The name of the configured Deployment Engine in . This field links the grain to a specific ArgoCD server configuration (see [Configuring a Deployment Engine](#configuring-a-deployment-engine)).
**Example:**
```yaml
deployment-engine: '{{ .inputs.agro-server }}'
diff --git a/docs/blueprint-designer-guide/blueprints/blueprint-grain.md b/docs/blueprint-designer-guide/blueprints/blueprint-grain.md
index b8654370a..1caea9341 100644
--- a/docs/blueprint-designer-guide/blueprints/blueprint-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/blueprint-grain.md
@@ -5,7 +5,7 @@ title: The Blueprint Grain
## Reusable building-blocks
-The Blueprint grain is Torque’s built-in support for allowing a Torque blueprint to be used as a grain in another Torque blueprint. This process is called "nesting" and such a blueprint will then be referred to as a "nested blueprint" within the context of the blueprint in which it is used as a grain. The blueprint containing the blueprint grain is called the “nesting blueprint”.
+The Blueprint grain is ’s built-in support for allowing a blueprint to be used as a grain in another blueprint. This process is called "nesting" and such a blueprint will then be referred to as a "nested blueprint" within the context of the blueprint in which it is used as a grain. The blueprint containing the blueprint grain is called the “nesting blueprint”.
Nesting a blueprint allows you to carry over (in a single grain) all of the nested blueprint’s grains, internal dependencies, and orchestration relationships, while only needing to provide the inputs for the nested blueprint, and specify the outputs expected to be received from it. These outputs can then be referred to by other grains in the blueprint.
@@ -93,7 +93,7 @@ grains:
Please see [the grain source](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#source) for more details.
### `agent`
-The blueprint grain does not require an agent as Torque uses the agent defined in the referenced blueprint. However, you can specify the agent as an input of ```type: agent``` on the blueprint level, and reference it from the grain, both as an input and in the host section.
+The blueprint grain does not require an agent as uses the agent defined in the referenced blueprint. However, you can specify the agent as an input of ```type: agent``` on the blueprint level, and reference it from the grain, both as an input and in the host section.
### `inputs`
Blueprint grain inputs are the names of the inputs of the nested blueprint, and the values being provided for each one when the blueprint is launched as a nested blueprint. These names must exactly match the input names in the ```inputs``` section of the nested blueprint’s blueprint YAML.
diff --git a/docs/blueprint-designer-guide/blueprints/blueprints-overview.md b/docs/blueprint-designer-guide/blueprints/blueprints-overview.md
index aaa495ae5..54c4f054c 100644
--- a/docs/blueprint-designer-guide/blueprints/blueprints-overview.md
+++ b/docs/blueprint-designer-guide/blueprints/blueprints-overview.md
@@ -3,19 +3,19 @@ sidebar_position: 1
title: Blueprint YAML Overview
---
-Torque blueprints are reusable components designed to model a required environment from the infrastructure to the application. **Blueprint designers** utilize Torque's VSCode plugin or the Torque's self-service UI to build a YAML based imperative blueprints that aimed to fulfill business requirements in a self-service manner for their end-users.
+ blueprints are reusable components designed to model a required environment from the infrastructure to the application. **Blueprint designers** utilize 's VSCode plugin or the 's self-service UI to build a YAML based imperative blueprints that aimed to fulfill business requirements in a self-service manner for their end-users.
:::tip __Note__
Blueprints are written in YAML files that reside in a __/blueprints__ folder within a Github, Gitlab or BitBucket repository (the folder name is case-sensitive and must be "blueprints"). The __/blueprints__ folder must be defined as the blueprint repository in the space's __Settings > Repositories__ page. Blueprints file type must be ".yaml" and not ".yml".
-For enhanced asset discovery and organization, see [Torque Assets Markers](/blueprint-designer-guide/torque-assets-markers).
+For enhanced asset discovery and organization, see [ Assets Markers](/blueprint-designer-guide/torque-assets-markers).
:::
-Common example will be a platform team or a DevOps team building Dev, Test and staging environments for their development, QA and product teams. With Torque, the DevOps team can focus on design, best practices, and security for environment, while their end users are being self-served from the torque UI, API or eco-system integrations based on governance and policies without having the 'keys-to-the-cloud'.
+Common example will be a platform team or a DevOps team building Dev, Test and staging environments for their development, QA and product teams. With , the DevOps team can focus on design, best practices, and security for environment, while their end users are being self-served from the torque UI, API or eco-system integrations based on governance and policies without having the 'keys-to-the-cloud'.
## Grain Categories
-Torque provides different types of grains per use case:
+ provides different types of grains per use case:
- **Core Blueprint Structure**: Blueprint YAML first
- **Configuration Management**: Ansible
@@ -27,7 +27,7 @@ Torque provides different types of grains per use case:
- **Custom Solutions**: Custom Grain, Shell
## In this section
-* [Torque's Blueprint YAML](/blueprint-designer-guide/blueprints/blueprints-yaml-structure)
+* ['s Blueprint YAML](/blueprint-designer-guide/blueprints/blueprints-yaml-structure)
* [The Ansible Grain](/blueprint-designer-guide/blueprints/ansible-grain)
* [The ArgoCD Grain](/blueprint-designer-guide/blueprints/argocd-grain)
* [The Blueprint Grain](/blueprint-designer-guide/blueprints/blueprint-grain)
diff --git a/docs/blueprint-designer-guide/blueprints/blueprints-yaml-structure.md b/docs/blueprint-designer-guide/blueprints/blueprints-yaml-structure.md
index c7a51ff02..d30399eea 100644
--- a/docs/blueprint-designer-guide/blueprints/blueprints-yaml-structure.md
+++ b/docs/blueprint-designer-guide/blueprints/blueprints-yaml-structure.md
@@ -3,19 +3,19 @@ sidebar_position: 4
title: Blueprint YAML Structure
---
-The Torque's blueprint YAML is the main blueprint definition file. It contains general information about the environment as well as the grains that make up the environment's applications and services. The blueprint YAML is published to end-users in Torque's blueprint catalog.
+The 's blueprint YAML is the main blueprint definition file. It contains general information about the environment as well as the grains that make up the environment's applications and services. The blueprint YAML is published to end-users in 's blueprint catalog.
## The Blueprint spec
### `spec_version`
-The spec_version determines the blueprint YAML type. Currently, Torque supports spec_version:2 as the default and recommended version. With time, new preview releases and official feature releases will bring more and more features and users will be able to use other spec versions.
+The spec_version determines the blueprint YAML type. Currently, supports spec_version:2 as the default and recommended version. With time, new preview releases and official feature releases will bring more and more features and users will be able to use other spec versions.
```yaml
spec_version: 2
```
### `description`
-The blueprint’s description is an optional but recommended field. Blueprint description will be presented in the Torque's UI and API so users consuming environment will have more information about the blueprints to batter match their business need to the available set of blueprints published in the account catalog.
+The blueprint’s description is an optional but recommended field. Blueprint description will be presented in the 's UI and API so users consuming environment will have more information about the blueprints to batter match their business need to the available set of blueprints published in the account catalog.
```yaml
@@ -34,18 +34,18 @@ description: Performance testing deployment based on RDS, EKS and Lambda
instructions:
text: "This is what you need to know ... " # text option
source:
- store:
+ store: >
path : # path inside the repository where the instructions md file is located. Must be in a folder called "instructions".
```
:::info
- Blueprint instructions can be located in the same repository as the blueprints or a different repository
-- Torque will use only markdown files located in the “/instructions” folder under the root of the onboarded repository
-- Torque will support external resources embed in the markdown under the following rules:
+- will use only markdown files located in the “/instructions” folder under the root of the onboarded repository
+- will support external resources embed in the markdown under the following rules:
- Any link to external and publicly exposed resource
- Relative path to images, svg and gif files located within the /instructions folder
- Images, svg and gif files smaller than 1MB.
-- Torque will not support relative .md references -Torque will not allow to load/redirect to another markdown mentioned in the markdown provided as the blueprint instructions.
+- will not support relative .md references - will not allow to load/redirect to another markdown mentioned in the markdown provided as the blueprint instructions.
:::
@@ -54,11 +54,11 @@ Blueprint designers can publish blueprint inputs to their end-users to add flexi
The input definition is composed out of the following fields:
- The input name
-- ```description``` is presented to all users in the Torque UI and API's (Optional)
+- ```description``` is presented to all users in the UI and API's (Optional)
- ```type``` of the input. Options are:
- ```string```
- ```agent``` allows the environment end-user to select the agent that will deploy the grain(s) from a dropdown list. By default, all agents are listed in the dropdown list, but you can add ```allowed-values``` to only display a subset of the agents. For details, see [agent](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#agent).
- - ```parameter``` will take the input's allowed values from the parameter-store, from a parameter with the name ```parameter-name```. The parameter can be defined either in the account level or in the space level. If the parameter's value is built as a comma separated list, Torque will convert them to a set of values and present it to the end-user as a drop down list of the values. See an example below. For more info about the parameter store, click [here](admin-guide/params.md).
+ - ```parameter``` will take the input's allowed values from the parameter-store, from a parameter with the name ```parameter-name```. The parameter can be defined either in the account level or in the space level. If the parameter's value is built as a comma separated list, will convert them to a set of values and present it to the end-user as a drop down list of the values. See an example below. For more info about the parameter store, click [here](admin-guide/params.md).
- ```credentials``` allows the environment end-user to select the credentials that will be used to deploy the grain(s) from a dropdown list. By default, all credentials in the account are listed in the dropdown list, but you can add ```allowed-values``` to only display a subset of the credentials.
- ```file``` allows the environment end-user to upload one or more files from the launch form. The uploaded files are made available to the blueprint designer using the [`workspace-directories`](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#workspace-directories) section and the **env-storage** store - [See details below](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#file-input-type).
- ```input-source``` allows the environment end-user to select from a list of values provided by a dynamic source. The source is defined in the [`input-sources`](/admin-guide/input-sources) section.
@@ -112,10 +112,10 @@ For advanced input visibility control and organization, see the [customization](
description: 'GPU types'
```
- ```sensitive```: ```true``` masks the value behind asterisks in the UI and API. (Default is ```false```)
-- ```default``` - (Optional) Value to be used in the Torque UI and will be used in case no other value provided for the input. If a default value is not defined, the environment end-user will need to provide one when launching the environment.
+- ```default``` - (Optional) Value to be used in the UI and will be used in case no other value provided for the input. If a default value is not defined, the environment end-user will need to provide one when launching the environment.
- ```allowed-values``` converts the input into a dropdown list, allowing the environment end-user to select the appropriate value. If a ```default``` is specified, it must be included in the allowed values list.
- ```quick``` is an optional boolean value. Setting it to "true" or omitting it will cause the input to be presented to the end user in the "quick links" section of the environment. Setting it to "false" means it will not appear in that section.
-- ```pattern``` is an optional regular expression pattern that the input value must match. If provided, Torque will validate the user input against this pattern during environment launch and prevent launching if the input does not conform to the specified pattern.
+- ```pattern``` is an optional regular expression pattern that the input value must match. If provided, will validate the user input against this pattern during environment launch and prevent launching if the input does not conform to the specified pattern.
- ```validation-description``` is an optional user-friendly message or description that will be shown to the user if the provided input value does not match the specified `pattern`. This helps provide better guidance to the user on the expected input format or constraints.
**Example:**
@@ -148,7 +148,7 @@ For advanced input visibility control and organization, see the [customization](
description: "How long should this environment run"
```
-The inputs section in the Torque blueprint YAML also supports spaces to make inputs more user friendly. Configuring an input with a friendly name can be done in the following way:
+The inputs section in the blueprint YAML also supports spaces to make inputs more user friendly. Configuring an input with a friendly name can be done in the following way:
```yaml
inputs:
@@ -253,10 +253,10 @@ outputs:
The ```quick: true``` attribute is optional and defaults to false. Setting it to `true` will cause the specific output to be presented in the __Quick Access__ section of the environment for ease of use.
:::info
-The example above includes some of the Torque's YAML templating engine capabilities allowing the blueprint designer more flexibility and leads to less code that will require maintenance. More examples for templating will be described [Torque Templating engine](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#torque-templating-engine).
+The example above includes some of the 's YAML templating engine capabilities allowing the blueprint designer more flexibility and leads to less code that will require maintenance. More examples for templating will be described [ Templating engine](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#torque-templating-engine).
:::
-The outputs section in the Torque blueprint YAML also supports spaces to make outputs more user friendly in the following way:
+The outputs section in the blueprint YAML also supports spaces to make outputs more user friendly in the following way:
```yaml
outputs:
@@ -320,7 +320,7 @@ The following grains are available:
### `source`
-Sources are repositories storing IaC, CM or other configuration technology that will be utilized by Torque to launch and operate an environment. Torque supports multiple ways to define grain sources.
+Sources are repositories storing IaC, CM or other configuration technology that will be utilized by to launch and operate an environment. supports multiple ways to define grain sources.
Sources can be defined in the following ways:
__1. Direct link to a source control folder__:
@@ -340,7 +340,7 @@ grains:
__2. Location based on a repository (blueprints or assets) onboarded to Torque__:
-The name of the repository should be provided under the 'store' field, while the IaC code folder location should be specified under the path field. In the below example, nginx helm chart resides in the 'nginx' folder within a repository onboarded to Torque with the name 'web_servers'.
+The name of the repository should be provided under the 'store' field, while the IaC code folder location should be specified under the path field. In the below example, nginx helm chart resides in the 'nginx' folder within a repository onboarded to with the name 'web_servers'.
```yaml
grains:
@@ -380,9 +380,9 @@ grains:
:::tip note
* You can specify only one of the parameters (```branch``` or ```commit``` or ```tag```).
-* If "tag" is provided, Torque will track the repo for newer tags. In other words, if a newer tag is found, then an "update" will be detected.
-* If "branch" is provided, Torque will track the head of the branch. In other words, when new commits arrive, an "update" will be detected.
-* If "commit" is provided, Torque __will not__ track changes.
+* If "tag" is provided, will track the repo for newer tags. In other words, if a newer tag is found, then an "update" will be detected.
+* If "branch" is provided, will track the head of the branch. In other words, when new commits arrive, an "update" will be detected.
+* If "commit" is provided, __will not__ track changes.
:::
### `agent`
@@ -422,10 +422,10 @@ The agent's configuration must include:
Optionally, the agent configuration may include:
-* **storage-size** - Set the size of storage allocated to this grain. The size is in MB. The size must be smaller than the overall storage size which was defined in the [agent settings](torque-agent/advanced-settings.md). If not defined, Torque will use the default size. This is an advanced configuration option, it is recommended to consult with Torque's support team before making a change.
-* **runner-namespace** - The namespace where the runner pod will be provisioned. If not defined, the runners will be provisioned in the default namespace defined in the agent level. This is an advanced configuration option, it is recommended to consult with Torque's support team before making a change.
+* **storage-size** - Set the size of storage allocated to this grain. The size is in MB. The size must be smaller than the overall storage size which was defined in the [agent settings](torque-agent/advanced-settings.md). If not defined, will use the default size. This is an advanced configuration option, it is recommended to consult with 's support team before making a change.
+* **runner-namespace** - The namespace where the runner pod will be provisioned. If not defined, the runners will be provisioned in the default namespace defined in the agent level. This is an advanced configuration option, it is recommended to consult with 's support team before making a change.
* **service-account** - The service-account name configured within the kubernetes cluster that will be used to execute the grain. A kubernetes
-service account provides an identity for processes that run in a pod. If not specified, Torque will use the default service account defined for the agent. The service account must be defined in the runner namespace.
+service account provides an identity for processes that run in a pod. If not specified, will use the default service account defined for the agent. The service account must be defined in the runner namespace.
* **isolated** - A boolean value (`true` or `false`) indicating whether the grain should run in isolation on a runner. If not defined, the default is determined internally based on the configuration (e.g., if agent's storage class supports `ReadWriteMany`, the default is `false`).
```yaml
@@ -463,7 +463,7 @@ grains:
```
### `depends-on`
-The need to deploy one IaC component before the other is common and usually required when 3rd party components, managed services and other teams need to provide the infrastructure. Using dependencies in the blueprint YAML Torque will evaluate and optimize the deployment process to make sure dependencies are respected and components with no dependencies will be deployed in parallel to maximize efficiency and reduce overall uptime.
+The need to deploy one IaC component before the other is common and usually required when 3rd party components, managed services and other teams need to provide the infrastructure. Using dependencies in the blueprint YAML will evaluate and optimize the deployment process to make sure dependencies are respected and components with no dependencies will be deployed in parallel to maximize efficiency and reduce overall uptime.
In the example below, 3 grain in the blueprint will be deployed in the following order: rds and redis will be deployed in parallel - and my_app will be deployed next, only in case of a successful deployment.
@@ -545,7 +545,7 @@ The **exclude-from-layout** element is optional, use it in case you need to appl
### `metadata`
-The metadata section allows you to define additional information about the blueprint that affects how it's presented and behaves in the Torque catalog. This section contains optional fields that enhance the blueprint's appearance and functionality.
+The metadata section allows you to define additional information about the blueprint that affects how it's presented and behaves in the catalog. This section contains optional fields that enhance the blueprint's appearance and functionality.
```yaml
spec_version: 2
@@ -570,7 +570,7 @@ metadata:
#### `display-name`
-Specifies a user-friendly display name for the blueprint that will be shown in the Torque UI catalog. This allows you to provide a more descriptive name than the filename or internal identifier.
+Specifies a user-friendly display name for the blueprint that will be shown in the UI catalog. This allows you to provide a more descriptive name than the filename or internal identifier.
```yaml
metadata:
@@ -579,7 +579,7 @@ metadata:
#### `icon`
-Defines the icon that will be displayed for the blueprint in the Torque catalog. This helps users quickly identify and distinguish between different blueprints.
+Defines the icon that will be displayed for the blueprint in the catalog. This helps users quickly identify and distinguish between different blueprints.
```yaml
metadata:
@@ -913,8 +913,8 @@ grains:
This dynamic output capability enables more sophisticated blueprint architectures where data can flow seamlessly between different layers and technologies while maintaining flexibility in how outputs are consumed and transformed.
-## Torque Templating Engine
-Templating engines are a great way to enrich the YAML format to allow extensibility points and text manipulations. Torque utilizes a GO-Lang style engine called [Shopify Liquid](https://shopify.github.io/liquid/) to allow dynamic injection of parameters and inputs as well as provider attribute values via reference of other attributes within the same YAML.
+## Templating Engine
+Templating engines are a great way to enrich the YAML format to allow extensibility points and text manipulations. utilizes a GO-Lang style engine called [Shopify Liquid](https://shopify.github.io/liquid/) to allow dynamic injection of parameters and inputs as well as provider attribute values via reference of other attributes within the same YAML.
Example:
* Insert Blueprint input from the user as a value for a Grain input.
* Insert Parameter Store information as a value for a Grain attribute or input.
@@ -939,7 +939,7 @@ In the below example the [downcase](https://shopify.github.io/liquid/filters/dow
For details and examples of how to use the parameters from the parameter store inside blueprints, check [this article](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#parameters).
### Dynamic Attributes
-Blueprint designers might need extra details about the account, space or environment during the environment's orchestration. Torque provides dynamic attributes which are pre-defined parameters blueprints designers can use. The currently supported dynamic attributes are:
+Blueprint designers might need extra details about the account, space or environment during the environment's orchestration. provides dynamic attributes which are pre-defined parameters blueprints designers can use. The currently supported dynamic attributes are:
- `envId`
- `blueprintName`
@@ -963,7 +963,7 @@ The dynamic attributes calculation is case insensitive so you can use either "en
### Parameters
-Torque's [Parameters](/admin-guide/params) store allows admins to set pre-defined account/space-level parameters. Blueprint designers can use the parameters in the blueprint YAML, instead of inputs if they don't want the environment end-user to provide the value, but also don't want to hard-code it in the blueprint.
+'s [Parameters](/admin-guide/params) store allows admins to set pre-defined account/space-level parameters. Blueprint designers can use the parameters in the blueprint YAML, instead of inputs if they don't want the environment end-user to provide the value, but also don't want to hard-code it in the blueprint.
The syntax is: ```{{ .params.param-value }}```
@@ -1002,7 +1002,7 @@ The env-vars field is relevant only to concrete IaC grains (e.g., terraform, hel
```
## Disabling Auto-Retry
-In some situations, Torque will automatically retry to deploy failed grains. This behavior is usually very beneficial but it might not be suitable in all cases.
+In some situations, will automatically retry to deploy failed grains. This behavior is usually very beneficial but it might not be suitable in all cases.
In case you wish to exclude a specific grain from the auto-retry, include the following in the blueprint:
:::note
@@ -1078,7 +1078,7 @@ In this case, the entire repository will be checked out, and the `name` specifie
#### Working with Artifactory as Binary Repository
-Artifactory is a popular binary repository manager that can store and manage various types of artifacts, including Docker images, Helm charts, and other binary files. In Torque, you can use Artifactory as a source for binary files that are required during the deployment process. This can be particularly useful for scenarios such as:
+Artifactory is a popular binary repository manager that can store and manage various types of artifacts, including Docker images, Helm charts, and other binary files. In , you can use Artifactory as a source for binary files that are required during the deployment process. This can be particularly useful for scenarios such as:
- Storing and managing Helm charts or other application configuration files
- Storing and managing Terraform state files or other infrastructure-related artifacts
@@ -1086,7 +1086,7 @@ Artifactory is a popular binary repository manager that can store and manage var
**Motivation and Scope**
-Using Artifactory as a binary repository in Torque provides several benefits:
+Using Artifactory as a binary repository in provides several benefits:
1. **Centralized Artifact Management**: Artifactory acts as a centralized repository for all your binary artifacts, making it easier to manage and distribute them across multiple environments.
@@ -1100,7 +1100,7 @@ Using Artifactory as a binary repository in Torque provides several benefits:
**Usage Example**
-To use Artifactory as a binary repository in Torque, you need to configure it as a workspace directory within your blueprint. Here's an example:
+To use Artifactory as a binary repository in , you need to configure it as a workspace directory within your blueprint. Here's an example:
```yaml title="Artifactory - Blueprint usage example"
vm-grain:
@@ -1132,15 +1132,15 @@ In this example, we have two workspace directories (`file1` and `file2`) that ar
**Setup**
-To use Artifactory with Torque, you need to configure an Artifactory credential in the Credentials Store.
+To use Artifactory with , you need to configure an Artifactory credential in the Credentials Store.
-In Torque portal, navigate to the `Account Settings` and to the Credentials page. Click on the `Add Credentials` button and choose `JFrog Artifactory`.
+In portal, navigate to the `Account Settings` and to the Credentials page. Click on the `Add Credentials` button and choose `JFrog Artifactory`.
Provide a `Name` and a `Description`, select the allowed `Spaces` that can use that Artifactory server, fill in the `Server URL` and the `Token` and hit the `Apply` button.
-You are also able to create an Artifactory credential using the Torque REST API as well. Here is an example on setting up Artifactory credentials on a space level:
+You are also able to create an Artifactory credential using the REST API as well. Here is an example on setting up Artifactory credentials on a space level:
```curl title="API call to setup Artifactory credentials on a space level"
POST {{host}}/api/spaces/{{space}}/settings/credentialstore
@@ -1157,7 +1157,7 @@ POST {{host}}/api/spaces/{{space}}/settings/credentialstore
}
```
-In this example, we're creating an Artifactory credential named `my-artifactory` with the server URL and a token for authentication. Currently, Torque supports Artifactory token authentication.
+In this example, we're creating an Artifactory credential named `my-artifactory` with the server URL and a token for authentication. Currently, supports Artifactory token authentication.
Once the Artifactory credential is configured, you can reference it in your blueprint's `workspace-directories` section using the `store` parameter, as shown in the usage example above.
@@ -1166,7 +1166,7 @@ Once the Artifactory credential is configured, you can reference it in your blue
The customization section allows you to control the user interface and presentation aspects of your blueprint, including the visual layout of grains and the behavior of the launch form. This section provides two main customization capabilities: grains-map visualization and launch-form input control.
:::note Preview Feature
-This feature is currently in preview. To get access to customization capabilities, please contact Torque support.
+This feature is currently in preview. To get access to customization capabilities, please contact support.
:::
```yaml
diff --git a/docs/blueprint-designer-guide/blueprints/cdk-grain.md b/docs/blueprint-designer-guide/blueprints/cdk-grain.md
index 53f6a6d23..6a6a73c5f 100644
--- a/docs/blueprint-designer-guide/blueprints/cdk-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/cdk-grain.md
@@ -3,7 +3,7 @@ sidebar_position: 7
title: The CDK Grain
---
-The AWS CDK grain enables you to orchestrate the deployment and management of AWS resources using the [AWS Cloud Development Kit (CDK)](https://aws.amazon.com/cdk/) as part of a Torque blueprint. This grain allows you to define, provision, and manage AWS infrastructure using familiar programming languages and the CDK toolchain.
+The AWS CDK grain enables you to orchestrate the deployment and management of AWS resources using the [AWS Cloud Development Kit (CDK)](https://aws.amazon.com/cdk/) as part of a blueprint. This grain allows you to define, provision, and manage AWS infrastructure using familiar programming languages and the CDK toolchain.
:::info
Currently, the CDK grain supports only the Python SDK.
@@ -118,7 +118,7 @@ Specifies the agent on which to run the CDK deployment. You can also specify a `
### `env-vars`
-A list of environment variables to set for the CDK process. Supports static values and Torque templating.
+A list of environment variables to set for the CDK process. Supports static values and templating.
### `workspace-directories`
@@ -146,10 +146,10 @@ Defines dependencies on other grains, ensuring this grain runs after the specifi
- The AWS CDK grain expects a valid CDK app (e.g., Python, TypeScript, etc.) in the specified path.
- Ensure that your agent has the necessary AWS credentials and permissions to deploy the resources defined in your CDK app.
- Use environment variables to pass configuration and secrets securely.
-- You can use Torque's templating engine to inject dynamic values from blueprint inputs or parameters.
+- You can use 's templating engine to inject dynamic values from blueprint inputs or parameters.
## See Also
- [AWS CDK Documentation](https://docs.aws.amazon.com/cdk/latest/guide/home.html)
-- [Torque Templating Engine](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#torque-templating-engine)
+- [ Templating Engine](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#torque-templating-engine)
- [Blueprint YAML Structure](/blueprint-designer-guide/blueprints/blueprints-yaml-structure)
diff --git a/docs/blueprint-designer-guide/blueprints/cloudformation-grain.md b/docs/blueprint-designer-guide/blueprints/cloudformation-grain.md
index 4496de35a..44edae371 100644
--- a/docs/blueprint-designer-guide/blueprints/cloudformation-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/cloudformation-grain.md
@@ -3,20 +3,20 @@ sidebar_position: 8
title: The CloudFormation Grain
---
-The CloudFormation grain represents Torque's native support for AWS CloudFormation templates. Torque enables designers to utilize CloudFormation features for orchestrating both self-developed and community-driven CloudFormation modules in a consistent manner, making them accessible as reusable building blocks.
+The CloudFormation grain represents 's native support for AWS CloudFormation templates. enables designers to utilize CloudFormation features for orchestrating both self-developed and community-driven CloudFormation modules in a consistent manner, making them accessible as reusable building blocks.
## Prerequisites
-Before utilizing CloudFormation with Torque, ensure that you have the following prerequisites in place:
+Before utilizing CloudFormation with , ensure that you have the following prerequisites in place:
1. **S3 bucket**: An S3 bucket designated for the temporary storage of large templates (required for templates exceeding 50K bytes)
2. **AWS policy**: Proper AWS permissions for CloudFormation operations
-For templates exceeding 50K bytes in size, Torque requires a "template-storage" location to upload templates from a Git repository, enabling the creation of CloudFormation stacks. Templates are fetched from Git and stored in this bucket, from where they can be launched.
+For templates exceeding 50K bytes in size, requires a "template-storage" location to upload templates from a Git repository, enabling the creation of CloudFormation stacks. Templates are fetched from Git and stored in this bucket, from where they can be launched.
### Required AWS Policy
-To grant Torque the necessary permissions to successfully provision resources, your credentials must include at least the following policy:
+To grant the necessary permissions to successfully provision resources, your credentials must include at least the following policy:
```json
{
@@ -122,12 +122,12 @@ The `agent` is now **required** for CloudFormation Grain. Please see [the grain
### `authentication`
-To enable Torque to connect to the AWS account and deploy the CloudFormation template, you have two options:
+To enable to connect to the AWS account and deploy the CloudFormation template, you have two options:
-1. **Torque credentials**: Authenticate with AWS access key and secret key OR AWS role ARN to be assumed by Torque
+1. ** credentials**: Authenticate with AWS access key and secret key OR AWS role ARN to be assumed by
2. **Service account**: Authenticate with a service account that will be attached to the runner which provisions the infrastructure
-__Example - Option 1 (Torque credentials):__
+__Example - Option 1 ( credentials):__
```yaml
grains:
@@ -159,7 +159,7 @@ grains:
```
:::info
-The service account needs to be annotated by an AWS role ARN to be assumed by Torque. If not provided, Torque will try to use the default service account of the agent.
+The service account needs to be annotated by an AWS role ARN to be assumed by . If not provided, will try to use the default service account of the agent.
:::
### `template-storage`
@@ -211,7 +211,7 @@ grains:
### `tags`
-Whenever a CloudFormation grain is launched, all resources created during the deployment process are automatically tagged with Torque's system tags, built-in tags and custom tags.
+Whenever a CloudFormation grain is launched, all resources created during the deployment process are automatically tagged with 's system tags, built-in tags and custom tags.
### `outputs`
@@ -237,7 +237,7 @@ grains:
### `stack-name-prefix`
-You can prefix all stacks created by Torque with a customized prefix to adhere to your organization standards or conventions.
+You can prefix all stacks created by with a customized prefix to adhere to your organization standards or conventions.
__Example:__
@@ -259,10 +259,10 @@ You can also define a system parameter at the account or space level with the na
## Drift Detection and Reconciliation
-Resolving drift in AWS CloudFormation involves acknowledging the updated configuration as the intended state and adjusting the stack template accordingly. In Torque, drift resolution or reconciliation entails undoing changes made to cloud resources and restoring them to the original template.
+Resolving drift in AWS CloudFormation involves acknowledging the updated configuration as the intended state and adjusting the stack template accordingly. In , drift resolution or reconciliation entails undoing changes made to cloud resources and restoring them to the original template.
:::warning
-Due to AWS limitations, if the drift includes deleted resources, Torque will not be able to restore these via reconciliation. It is advised to reconcile the stack manually via the AWS console or CLI.
+Due to AWS limitations, if the drift includes deleted resources, will not be able to restore these via reconciliation. It is advised to reconcile the stack manually via the AWS console or CLI.
:::
diff --git a/docs/blueprint-designer-guide/blueprints/cloudshell-grain.md b/docs/blueprint-designer-guide/blueprints/cloudshell-grain.md
index 40791de81..44a7cfd1c 100644
--- a/docs/blueprint-designer-guide/blueprints/cloudshell-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/cloudshell-grain.md
@@ -3,24 +3,24 @@ sidebar_position: 9
title: The CloudShell Grain
---
-The CloudShell grain allows you to integrate Torque with Quali CloudShell. CloudShell blueprints are treated as assets in Torque, extending Torque's capabilities to manage physical resources alongside cloud and container environments.
+The CloudShell grain allows you to integrate with Quali CloudShell. CloudShell blueprints are treated as assets in , extending 's capabilities to manage physical resources alongside cloud and container environments.
## Prerequisites
Before using the CloudShell grain, ensure you have:
- A healthy CloudShell instance with proper connectivity
-- Configured integration between Torque and CloudShell
+- Configured integration between and CloudShell
- An agent with direct connectivity to the self-hosted CloudShell instance
For detailed setup instructions, see [Self-Managed Quali CloudShell](/admin-guide/source-control/source-managed-cloudshell).
## Environment lifecycle management
-When launching an environment in Torque with the CloudShell grain, Torque will start a sandbox in CloudShell with the same duration. The lifecycle is fully synchronized:
+When launching an environment in with the CloudShell grain, will start a sandbox in CloudShell with the same duration. The lifecycle is fully synchronized:
-- **Extension**: If the Torque environment is extended, the CloudShell sandbox will be extended accordingly
-- **Termination**: When the Torque environment ends, the CloudShell sandbox will be terminated as well
+- **Extension**: If the environment is extended, the CloudShell sandbox will be extended accordingly
+- **Termination**: When the environment ends, the CloudShell sandbox will be terminated as well
## Usage example
@@ -85,7 +85,7 @@ Please see [the grain agent](/blueprint-designer-guide/blueprints/blueprints-yam
Similar to blueprint inputs, the CloudShell grain `inputs` allow you to reuse the same CloudShell Blueprint in different configurations. Inputs provided to the CloudShell grain are used when launching the CloudShell Blueprint.
:::tip
-We recommend using Torque's auto-discovery capability to quickly model your CloudShell Blueprint within Torque, including all defined inputs and their types.
+We recommend using 's auto-discovery capability to quickly model your CloudShell Blueprint within , including all defined inputs and their types.
:::
**Example:**
diff --git a/docs/blueprint-designer-guide/blueprints/custom-grain.md b/docs/blueprint-designer-guide/blueprints/custom-grain.md
index f686a60e8..e6765c02c 100644
--- a/docs/blueprint-designer-guide/blueprints/custom-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/custom-grain.md
@@ -3,7 +3,7 @@ sidebar_position: 100
title: Custom Grain
---
-Torque allows you to use your custom grain. To do so, you can specify the binary executable file which you would like to use.
+ allows you to use your custom grain. To do so, you can specify the binary executable file which you would like to use.
For example:
@@ -22,6 +22,6 @@ grains:
:::info
- The only platform supported for binaries is linux_amd64.
- The executable must be in zip archive format.
-- Torque will get the executable using and http get command which will be executed from the runner (i.e from the cluster where the agent is running). You have to make sure that the URL is accessible from the cluster without further authentication.
+- will get the executable using and http get command which will be executed from the runner (i.e from the cluster where the agent is running). You have to make sure that the URL is accessible from the cluster without further authentication.
- Please also note that no validation will be done on the binary link, it is the responsibility of the user.
:::
diff --git a/docs/blueprint-designer-guide/blueprints/helm-grain.md b/docs/blueprint-designer-guide/blueprints/helm-grain.md
index cbdc4c1c8..ff4a32f05 100644
--- a/docs/blueprint-designer-guide/blueprints/helm-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/helm-grain.md
@@ -3,7 +3,7 @@ sidebar_position: 10
title: The Helm Grain
---
-The Helm grain is Torque's native support for Helm v3 charts. Torque allows designers to use Helm specific features to easily orchestrate self-developer and community charts in a standard way and share them with others as building blocks.
+The Helm grain is 's native support for Helm v3 charts. allows designers to use Helm specific features to easily orchestrate self-developer and community charts in a standard way and share them with others as building blocks.
## Tools and technologies
@@ -68,11 +68,11 @@ grains:
### `target-namespace`
-Torque will install the helm release in the namespace referred to in `target-namespace`.
+ will install the helm release in the namespace referred to in `target-namespace`.
:::info
- The target namespace must exist in the cluster prior to the deployment
-- It must not be equal to the namespaces used by Torque for agent deployments
+- It must not be equal to the namespaces used by for agent deployments
- Make sure the service account has enough permissions to create/read/delete everything in the helm chart and also create/read/delete secrets and volumes
- To automatically create the namespace if it doesn't exist, see [Creating Namespace Automatically](#use-case-creating-namespace-automatically)
:::
@@ -94,7 +94,7 @@ helloHelm:
### `source`
-The `source` section of a Helm grain provides Torque with the information on where the Helm chart is stored and should be retrieved from. This could be either a direct source URL to a Helm chart, or it can be a reference from a Torque-connected git repository.
+The `source` section of a Helm grain provides with the information on where the Helm chart is stored and should be retrieved from. This could be either a direct source URL to a Helm chart, or it can be a reference from a -connected git repository.
Please see [the grain source](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#source) for more details.
@@ -129,7 +129,7 @@ agent:
### `inputs`
-Similar to blueprint inputs and Terraform inputs, the Helm grain `inputs` allow you to reuse the same Helm chart in different ways using different values overrides. Inputs provided to the Helm grain are used when launching the Helm chart. We recommend using Torque's auto-discovery capability to quickly model your Helm chart within Torque including all defined inputs.
+Similar to blueprint inputs and Terraform inputs, the Helm grain `inputs` allow you to reuse the same Helm chart in different ways using different values overrides. Inputs provided to the Helm grain are used when launching the Helm chart. We recommend using 's auto-discovery capability to quickly model your Helm chart within including all defined inputs.
__Example:__
@@ -169,7 +169,7 @@ In Helm, the `values.yaml` file is a critical component that allows you to confi
The `values.yaml` file contains the default configuration values for the templates used in the Helm chart. These values can be overridden at the time of deployment or during an upgrade by providing a different set of values.
-Torque supports referencing `values.yaml` files as inputs to the Helm grain, with the following syntax:
+ supports referencing `values.yaml` files as inputs to the Helm grain, with the following syntax:
```yaml
grains:
@@ -219,7 +219,7 @@ outputs:
### `scripts`
-Torque provides the ability to execute custom code after Torque executes the Helm chart. This is useful for generating and using outputs, as explained in [helm outputs](#outputs).
+ provides the ability to execute custom code after executes the Helm chart. This is useful for generating and using outputs, as explained in [helm outputs](#outputs).
__Example - grain with a post-install script and outputs:__
diff --git a/docs/blueprint-designer-guide/blueprints/kubernetes-grain.md b/docs/blueprint-designer-guide/blueprints/kubernetes-grain.md
index 92b8b1b28..d370e823b 100644
--- a/docs/blueprint-designer-guide/blueprints/kubernetes-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/kubernetes-grain.md
@@ -3,7 +3,7 @@ sidebar_position: 11
title: The Kubernetes Grain
---
-The Kubernetes grain allows you to deploy native Kubernetes manifests and manifest catalogs from your repositories as part of a Torque blueprint. The grain leverages Kubernetes' declarative approach to manage containerized applications and services within your Torque environments.
+The Kubernetes grain allows you to deploy native Kubernetes manifests and manifest catalogs from your repositories as part of a blueprint. The grain leverages Kubernetes' declarative approach to manage containerized applications and services within your environments.
## Tools and technologies
@@ -18,7 +18,7 @@ The following tools and technologies are installed out of the box on our agents
:::warning Important
* The target namespace must exist in the cluster prior to deployment
-* The namespace must not be equal to the namespaces used by Torque for agent deployments
+* The namespace must not be equal to the namespaces used by for agent deployments
* Ensure the service account has sufficient permissions to create/read/delete everything in the manifest, including secrets and volumes
* Currently, it is not possible to launch multiple concurrent environments from the same blueprint on the same namespace because the manifest resources are static and their names are not unique
:::
@@ -116,13 +116,13 @@ grains:
:::info
* Launching concurrent environments with a Kubernetes grain is not supported for the same namespace
-* Ensure the Torque agent has permissions to use the target namespace
-* The namespace must not be equal to namespaces used by Torque for agent deployments
+* Ensure the agent has permissions to use the target namespace
+* The namespace must not be equal to namespaces used by for agent deployments
:::
### `tags`
-Whenever a Kubernetes grain is launched, all resources created during the deployment process are automatically tagged with Torque's system tags, built-in tags, and custom tags. You can disable auto-tagging for specific grains if needed.
+Whenever a Kubernetes grain is launched, all resources created during the deployment process are automatically tagged with 's system tags, built-in tags, and custom tags. You can disable auto-tagging for specific grains if needed.
**Example - disable auto-tagging:**
@@ -141,7 +141,7 @@ grains:
### `scripts`
-Kubernetes does not natively support outputs from manifest deployments. Using Torque scripts, you can extract information from deployed resources and provide it as grain outputs. Scripts are executed after the grain's installation and must export environment variables that correspond to declared outputs.
+Kubernetes does not natively support outputs from manifest deployments. Using scripts, you can extract information from deployed resources and provide it as grain outputs. Scripts are executed after the grain's installation and must export environment variables that correspond to declared outputs.
**Usage example:**
diff --git a/docs/blueprint-designer-guide/blueprints/terraform-grain.md b/docs/blueprint-designer-guide/blueprints/terraform-grain.md
index 28dc923b2..fcd422d40 100644
--- a/docs/blueprint-designer-guide/blueprints/terraform-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/terraform-grain.md
@@ -3,7 +3,7 @@ sidebar_position: 14
title: The Terraform Grain
---
-The Terraform grain is Torque's native support for HashiCorp Terraform modules. Torque allows designers to use Terraform-specific features to easily orchestrate self-developer and community Terraform modules in a standard way and share them with others as building blocks.
+The Terraform grain is 's native support for HashiCorp Terraform modules. allows designers to use Terraform-specific features to easily orchestrate self-developer and community Terraform modules in a standard way and share them with others as building blocks.
Note that to deploy Terraform modules, you will need to authenticate Terraform on the Kubernetes cluster. For details, see [Terraform EKS Authentication](/torque-agent/service-accounts-for-aws), [Terraform AKS Authentication](/torque-agent/service-accounts-for-azure), or [Terraform GKE Authentication](/torque-agent/service-accounts-for-gcp).
@@ -177,7 +177,7 @@ When `use-storage: false` is specified, ensure you have a remote backend configu
### `authentication`
-To authenticate with AWS and deploy the terraform module, Torque will try to use the default service account configured for the selected agent. You can also supply different credentials in the grain's `authentication` section. This is done by referencing a [credential](/admin-guide/credentials) that contains these authentication details. There are two ways to specify the credential, literally by name or using an input:
+To authenticate with AWS and deploy the terraform module, will try to use the default service account configured for the selected agent. You can also supply different credentials in the grain's `authentication` section. This is done by referencing a [credential](/admin-guide/credentials) that contains these authentication details. There are two ways to specify the credential, literally by name or using an input:
```yaml
grains:
@@ -264,7 +264,7 @@ Liquid templating is supported in the `attributes` values, allowing blueprint in
### `backend`
-When launching the environment, Torque creates a tfstate file for each Terraform grain in the blueprint. By default, the state is saved locally on the PVC of the grain runner (volume for Docker agents). However, Torque allows you to optionally choose to save the terraform state in a backend of your choice. Torque supports the following backends:
+When launching the environment, creates a tfstate file for each Terraform grain in the blueprint. By default, the state is saved locally on the PVC of the grain runner (volume for Docker agents). However, allows you to optionally choose to save the terraform state in a backend of your choice. supports the following backends:
* [S3](https://developer.hashicorp.com/terraform/language/settings/backends/s3)
* [GCS](https://developer.hashicorp.com/terraform/language/settings/backends/gcs)
* [Azure RM](https://developer.hashicorp.com/terraform/language/settings/backends/azurerm)
@@ -273,10 +273,10 @@ When launching the environment, Torque creates a tfstate file for each Terraform
* [Cloud](https://developer.hashicorp.com/terraform/cli/cloud/settings#the-cloud-block)
__Prerequisites:__
-* The backend must already exist. Torque will not create the backend if it doesn't exist.
+* The backend must already exist. will not create the backend if it doesn't exist.
* RoleARN in the `service-account` or `authentication` block, must have access permissions to the backend specified.
-Based on the `backend` block in the blueprint definition, Torque will create an override file that contains the backend configurations.
+Based on the `backend` block in the blueprint definition, will create an override file that contains the backend configurations.
__Example__:
@@ -377,7 +377,7 @@ grains:
* __`workspaces`__: Mandatory - Workspace configuration (name or prefix)
* __`token`__: Optional - Authentication token (can be provided via environment variable)
-The `cloud` backend configuration allows you to use [Terraform Cloud](https://developer.hashicorp.com/terraform/cli/cloud/settings#the-cloud-block) for remote state management. This is particularly useful when migrating from Terraform Cloud to Torque or when you need to manage state using a third-party service.
+The `cloud` backend configuration allows you to use [Terraform Cloud](https://developer.hashicorp.com/terraform/cli/cloud/settings#the-cloud-block) for remote state management. This is particularly useful when migrating from Terraform Cloud to or when you need to manage state using a third-party service.
```yaml
backend:
@@ -392,10 +392,10 @@ The `cloud` backend configuration allows you to use [Terraform Cloud](https://de
**Cloud block behavior:**
* If your Terraform configuration doesn't include a cloud block, adding it to the blueprint will automatically configure it
* If both your Terraform configuration and blueprint specify cloud settings, the blueprint configuration will override the Terraform configuration
-* This enables seamless migration from Terraform Cloud to Torque while preserving existing state management
+* This enables seamless migration from Terraform Cloud to while preserving existing state management
**Use cases:**
-1. **Migrating from Terraform Cloud to Torque**: Maintain existing state management while transitioning to Torque orchestration
+1. **Migrating from Terraform Cloud to **: Maintain existing state management while transitioning to orchestration
2. **Managing state using a 3rd party**: Leverage external state management services for compliance or organizational requirements
`cloud` token options:
@@ -406,7 +406,7 @@ The `cloud` backend configuration allows you to use [Terraform Cloud](https://de
:::note
-Torque uses a "1 to many" model, meaning that one blueprint definition is used to launch many standalone environments. When using a backend for Terraform grains, it is important to ensure that each live instance of the grain has its own unique tfstate file, so Torque will auto-generate the tfstate file name.
+ uses a "1 to many" model, meaning that one blueprint definition is used to launch many standalone environments. When using a backend for Terraform grains, it is important to ensure that each live instance of the grain has its own unique tfstate file, so will auto-generate the tfstate file name.
For s3, gcs, azurerm backends, the tfstate file location will be:
@@ -427,11 +427,11 @@ For s3, gcs, azurerm backends, the tfstate file location will be:
__Cleaning up the tfstate file when the Terraform grain is destroyed:__
-When destroying a Terraform environment, Terraform does not delete the tfstate file but rather leaves behind an empty file. To clean up the leftovers, set a file retention policy on the remote storage to ensure the removal of files that have not been recently accessed. Since Torque runs drift detection on a 1-hour schedule, the tfstate file will be considered as “accessed” by the remote storage when running drift detection. And when the Torque environment ends, the tfstate file will not be “accessed” anymore by Torque.
+When destroying a Terraform environment, Terraform does not delete the tfstate file but rather leaves behind an empty file. To clean up the leftovers, set a file retention policy on the remote storage to ensure the removal of files that have not been recently accessed. Since runs drift detection on a 1-hour schedule, the tfstate file will be considered as “accessed” by the remote storage when running drift detection. And when the environment ends, the tfstate file will not be “accessed” anymore by .
:::
### `version`
-Torque provides the flexibility to choose a specific Terraform version with which the Terraform module will be deployed (minimum supported version is 0.14, last version supported is 1.5.5). Otherwise, you can use the [custom-grain option](/blueprint-designer-guide/blueprints/custom-grain).
+ provides the flexibility to choose a specific Terraform version with which the Terraform module will be deployed (minimum supported version is 0.14, last version supported is 1.5.5). Otherwise, you can use the [custom-grain option](/blueprint-designer-guide/blueprints/custom-grain).
```yaml
grains:
@@ -446,7 +446,7 @@ grains:
```
### `inputs`
-Similar to blueprint inputs, the Terraform grain input allows you to reuse the same Terraform module in different ways. Inputs provided to the Terraform grain are used when launching the Terraform module. Terraform grain inputs should be listed in the order defined in the module's variables.tf file. We recommend using Torque's auto-discovery capability to quickly model your Terraform modules within Torque including all defined inputs.
+Similar to blueprint inputs, the Terraform grain input allows you to reuse the same Terraform module in different ways. Inputs provided to the Terraform grain are used when launching the Terraform module. Terraform grain inputs should be listed in the order defined in the module's variables.tf file. We recommend using 's auto-discovery capability to quickly model your Terraform modules within including all defined inputs.
Every value that goes to the Terraform grain's input is interpreted as a json token. So you can pass any valid value by json: number, list, dictionary, boolean, string , etc.
For details, check out this Terraform Docs section [Variable Definitions (.tfvars) Files](https://www.terraform.io/language/values/variables#variable-definitions-tfvars-files)
@@ -484,7 +484,7 @@ Note that invalid tokens will be parsed as strings. Keep in mind that json strin
### `tfvars files`
-In Terraform, a tfvars file (short for "Terraform variables file") is a plain text file that contains a set of key-value pairs representing values for Terraform variables. Torque supports referencing tfvars files as inputs to the terraform grain, with the following syntax:
+In Terraform, a tfvars file (short for "Terraform variables file") is a plain text file that contains a set of key-value pairs representing values for Terraform variables. supports referencing tfvars files as inputs to the terraform grain, with the following syntax:
```yaml
grains:
@@ -512,7 +512,7 @@ grains:
### `tags`
-Whenever a Terraform grain is launched, all resources created during the deployment process will be automatically tagged with Torque's system tags, built-in tags and custom tags. For details, see [Tags](/governance/tags).
+Whenever a Terraform grain is launched, all resources created during the deployment process will be automatically tagged with 's system tags, built-in tags and custom tags. For details, see [Tags](/governance/tags).
Sometimes, you need to disable tagging for all or specific resources.
To disable *all* resources in a specific grain use the following syntax:
@@ -539,7 +539,7 @@ grains:
### `outputs`
-Output are values generated by Terraform during the deployment process. Outputs should be defined in the outputs.tf file located in the Terraform module folder. We recommend using Torque's auto-discovery capability to quickly model your Terraform modules within Torque including it's defined outputs.
+Output are values generated by Terraform during the deployment process. Outputs should be defined in the outputs.tf file located in the Terraform module folder. We recommend using 's auto-discovery capability to quickly model your Terraform modules within including it's defined outputs.
```yaml
@@ -557,7 +557,7 @@ grains:
```
### `scripts`
-Torque provides the ability to execute custom code before the executing the Terraform module init and before the Terraform destroy process. Scripts allows to run CLI commands to make sure authentication and requirements are set prior to the Terraform execution at the environment's initialization and destroy process.
+ provides the ability to execute custom code before the executing the Terraform module init and before the Terraform destroy process. Scripts allows to run CLI commands to make sure authentication and requirements are set prior to the Terraform execution at the environment's initialization and destroy process.
The available script hooks are:
- pre-tf-init: The script will run before the command ```terraform init```
@@ -598,7 +598,7 @@ grains:
Note that scripts should be stored next to your IaC code to be used under the scripts section.
:::
-When writing the scripts, you can take advantage of the following out of the box environment variables provided by Torque:
+When writing the scripts, you can take advantage of the following out of the box environment variables provided by :
- **TORQUE_TF_EXECUTABLE** - the terraform executable file name
- **TORQUE_TF_MODULE_PATH** - the path to the terraform executable.
@@ -631,7 +631,7 @@ fi
```
### `auto-approve`
-The "auto-approve" flag in Terraform is used to automatically approve and apply changes without requiring manual confirmation. It is helpful in automation workflows or scripts where user interaction is not feasible, allowing for unattended execution of Terraform commands without the need for explicit approval during the apply phase. By default, Torque will apply the terraform module with auto-approval.
+The "auto-approve" flag in Terraform is used to automatically approve and apply changes without requiring manual confirmation. It is helpful in automation workflows or scripts where user interaction is not feasible, allowing for unattended execution of Terraform commands without the need for explicit approval during the apply phase. By default, will apply the terraform module with auto-approval.
However, you might specifically want to ensure that critical or potentially destructive changes are reviewed and approved by a user before being applied. This adds an extra layer of safety, especially in scenarios where unintended consequences could result from applying infrastructure changes. It provides an opportunity to carefully inspect the proposed changes before confirming their execution.
To do that, you can set the auto-approve flag in the terraform grain spec to false (default will be true):
@@ -725,7 +725,7 @@ The `mode` field controls how Terraform resources are managed during environment
- **`managed`** (default): Standard behavior where resources are destroyed using `terraform destroy` when the environment is terminated or grain is deleted/edited
- **`no-termination`**: Resources are "released" rather than destroyed. The Terraform state is removed but the actual cloud resources remain intact
-This is particularly useful for production environments where you want to preserve critical infrastructure (databases, storage, networks) even when the Torque environment is terminated.
+This is particularly useful for production environments where you want to preserve critical infrastructure (databases, storage, networks) even when the environment is terminated.
```yaml
spec_version: 2
@@ -762,5 +762,5 @@ grains:
- Any resources that are expensive to recreate or contain state that must be preserved
:::warning
-When using `no-termination` mode, you are responsible for manually cleaning up the cloud resources when they are no longer needed, as Torque will not destroy them automatically.
+When using `no-termination` mode, you are responsible for manually cleaning up the cloud resources when they are no longer needed, as will not destroy them automatically.
:::
\ No newline at end of file
diff --git a/docs/blueprint-designer-guide/blueprints/terragrunt-grain.md b/docs/blueprint-designer-guide/blueprints/terragrunt-grain.md
index 9de8f6122..b33e0a5fe 100644
--- a/docs/blueprint-designer-guide/blueprints/terragrunt-grain.md
+++ b/docs/blueprint-designer-guide/blueprints/terragrunt-grain.md
@@ -5,7 +5,7 @@ title: The Terragrunt Grain
# The Terragrunt Grain
-The Terragrunt grain is Torque's native support for [Terragrunt](https://terragrunt.gruntwork.io/) modules. Terragrunt is a thin wrapper for Terraform that provides extra tools for working with multiple Terraform modules and keeping your configurations DRY. Torque allows designers to use Terragrunt-specific features to easily orchestrate self-developed and community Terragrunt modules in a standard way and share them as building blocks.
+The Terragrunt grain is 's native support for [Terragrunt](https://terragrunt.gruntwork.io/) modules. Terragrunt is a thin wrapper for Terraform that provides extra tools for working with multiple Terraform modules and keeping your configurations DRY. allows designers to use Terragrunt-specific features to easily orchestrate self-developed and community Terragrunt modules in a standard way and share them as building blocks.
## Tools and technologies
The following tools and technologies are installed out of the box on our agents in the Kubernetes pods and can be used when writing Terragrunt grain scripts (pre/post, etc.):
@@ -80,7 +80,7 @@ env-vars:
```
### `scripts`
-Torque provides the ability to execute custom scripts before or after Terragrunt commands. The available script hooks are:
+ provides the ability to execute custom scripts before or after Terragrunt commands. The available script hooks are:
- pre-tf-init: Runs before `terragrunt init`
- post-tf-plan: Runs after `terragrunt plan`
- pre-tf-destroy: Runs before `terragrunt destroy`
@@ -100,7 +100,7 @@ Scripts should be stored next to your IaC code to be used under the scripts sect
:::
### `auto-approve`
-The `auto-approve` flag is used to automatically approve and apply changes without requiring manual confirmation. By default, Torque will apply the Terragrunt module with auto-approval. To require manual approval, set `auto-approve: false`.
+The `auto-approve` flag is used to automatically approve and apply changes without requiring manual confirmation. By default, will apply the Terragrunt module with auto-approval. To require manual approval, set `auto-approve: false`.
```yaml
auto-approve: false
@@ -108,7 +108,7 @@ auto-approve: false
## Usage Example
-Below is a complete example of a Torque blueprint using a Terragrunt grain:
+Below is a complete example of a blueprint using a Terragrunt grain:
```yaml
spec_version: 2
diff --git a/docs/blueprint-designer-guide/torque-assets-markers.md b/docs/blueprint-designer-guide/torque-assets-markers.md
index 4356bc5f6..82862e4cb 100644
--- a/docs/blueprint-designer-guide/torque-assets-markers.md
+++ b/docs/blueprint-designer-guide/torque-assets-markers.md
@@ -1,36 +1,36 @@
---
sidebar_position: 18
-title: Torque Assets Markers
+title: Assets Markers
---
-# Torque Markers for Asset Discovery
+# Markers for Asset Discovery
## Overview
-Torque Markers is a feature designed to enhance the discovery and management of Torque-related assets, including Blueprints, Environments, Instructions, Workflows, and Layouts. This capability improves asset scanning efficiency and provides better organization for repositories with multiple Torque assets.
+ Markers is a feature designed to enhance the discovery and management of -related assets, including Blueprints, Environments, Instructions, Workflows, and Layouts. This capability improves asset scanning efficiency and provides better organization for repositories with multiple assets.
## How It Works
-Torque Markers use special marker files to indicate directories containing Torque assets. These marker files help Torque focus its scanning efforts on relevant directories, optimizing the asset discovery process.
+ Markers use special marker files to indicate directories containing assets. These marker files help focus its scanning efforts on relevant directories, optimizing the asset discovery process.
### Marker File Implementation
-- Marker files have specific extensions to indicate different Torque asset types:
+- Marker files have specific extensions to indicate different asset types:
- `.environments`
- `.blueprints`
- `.workflows`
- `.layouts`
- `.instructions`
- Marker files should have no filename, only the extension (e.g., `.blueprints`)
-- Place marker files in the Git directories that Torque will scan for changes and assets
+- Place marker files in the Git directories that will scan for changes and assets
:::note
-For `.instructions` Torque will recursively scan for `image` and `.md` files.
+For `.instructions` will recursively scan for `image` and `.md` files.
:::
:::info
1. `Multiple Marker` files can not coexist in the same directory
-2. Torque will still scan the default directory naming convention at root. (e.g., `blueprints/`, `environmnets/`, etc.)
+2. will still scan the default directory naming convention at root. (e.g., `blueprints/`, `environmnets/`, etc.)
:::
@@ -73,7 +73,7 @@ app/
## Optimized Scanning Process
-- Torque scans only directories containing Torque marker files for associated assets
+- scans only directories containing marker files for associated assets
- This approach reduces scanning time and resource usage
- Eliminates the need to parse all files in the repository, improving performance
@@ -81,35 +81,35 @@ app/
- Improved repository organization and asset management
- Reduced scanning time and resource usage
-- Clear indication of Torque-related asset locations
-- Flexibility in structuring repositories with multiple Torque assets
+- Clear indication of -related asset locations
+- Flexibility in structuring repositories with multiple assets
- Enhanced support for GitOps workflows
## Implementation Considerations
-- The Torque scanning algorithm has been updated to recognize and utilize marker files
-- Documentation and guidelines are available for users on how to implement and use Torque markers
-- Backward compatibility with existing Torque implementations is ensured
+- The scanning algorithm has been updated to recognize and utilize marker files
+- Documentation and guidelines are available for users on how to implement and use markers
+- Backward compatibility with existing implementations is ensured
## Getting Started
-To start using Torque Markers in your repository:
+To start using Markers in your repository:
-1. Identify the directories containing Torque assets (Blueprints, Environments, etc.)
+1. Identify the directories containing assets (Blueprints, Environments, etc.)
2. Add the appropriate marker file to each directory (e.g., `.blueprints`, `.environments`)
3. Ensure your asset files are properly named and located within the marked directories
4. Commit and push your changes to the repository
-5. Torque will automatically detect and use the new marker system on the next scan
+5. will automatically detect and use the new marker system on the next scan
## Best Practices
- Use marker files consistently across your repositories
- Organize your assets logically within your repository structure
-- Avoid placing unrelated files in directories with Torque markers
+- Avoid placing unrelated files in directories with markers
- Regularly review and update your marker placement as your repository evolves
## Conclusion
-Torque Markers provide an efficient and flexible way to manage Torque assets within your Git repositories. By adopting this feature, you can improve your asset organization, reduce scanning times, and enhance your overall GitOps workflow.
+ Markers provide an efficient and flexible way to manage assets within your Git repositories. By adopting this feature, you can improve your asset organization, reduce scanning times, and enhance your overall GitOps workflow.
-For more information or assistance, please refer to the Torque documentation or contact our support team.
\ No newline at end of file
+For more information or assistance, please refer to the documentation or contact our support team.
\ No newline at end of file
diff --git a/docs/eco-system/ci-cd-tooling/azure-devops.md b/docs/eco-system/ci-cd-tooling/azure-devops.md
index f2b8a9cbb..c702f9e81 100644
--- a/docs/eco-system/ci-cd-tooling/azure-devops.md
+++ b/docs/eco-system/ci-cd-tooling/azure-devops.md
@@ -3,34 +3,34 @@ sidebar_position: 6
title: Azure DevOps Plugin
---
-The Azure DevOps plugin lets developers trigger application environments on-demand directly from their Azure DevOps pipelines. Azure DevOps users can easily integrate the Torque environments-as-a-service platform into their projects by utilizing the Torque orb’s pre-defined commands.
-To integrate Torque with the Azure DevOps plugin, make sure to complete the next few steps.
+The Azure DevOps plugin lets developers trigger application environments on-demand directly from their Azure DevOps pipelines. Azure DevOps users can easily integrate the environments-as-a-service platform into their projects by utilizing the orb’s pre-defined commands.
+To integrate with the Azure DevOps plugin, make sure to complete the next few steps.
## 1. Install
__Prerequisites:__
* Admin permissions on the plugin’s intended Azure DevOps organization. If you are not the organization’s admin, you may send a request to the admin to install the plugin for you.
-* Azure DevOps organization that will use the Torque plugin
+* Azure DevOps organization that will use the plugin
__To Install the plugin:__
1. Log in to [VisualStudio.com](http://visualstudio.com) and select the organization that will use this plugin.
2. Click __Organization settings__.
3. From the left pane, select __Extensions__ and then click __Browse Marketplace__.
-4. Search for “torque”, click the Torque plugin and then __Install__.
+4. Search for “torque”, click the plugin and then __Install__.
## 2. Configure
-__To set your Torque account information:__
+__To set your account information:__
1. Click __Project Settings > Service connections__.
2. Click __New service connection__, select __Torque__, and click __Next__.
3. Specify the server url (https://portal.qtorque.io).
4. Specify the __Torque Long Token__ with the one generated below:
5. Click __Generate New Token__ in the plugin's instructions pane.
6. Click __Verify__ and make sure the connection succeeds.
-7. In the __Service Connection Name__ field, enter 'Torque connection'.
+7. In the __Service Connection Name__ field, enter ' connection'.
8. Click __Verify__ and save.
## 3. Verify and launch
-Use Torque's environments in your Azure DevOps Build
+Use 's environments in your Azure DevOps Build
Use the available build steps to create an environment from any blueprint, retrieve its details, start your tests and end the environment when it's no longer needed.
Learn more [here](https://marketplace.visualstudio.com/items?itemName=Quali.build-release-task-torque).
\ No newline at end of file
diff --git a/docs/eco-system/ci-cd-tooling/circle-ci.md b/docs/eco-system/ci-cd-tooling/circle-ci.md
index ab43f663f..6fabfdd56 100644
--- a/docs/eco-system/ci-cd-tooling/circle-ci.md
+++ b/docs/eco-system/ci-cd-tooling/circle-ci.md
@@ -3,9 +3,9 @@ sidebar_position: 21
title: CircleCI Plugin
---
-The [Quali Torque plugin](https://circleci.com/developer/orbs/orb/quali/torque) lets developers trigger application environments on-demand directly from their CircleCI pipelines. CircleCI users can easily integrate the Torque environments-as-a-service platform into their projects by utilizing by utilizing the Torque orb’s pre-defined commands.
+The [Quali plugin](https://circleci.com/developer/orbs/orb/quali/torque) lets developers trigger application environments on-demand directly from their CircleCI pipelines. CircleCI users can easily integrate the environments-as-a-service platform into their projects by utilizing by utilizing the orb’s pre-defined commands.
-To integrate Torque with the CircleCI plugin, make sure to complete the next few steps.
+To integrate with the CircleCI plugin, make sure to complete the next few steps.
## 1. Install
@@ -13,8 +13,8 @@ To integrate Torque with the CircleCI plugin, make sure to complete the next few
2. Open the __Environment Variables__ page.
3. Add the following three variables:
- * __TORQUE_SERVER__: The URL of your Torque server (https://portal.qtorque.io).
- * __TORQUE_SPACE__: The name of your space in Torque.
+ * __TORQUE_SERVER__: The URL of your server (https://portal.qtorque.io).
+ * __TORQUE_SPACE__: The name of your space in .
* __TORQUE_TOKEN__: Use the token you generate below
4. Click the __Generate New Token__ button in the plugin's instructions pane.
@@ -31,7 +31,7 @@ __Using the torque orb in your config file__
It is recommended to use the [latest release version](https://circleci.com/developer/orbs/orb/quali/torque).
## 3. Verify and launch
-__Use Torque's tasks in your CircleCI workflow__
+__Use 's tasks in your CircleCI workflow__
-Add the __torque/start-sandbox__ and __torque/end-sandbox__ commands to start and stop the environment in Torque. Review examples [here](https://circleci.com/developer/orbs/orb/quali/torque#usage-examples).
+Add the __torque/start-sandbox__ and __torque/end-sandbox__ commands to start and stop the environment in . Review examples [here](https://circleci.com/developer/orbs/orb/quali/torque#usage-examples).
See the parameters list for orb behavior command customization [here](https://circleci.com/developer/orbs/orb/quali/torque#jobs).
diff --git a/docs/eco-system/ci-cd-tooling/github-actions.md b/docs/eco-system/ci-cd-tooling/github-actions.md
index 7b977e5f1..b31f509ce 100644
--- a/docs/eco-system/ci-cd-tooling/github-actions.md
+++ b/docs/eco-system/ci-cd-tooling/github-actions.md
@@ -7,7 +7,7 @@ Use GitHub Actions to automate environment lifecycle management. We currently pr
* [torque-start-sb-action](https://github.com/QualiTorque/torque-start-sb-action#readme): Starts an environment
* [torque-end-sb-action](https://github.com/QualiTorque/torque-end-sb-action#readme): Ends an environment
-To integrate Torque with the GitHub Actions, make sure to complete the next few steps.
+To integrate with the GitHub Actions, make sure to complete the next few steps.
## 1. Install
@@ -23,7 +23,7 @@ __Install the plugin:__
2. Click the __Generate New Token__ button in the plugin's instructions pane.
## 3. Verify and launch
-__Use Torque's tasks in your Jenkins pipeline__
+__Use 's tasks in your Jenkins pipeline__
Read more and view the usage examples for each one of the actions:
* [torque-start-sb-action](https://github.com/QualiTorque/torque-start-sb-action#readme)
diff --git a/docs/eco-system/ci-cd-tooling/jenkins.md b/docs/eco-system/ci-cd-tooling/jenkins.md
index 61a22f73f..d1c4a4d19 100644
--- a/docs/eco-system/ci-cd-tooling/jenkins.md
+++ b/docs/eco-system/ci-cd-tooling/jenkins.md
@@ -3,9 +3,9 @@ sidebar_position: 9
title: Jenkins Plugin
---
-The [Jenkins plugin](https://github.com/jenkinsci/quali-torque-plugin/) lets developers trigger application environments on-demand directly from their Jenkins pipelines. Jenkins users can easily integrate the Torque environments-as-a-service platform into their projects by utilizing the Torque orb’s pre-defined commands.
+The [Jenkins plugin](https://github.com/jenkinsci/quali-torque-plugin/) lets developers trigger application environments on-demand directly from their Jenkins pipelines. Jenkins users can easily integrate the environments-as-a-service platform into their projects by utilizing the orb’s pre-defined commands.
-To integrate Torque with the Jenkins plugin, make sure to complete the next few steps.
+To integrate with the Jenkins plugin, make sure to complete the next few steps.
## 1. Install
@@ -15,7 +15,7 @@ __Install the latest version from within Jenkins:__
3. Select and install the plugin.
__Or, manually download and install it:__
-1. Download the latest __Jenkins Torque Plugin__ from [here](https://plugins.jenkins.io/quali-torque/#releases).
+1. Download the latest __Jenkins Plugin__ from [here](https://plugins.jenkins.io/quali-torque/#releases).
2. In Jenkins Web UI, click __Manage Jenkins > Manage Plugins__.
3. Select the __Advanced__ tab.
4. Scroll down to the __Deploy Plugin__ section.
@@ -34,9 +34,9 @@ __Or, manually download and install it:__
5. Click __Save__.
## 3. Verify and launch
-__Use Torque's tasks in your Jenkins pipeline__
+__Use 's tasks in your Jenkins pipeline__
After installing and configuring the Jenkins plugin, you can start using the plugin to launch environments from your Jenkins Pipeline. Note that this plugin only supports environments.
-To use the plugin, you will need to instantiate a Blueprint object with using the torque global object. This object can then be used to start an environment. The environment object can later be used to end the Torque Environment.
+To use the plugin, you will need to instantiate a Blueprint object with using the torque global object. This object can then be used to start an environment. The environment object can later be used to end the Environment.
To learn more about the parameters of each step, read [here](https://github.com/jenkinsci/quali-torque-plugin/#readme).
diff --git a/docs/eco-system/ci-cd-tooling/spinnaker.md b/docs/eco-system/ci-cd-tooling/spinnaker.md
index 6062cb225..5e57b5c81 100644
--- a/docs/eco-system/ci-cd-tooling/spinnaker.md
+++ b/docs/eco-system/ci-cd-tooling/spinnaker.md
@@ -3,14 +3,14 @@ sidebar_position: 15
title: Spinnaker Plugin
---
-The [Spinnaker plugin](https://github.com/QualiTorque/torque-spinnaker-plugin) lets developers trigger application environments on-demand directly from their Spinnaker pipelines. Spinnaker users can easily integrate the Torque environments-as-a-service platform into their projects by utilizing the Torque plugin’s pre-defined commands.
+The [Spinnaker plugin](https://github.com/QualiTorque/torque-spinnaker-plugin) lets developers trigger application environments on-demand directly from their Spinnaker pipelines. Spinnaker users can easily integrate the environments-as-a-service platform into their projects by utilizing the plugin’s pre-defined commands.
-To integrate Torque with the Spinnaker plugin, make sure to complete the next few steps.
+To integrate with the Spinnaker plugin, make sure to complete the next few steps.
## 1. Install
__Prerequisites:__
-* This plugin integrates Torque into your Pipelines in Spinnaker 1.23.0 and above.
+* This plugin integrates into your Pipelines in Spinnaker 1.23.0 and above.
__Install the plugin:__
* Read how to add the Halyard file that will be used to load the orca file, and how to add the profile file to load the Deck frontend [here](https://github.com/QualiTorque/torque-spinnaker-plugin#plugin-deployment-guide-for-spinnaker).
@@ -19,7 +19,7 @@ __Install the plugin:__
1. When adding the Halyard file, you’ll need to provide the following parameters:
* __torqueUrl__ - Use https://portal.qtorque.io
- * __account__ - The Torque account name (optional)
+ * __account__ - The account name (optional)
* __torqueToken__ - Use the token with the value generated below:
2. Click the __Generate New Token__ button in the plugin's instructions pane.
diff --git a/docs/eco-system/ci-cd-tooling/teamcity.md b/docs/eco-system/ci-cd-tooling/teamcity.md
index 1a85fb4b2..c37a46abe 100644
--- a/docs/eco-system/ci-cd-tooling/teamcity.md
+++ b/docs/eco-system/ci-cd-tooling/teamcity.md
@@ -3,29 +3,29 @@ sidebar_position: 18
title: TeamCity Plugin
---
-The [Quali Torque plugin](https://plugins.jetbrains.com/plugin/18582-torque) lets developers trigger application environments on-demand directly from their TeamCity pipelines. TeamCity users can easily integrate the Torque environments-as-a-service platform into their projects by utilizing the Torque plugin’s pre-defined commands.
+The [Quali plugin](https://plugins.jetbrains.com/plugin/18582-torque) lets developers trigger application environments on-demand directly from their TeamCity pipelines. TeamCity users can easily integrate the environments-as-a-service platform into their projects by utilizing the plugin’s pre-defined commands.
-To integrate Torque with the Spinnaker plugin, make sure to complete the next few steps.
+To integrate with the Spinnaker plugin, make sure to complete the next few steps.
## 1. Install
-1. Open the Torque Plugin page in the Jetbrains marketplace.
-2. Download the latest version of the Torque plugin.
+1. Open the Plugin page in the Jetbrains marketplace.
+2. Download the latest version of the plugin.
3. Open the TeamCity web UI as an administrator and perform the following steps:
* Browse to the __Administration > Plugins__ page.
* Click the __Upload plugin__ zip and upload the __*teamcity-torque-plugin.zip*__. A warning message is displayed recommending that you restart the TeamCity Server.
* Click __Restart__ and wait for TeamCity to initiate.
4. To verify that the installation is successfully completed:
* Browse to the __Administration > Plugins List__ page.
- * Under the __External plugins__ section, verify that the Torque Plugin appears with no warnings.
+ * Under the __External plugins__ section, verify that the Plugin appears with no warnings.
* Open the __Projects Overview__ page and open any project.
* Click __Edit Project Settings__.
- * Under the left __General Settings__ list, a Torque option appears (the tab will appear only if TeamCity was restarted as described in step 3).
+ * Under the left __General Settings__ list, a option appears (the tab will appear only if TeamCity was restarted as described in step 3).
## 2. Configure
1. Open TeamCity as Administrator.
-2. Open the Project Administration page and click the Torque tab.
+2. Open the Project Administration page and click the tab.
3. Click Connect.
4. Under the General Configuration section, enter the following parameters:
* __Torque Server URL__: https://portal.qtorque.com
diff --git a/docs/eco-system/dev-tools/torque-cli.md b/docs/eco-system/dev-tools/torque-cli.md
index bdb49f4f9..3dbd8a094 100644
--- a/docs/eco-system/dev-tools/torque-cli.md
+++ b/docs/eco-system/dev-tools/torque-cli.md
@@ -1,9 +1,10 @@
---
sidebar_position: 23
-title: Torque CLI
---
-This tool streamlines the YAML development process by validating changes in real-time and allowing the execution of test environments directly from the development branch, without needing to first merge the changes to production.
+# CLI
+
+The CLI tool streamlines the YAML development process by validating changes in real-time and allowing the execution of test environments directly from the development branch, without needing to first merge the changes to production.
### Installation
@@ -25,10 +26,10 @@ There are two ways to use torque-cli:
### Configuration
-To allow the torque-cli to authenticate with Torque, you must provide several parameters:
-* *Space*: The Torque space to use
-* *Repository*: (Optional) Represents the name of the git repository containing the blueprints and IaC files that will be used when calling Torque
-* *Token*: The easiest way to generate a token is via the Torque UI.
+To allow the torque-cli to authenticate with , you must provide several parameters:
+* *Space*: The space to use
+* *Repository*: (Optional) Represents the name of the git repository containing the blueprints and IaC files that will be used when calling
+* *Token*: The easiest way to generate a token is via the UI.
1. In your space, go to **Settings > Integrations**.
2. Click **Connect** under any of the CI tools.
3. Click **New Token** to get an API token.
@@ -45,7 +46,7 @@ Example output:
```bash
$ torque config list
- Torque user profiles
+ user profiles
Active │ Profile Name │ Space │ Repository │ Token
────────┼──────────────┼──────────┼────────────┼────────────
@@ -72,7 +73,7 @@ export TORQUE_REPO_NAME = my_repo
### Additional environment variables
-It is possible to switch the client to a different Torque instance setting custom API endpoint:
+It is possible to switch the client to a different instance setting custom API endpoint:
```bash
export TORQUE_URL = "https://demo.qtorque.io"
@@ -80,9 +81,9 @@ export TORQUE_URL = "https://demo.qtorque.io"
## Basic Usage
-Torque CLI r
+ CLI r
-There are some basic actions Torque CLI currently allows you to perform:
+There are some basic actions CLI currently allows you to perform:
- Validate a blueprint (using the ```torque bp validate``` command)
- Get a list of blueprints (via ```torque bp list```)
@@ -112,7 +113,7 @@ OPTIONS:
COMMANDS:
blueprint Get, List, Validate blueprints
-environment Start, End, View Torque environments
+environment Start, End, View environments
config List, Add and Modify user profiles
agent List, associate agents
space Create, delete spaces, connect repo to space
@@ -123,7 +124,7 @@ You can get additional help information for a particular command by including t
```bash
$ torque env -h
DESCRIPTION:
-Start, End, View Torque environments.
+Start, End, View environments.
USAGE:
torque environment [OPTIONS]
@@ -141,7 +142,7 @@ OPTIONS:
COMMANDS:
start Start Environment
get Get Environment Details
- end End Torque Environment
- list List Torque Environment
- extend Extend Torque Environment
+ end End Environment
+ list List Environment
+ extend Extend Environment
```
\ No newline at end of file
diff --git a/docs/eco-system/dev-tools/vs-plugin.md b/docs/eco-system/dev-tools/vs-plugin.md
index 7881cbe7d..7962f1732 100644
--- a/docs/eco-system/dev-tools/vs-plugin.md
+++ b/docs/eco-system/dev-tools/vs-plugin.md
@@ -1,9 +1,10 @@
---
sidebar_position: 26
-title: Torque VSCode plugin
---
-This extension facilitates the blueprint yaml development process by providing developers with auto-complete, instant error checks and schema validations. For details, see [VS Code Extension for Torque](https://github.com/QualiTorque/torque-vs-code-extensions).
+# VS Code Extension
+
+This extension facilitates the blueprint yaml development process by providing developers with auto-complete, instant error checks and schema validations. For details, see [VS Code Extension for ](https://github.com/QualiTorque/torque-vs-code-extensions).
For example: Auto-completion suggestions for inputs, parameters and variables:
diff --git a/docs/eco-system/integrations-overview.md b/docs/eco-system/integrations-overview.md
index 398af98ec..a70c7c99c 100644
--- a/docs/eco-system/integrations-overview.md
+++ b/docs/eco-system/integrations-overview.md
@@ -3,8 +3,8 @@ sidebar_position: 1
title: Integrations Overview
---
-Torque supports three types of integrations:
-* Development tools that assist you to develop Torque blueprints.
+ supports three types of integrations:
+* Development tools that assist you to develop blueprints.
* Issue trackers and notification (collaboration) apps for communicating environment lifecycle events to your teams
* CI/CD tools for consuming environments as part of your DevOps pipeline
diff --git a/docs/eco-system/issue-trackers.md b/docs/eco-system/issue-trackers.md
index 5cb413f57..0b272baac 100644
--- a/docs/eco-system/issue-trackers.md
+++ b/docs/eco-system/issue-trackers.md
@@ -3,11 +3,11 @@ sidebar_position: 36
title: Issue Trackers
---
-With __Issue Trackers__ integrations, you can configure Torque to send environment lifecycle events to your bug tracking solution.
+With __Issue Trackers__ integrations, you can configure to send environment lifecycle events to your bug tracking solution.
## Jira
-This integration enables sending the environment events to specific issues in Jira. As part of the integration with Jira, you specify the Jira projects that can receive the events, and Torque will only send the events to a matching issue within those projects.
+This integration enables sending the environment events to specific issues in Jira. As part of the integration with Jira, you specify the Jira projects that can receive the events, and will only send the events to a matching issue within those projects.
The events are displayed in the __Comments__ section of the issues and look something like this:
diff --git a/docs/eco-system/itsm-tools/service-now.md b/docs/eco-system/itsm-tools/service-now.md
index d14dfdd34..d06df3a06 100644
--- a/docs/eco-system/itsm-tools/service-now.md
+++ b/docs/eco-system/itsm-tools/service-now.md
@@ -5,61 +5,61 @@ title: Service Now
## __Flow overview__
-Torque has a built-in integration with Service Now for approval flow. If your organization is using Service Now for ITSM, you can configure the integration and perform your approval flow through your Service Now portal.
+ has a built-in integration with Service Now for approval flow. If your organization is using Service Now for ITSM, you can configure the integration and perform your approval flow through your Service Now portal.
> 
## __Prerequisites__
-In order to configure the ServiceNow integration, you will need to have the Torque Integration XML file. Please contact Torque Support to get this file.
+In order to configure the ServiceNow integration, you will need to have the Integration XML file. Please contact Support to get this file.
-## 1. Install the ServiceNow Torque Application
+## 1. Install the ServiceNow Application
1. In Service Now, Go to -> `Retrieved Update Sets`
- 2. In the bottom, there is a link: `Import Update Set from XML` click it, and choose the file you received from Torque support.
+ 2. In the bottom, there is a link: `Import Update Set from XML` click it, and choose the file you received from support.
3. Select the record and press on `Preview Update Set` and then `commit`
-## 2. Create a service user for Torque
+## 2. Create a service user for
- 1. In Service Now, Create a dedicated user for Torque integration. This user does not need any special permissions in ServiceNow, just to be able to login to the system.
+ 1. In Service Now, Create a dedicated user for integration. This user does not need any special permissions in ServiceNow, just to be able to login to the system.
2. Take note of the username and password of this user, you will need this information in the next steps.
## 3. Approval Channel Configuration
-1. In Torque:
+1. In :
- 1. You will need a user in Toruqe that will be the approver for the approval channel. Note, currently only one approver can be assigned to each approval channel. The user can be one of your existing users, or a new one which can serve as a service user. This user does not have to be a real user in Torque, it is just a user for the purpose of this integration. This user needs to be a member of the space(s) where you want these approvals to be created.
+ 1. You will need a user in Toruqe that will be the approver for the approval channel. Note, currently only one approver can be assigned to each approval channel. The user can be one of your existing users, or a new one which can serve as a service user. This user does not have to be a real user in , it is just a user for the purpose of this integration. This user needs to be a member of the space(s) where you want these approvals to be created.
To create a new user you should invite the new user via email.
- 2. Log in to the Torque UI as the approver user from step 1, and create an API token. See [Generating a new Torque API Token](/rest-api/torque_api_tokens.md) . Take note of the generated Token.
+ 2. Log in to the UI as the approver user from step 1, and create an API token. See [Generating a new API Token](/rest-api/torque_api_tokens.md) . Take note of the generated Token.
2. In ServiceNow:
- 1. **Update Torque API token** : Go to `sys_properties.list` and update `Torque_Token` with the value of the generated API token.
- 2. **Update Torque Base URL** Go to `Connection & Credential Aliases` and click on `Torque`
+ 1. **Update API token** : Go to `sys_properties.list` and update `Torque_Token` with the value of the generated API token.
+ 2. **Update Base URL** Go to `Connection & Credential Aliases` and click on ``
3. Add a new connection by clicking the `New` button:
> 
4. In case you have a connection just edit the record with the correct URL:
> 
-3. In Torque:
+3. In :
1. Navigate to `Administration` -> `Approval Channels`
2. On the top right corner, click on `Add Channel`.
3. Fill a name and description of your choice and click on the ServiceNow icon.
4. Fill the following details:
1. ServiceNow address URL - your base service now tenant URL. For example: https://mytenant.service-now.com/
- 2. Username - The Torque dedicated ServiceNow user which you created in [Step 2](#2-create-a-service-user-for-torque)
- 3. Password - The Torque dedicated ServiceNow password of the same user
- 4. Approvers - the Torque approver user which you selected/created in step 3.1. It must be the same user to which the Torque token belongs.
+ 2. Username - The dedicated ServiceNow user which you created in [Step 2](#2-create-a-service-user-for-torque)
+ 3. Password - The dedicated ServiceNow password of the same user
+ 4. Approvers - the approver user which you selected/created in step 3.1. It must be the same user to which the token belongs.
4. In ServiceNow: Review Approval Flow template
- 1. Go to `Flow Designer -> Flows` and select type in the searchbox for “Torque Request”.
+ 1. Go to `Flow Designer -> Flows` and select type in the searchbox for “ Request”.
2. Select it and configure approvers under `Ask for Approval` action:
> 
-The approvers don't have to be Torque users.
+The approvers don't have to be users.
5. In ServiceNow: View approval flow
diff --git a/docs/eco-system/terraform-provider.md b/docs/eco-system/terraform-provider.md
index e3cc0f14d..ff25714c4 100644
--- a/docs/eco-system/terraform-provider.md
+++ b/docs/eco-system/terraform-provider.md
@@ -3,11 +3,11 @@ sidebar_position: 88
title: Terraform Provider
---
-The Terraform Provider for Quali's Torque is a plugin for Terraform that allows you to interact with Torque and control Torque behavior and presentation. The terraform provider is developed as a open source project that relies on Torque public APIs.
+The Terraform Provider for Quali's is a plugin for Terraform that allows you to interact with and control behavior and presentation. The terraform provider is developed as a open source project that relies on public APIs.
-* Torque open-source provider code: https://github.com/QualiTorque/terraform-provider-torque
-* The Torque provider in the Terraform registry: https://registry.terraform.io/providers/QualiTorque/torque/latest
-* Torque provider documentation: https://registry.terraform.io/providers/QualiTorque/torque/latest/docs
+* open-source provider code: https://github.com/QualiTorque/terraform-provider-torque
+* The provider in the Terraform registry: https://registry.terraform.io/providers/QualiTorque/torque/latest
+* provider documentation: https://registry.terraform.io/providers/QualiTorque/torque/latest/docs
To install this provider, copy and paste this code into your Terraform configuration. Then, run terraform init.
@@ -27,9 +27,9 @@ provider "torque" {
```
-### Example use for the Torque Terraform provider
-Many of our customers are automating Infrastructure that is not necessarily created as part of the environment orchestration. In such situations, the Torque Terraform provider can help with representation on the required resources in the resource catalog for users ease-of-use.
-Here is a code snippet from a terraform module that will generate a "torque_introspection_resource" resource - that will be recognized and presented by Torque so end-users of the environment will be able to see it in the Torque UI or use it in automation using the Torque API.
+### Example use for the Terraform provider
+Many of our customers are automating Infrastructure that is not necessarily created as part of the environment orchestration. In such situations, the Terraform provider can help with representation on the required resources in the resource catalog for users ease-of-use.
+Here is a code snippet from a terraform module that will generate a "torque_introspection_resource" resource - that will be recognized and presented by so end-users of the environment will be able to see it in the UI or use it in automation using the API.
```jsx
@@ -41,7 +41,7 @@ resource "torque_introspection_resource" "example" {
```
The complete terraform example can be found here: https://github.com/QualiTorque/terraform-provider-torque/blob/main/examples/provider-install-verification/main.tf
-Once deployed, Torque will represent the "torque_introspection_resource" resource in the resource catalog.
+Once deployed, will represent the "torque_introspection_resource" resource in the resource catalog.
> 
diff --git a/docs/environment-as-code/environment-as-code-overview.md b/docs/environment-as-code/environment-as-code-overview.md
index ce309411c..0c14f78e1 100644
--- a/docs/environment-as-code/environment-as-code-overview.md
+++ b/docs/environment-as-code/environment-as-code-overview.md
@@ -3,9 +3,9 @@ sidebar_position: 1
title: Overview
---
-## Torque **Environment as Code**
-Torque **Environment as code** provides a declarative way to define complex cloud environments, based on IaC assets (Terraform, Helm, CloudFormation, etc.) and governed by centralized policies. While 'as-code' practices were well adopted for infrastructure, configurations and policies, it is extremely difficult to combine them into a single source that fits the business requirements, can be generated using an automation process, audited and manually approved if required.
-Using **Environment as code** you can ensure a standard workflow is being applied so changes to the environment (development, staging, production etc) are being tracked, tested and applied frequently per organizational policies and practices. With Torque blueprints as building blocks, one can launch and manage a Torque environment with maximum flexibility, access, and control while taking advantage of the predefined guardrails in place to prevent unwanted activity from occurring.
+## **Environment as Code**
+ **Environment as code** provides a declarative way to define complex cloud environments, based on IaC assets (Terraform, Helm, CloudFormation, etc.) and governed by centralized policies. While 'as-code' practices were well adopted for infrastructure, configurations and policies, it is extremely difficult to combine them into a single source that fits the business requirements, can be generated using an automation process, audited and manually approved if required.
+Using **Environment as code** you can ensure a standard workflow is being applied so changes to the environment (development, staging, production etc) are being tracked, tested and applied frequently per organizational policies and practices. With blueprints as building blocks, one can launch and manage a environment with maximum flexibility, access, and control while taking advantage of the predefined guardrails in place to prevent unwanted activity from occurring.
@@ -23,7 +23,7 @@ The GitOps approach extends the use of Git to an application's configuration, in
Implementing GitOps implies that changes to applications and infrastructure are automatically synchronized with the live environment promoting source control management platforms as the single source of truth.
-Torque **Environment as code** provides an additional layer of control based on multi-tech, multi-cloud automation assets built for Git based operations (GitOps). With Torque you can launch, update, change and terminate complex application environments based on your existing Git flow.
+ **Environment as code** provides an additional layer of control based on multi-tech, multi-cloud automation assets built for Git based operations (GitOps). With you can launch, update, change and terminate complex application environments based on your existing Git flow.
-## Implementing Environment as Code with Torque
-Implementing Environment as Code using Torque involves discovering your infrastructure-as-code assets as blueprints and combining them using the Torque environment YAML together with metadata that will be kept and evaluated upon launch, updates and termination of the environment. Every Torque environment, regardless if operated in a GitOps manner or not, is managed using an environment YAML behind the scenes. Browsing to the environment YAML in the Torque self-service portal on any running environment can give a glimpse of how the YAML looks like for the specific environment launch.
\ No newline at end of file
+## Implementing Environment as Code with
+Implementing Environment as Code using involves discovering your infrastructure-as-code assets as blueprints and combining them using the environment YAML together with metadata that will be kept and evaluated upon launch, updates and termination of the environment. Every environment, regardless if operated in a GitOps manner or not, is managed using an environment YAML behind the scenes. Browsing to the environment YAML in the self-service portal on any running environment can give a glimpse of how the YAML looks like for the specific environment launch.
\ No newline at end of file
diff --git a/docs/environment-as-code/environment-as-code-yaml.md b/docs/environment-as-code/environment-as-code-yaml.md
index c46cb0775..a789ebb40 100644
--- a/docs/environment-as-code/environment-as-code-yaml.md
+++ b/docs/environment-as-code/environment-as-code-yaml.md
@@ -3,14 +3,14 @@ sidebar_position: 1
title: The Environment YAML
---
-Environment as Code (EaC) allows you to define and manage Torque environments using YAML files. If you know how to write Torque blueprints, you can write EaC YAML files. The structure of an EaC YAML file is similar to a blueprint, with the addition of an 'environment' section that defines the properties of the specific environment instance.
+Environment as Code (EaC) allows you to define and manage environments using YAML files. If you know how to write blueprints, you can write EaC YAML files. The structure of an EaC YAML file is similar to a blueprint, with the addition of an 'environment' section that defines the properties of the specific environment instance.
## Environment Discovery
-Environment YAML files must be placed under the 'environments' directory in the repository. Torque periodically scans this directory for environment YAML files and stores them internally.
+Environment YAML files must be placed under the 'environments' directory in the repository. periodically scans this directory for environment YAML files and stores them internally.
:::note
-Environments are written in YAML files that reside in an __/environments__ folder within a source control repository onboarded to Torque (the folder name is case-sensitive and must be "environments"). Environments kept in the __/environments__ folder must be of type ".yaml" and not ".yml" to be used in Torque.
+Environments are written in YAML files that reside in an __/environments__ folder within a source control repository onboarded to (the folder name is case-sensitive and must be "environments"). Environments kept in the __/environments__ folder must be of type ".yaml" and not ".yml" to be used in .
:::
The directory structure should be as follows:
@@ -22,7 +22,7 @@ environments/
devbox.yaml
```
-When a new environment YAML file is detected or an existing one is modified, Torque performs validations on the file. If the file is valid, a snapshot is saved, which will be used to create or reconcile the environment. If the file is invalid, it will not affect the existing snapshot or the environment.
+When a new environment YAML file is detected or an existing one is modified, performs validations on the file. If the file is valid, a snapshot is saved, which will be used to create or reconcile the environment. If the file is invalid, it will not affect the existing snapshot or the environment.
If a user modifies the environment YAML file, the changes will be applied to the corresponding environment.
@@ -38,7 +38,7 @@ All sources must contain a commit hash or tag.
## Usage Example
-Here's an example of a Torque environment YAML file:
+Here's an example of a environment YAML file:
```yaml
spec_version: 2
@@ -124,7 +124,7 @@ In this example, the `environment` section defines the environment name, descrip
The `grains` section contains the list of grains that make up the environment, similar to a blueprint. Each grain specifies its kind (e.g., `terraform`, `blueprint`, etc.), version, and other configuration details specific to that grain type.
-By following this structure, users can define and manage their environments as code, allowing for version control, collaboration, and automated deployments using Torque's Environment as Code (EaC) functionality.
+By following this structure, users can define and manage their environments as code, allowing for version control, collaboration, and automated deployments using 's Environment as Code (EaC) functionality.
## Environment section
@@ -173,7 +173,7 @@ environment:
### `owner_email`
-The email address of the environment owner. This field is required and must be a valid email address of a user in the Torque system.
+The email address of the environment owner. This field is required and must be a valid email address of a user in the system.
```yaml
environment:
@@ -216,7 +216,7 @@ environment:
### `spaces`
-Specifies which Torque spaces this environment belongs to. Environments can be associated with multiple spaces for organization and access control purposes.
+Specifies which spaces this environment belongs to. Environments can be associated with multiple spaces for organization and access control purposes.
```yaml
environment:
@@ -287,7 +287,7 @@ environment:
## EaC Management APIs
-Torque provides REST APIs for managing Environment as Code (EaC) files and their associated environments. These APIs allow you to control the lifecycle and behavior of EaC-managed environments.
+ provides REST APIs for managing Environment as Code (EaC) files and their associated environments. These APIs allow you to control the lifecycle and behavior of EaC-managed environments.
### Enable/Disable EaC Record
@@ -394,5 +394,5 @@ curl -X DELETE "https://portal.qtorque.io/api/spaces/my-space/environments/env-1
- Use terminate for clean decommissioning of EaC-managed environments
:::warning
-Once an environment is detached from its EaC file, it cannot be re-attached. The environment becomes a standard Torque environment and must be managed manually or through regular APIs.
+Once an environment is detached from its EaC file, it cannot be re-attached. The environment becomes a standard environment and must be managed manually or through regular APIs.
:::
diff --git a/docs/environment-services/Cost.md b/docs/environment-services/Cost.md
index f0f4605a4..d36fb9c19 100644
--- a/docs/environment-services/Cost.md
+++ b/docs/environment-services/Cost.md
@@ -3,18 +3,18 @@ sidebar_position: 3
title: Cost tracking
---
-Torque lets you get proactive about cloud cost optimization. With automatic tags apply to all deployed resources your teams can aggregates cost data based on team, project, or other custom parameters so you can understand ROI and address cost anomalies before you receive the cloud bill.
+ lets you get proactive about cloud cost optimization. With automatic tags apply to all deployed resources your teams can aggregates cost data based on team, project, or other custom parameters so you can understand ROI and address cost anomalies before you receive the cloud bill.
-While tagging is a common practice for adding metadata for deployed infrastructure, it's usually hard to maintain a consistence tagging methodology and ownership. Torque allows centralized control for tags, so administrator can configure the organization tagging methodology in Torque, allowing teams, projects and individuals the flexibility to use tags within that methodology.
+While tagging is a common practice for adding metadata for deployed infrastructure, it's usually hard to maintain a consistence tagging methodology and ownership. allows centralized control for tags, so administrator can configure the organization tagging methodology in , allowing teams, projects and individuals the flexibility to use tags within that methodology.
> 
-Tags added by Torque are business context that will be attached to any of the deployed resources in an environment regardless of the automation framework so cloud resources will be consistent and cost information will be aligned between teams, projects, environments and even between cloud account and cloud providers. Torque will also help you to address the differences between the cloud providers - for example, CP does not allow case-sensitive tagging and Torque will help you with standardizing that by providing best practices from the get go.
+Tags added by are business context that will be attached to any of the deployed resources in an environment regardless of the automation framework so cloud resources will be consistent and cost information will be aligned between teams, projects, environments and even between cloud account and cloud providers. will also help you to address the differences between the cloud providers - for example, CP does not allow case-sensitive tagging and will help you with standardizing that by providing best practices from the get go.
-> 
+> 
-Tags are key-value pairing that are set by Torque to all of the resources and infrastructure entities provisioned by an environment (example: `Owner=John.D@somecompany.com`) There are 2 types of tags: System tags and custom tags. System tags are tags that are defined by Torque (for example, environment id, space name, etc) while the users define the custom tags according to their needs.
+Tags are key-value pairing that are set by to all of the resources and infrastructure entities provisioned by an environment (example: `Owner=John.D@somecompany.com`) There are 2 types of tags: System tags and custom tags. System tags are tags that are defined by (for example, environment id, space name, etc) while the users define the custom tags according to their needs.
-For every launch of the blueprint, Torque will track the the overall cost information based on the tagging and the cloud provider cost. This is using the __actual cost__ you are paying the cloud provider and not an estimation. After several launches, the hourly cost will be presented both in the catalog on the blueprint and when an environment is running, the estimation will be presented in the environment page. Cost information can be used for policies and approval flows as well as it's captured and passed to Torque OPA integration.
+For every launch of the blueprint, will track the the overall cost information based on the tagging and the cloud provider cost. This is using the __actual cost__ you are paying the cloud provider and not an estimation. After several launches, the hourly cost will be presented both in the catalog on the blueprint and when an environment is running, the estimation will be presented in the environment page. Cost information can be used for policies and approval flows as well as it's captured and passed to OPA integration.
> 
diff --git a/docs/environment-services/Introspection and layouts.md b/docs/environment-services/Introspection and layouts.md
index 1ad9cfed9..558e849f8 100644
--- a/docs/environment-services/Introspection and layouts.md
+++ b/docs/environment-services/Introspection and layouts.md
@@ -3,17 +3,17 @@ sidebar_position: 3
title: Resource Introspection & Layouts
---
-While infrastructure orchestration using Infrastructure as Code (IaC) framework become a standard, it entails a challenge of visibility to the deployed resources. As environment consumers might not have access to the cloud provider itself, but still needs access and information about the deployed resources Torque is providing __Resource introspection__ and __Resource layout__ for any of the deployed IaC frameworks. Any of the deployed resources will have it's associated attributes that can be used to access and control it. Note that introspection information is available only after the grain deployment complete successfully.
+While infrastructure orchestration using Infrastructure as Code (IaC) framework become a standard, it entails a challenge of visibility to the deployed resources. As environment consumers might not have access to the cloud provider itself, but still needs access and information about the deployed resources is providing __Resource introspection__ and __Resource layout__ for any of the deployed IaC frameworks. Any of the deployed resources will have it's associated attributes that can be used to access and control it. Note that introspection information is available only after the grain deployment complete successfully.
> 
-Based on the introspection data, Torque generates a __Resource layout__, which is usually used by an environment consumer (who may not be an expert in IaC of automation frameworks). The layout will highlight the interesting entities out of the large amount of resources that deployed in the environment.
+Based on the introspection data, generates a __Resource layout__, which is usually used by an environment consumer (who may not be an expert in IaC of automation frameworks). The layout will highlight the interesting entities out of the large amount of resources that deployed in the environment.
In the following example, we deployed a single Terraform file that deployed a 3 tier wordpress application. The deployment process ended and 28 cloud resources created.
> 
-Out of the 28 deployed resources, Torque highlights the 3 VM with their basic attributes like public IP and instance type presented on the cards. The introspection data, is used to enable resource Actions, workflows and remote connection for specific resource types.
+Out of the 28 deployed resources, highlights the 3 VM with their basic attributes like public IP and instance type presented on the cards. The introspection data, is used to enable resource Actions, workflows and remote connection for specific resource types.
> 
diff --git a/docs/environment-services/actions-and-workflows.md b/docs/environment-services/actions-and-workflows.md
index 8f7ba688e..5fd432d60 100644
--- a/docs/environment-services/actions-and-workflows.md
+++ b/docs/environment-services/actions-and-workflows.md
@@ -15,7 +15,7 @@ title: Actions and Workflows
## Overview
-Managing cloud resources efficiently is critical for modern organizations. Leaving resources running when not in use can lead to significant waste and security risks. Torque's Actions and Workflows provide automated solutions to optimize your cloud infrastructure.
+Managing cloud resources efficiently is critical for modern organizations. Leaving resources running when not in use can lead to significant waste and security risks. 's Actions and Workflows provide automated solutions to optimize your cloud infrastructure.
### Why Resource Management Matters
@@ -39,9 +39,9 @@ Managing cloud resources efficiently is critical for modern organizations. Leavi
- Improve overall system performance and responsiveness
- Optimize resource allocation across your infrastructure
-### Torque's Solution
+### 's Solution
-Torque provides comprehensive resource management through two complementary approaches:
+ provides comprehensive resource management through two complementary approaches:
- **🎯 Actions** - Execute immediate operations on specific resources (power on/off, restart, connect)
- **⏰ Workflows** - Schedule automated operations across resource groups (daily shutdowns, weekend scaling)
@@ -50,7 +50,7 @@ This combination enables both reactive management and proactive automation, ensu
## Actions
-Torque provides a built-in set of **actions** you can run on specific cloud resources in the environment to optimize resource usage and achieve cost savings, security improvements, and performance benefits.
+ provides a built-in set of **actions** you can run on specific cloud resources in the environment to optimize resource usage and achieve cost savings, security improvements, and performance benefits.
## Workflows
@@ -65,7 +65,7 @@ Torque provides a built-in set of **actions** you can run on specific cloud reso
:::info
**Learn More About Workflows**
-To learn how to create and manage workflows in your Torque account, visit our [Workflows Overview](/workflows/workflows-overview) guide.
+To learn how to create and manage workflows in your account, visit our [Workflows Overview](/workflows/workflows-overview) guide.
:::
## How to Execute Actions and Workflows
@@ -108,13 +108,13 @@ Learn how to create scheduled automations with [built-in actions](/workflows/wor
### Supported Actions by Resource Type
-Torque provides the following built-in actions that you can run on specific cloud resources:
+ provides the following built-in actions that you can run on specific cloud resources:
**Virtual Machines:**
- **Power On** - Start instances
- **Power Off** - Stop instances
- **Restart** - Reboot instances
-- **Connect** - Create RDP/SSH connections directly from Torque UI
+- **Connect** - Create RDP/SSH connections directly from UI
**Database Servers:**
- **Stop** - Temporarily stop database instances
@@ -147,7 +147,7 @@ For technical implementation details, refer to the comprehensive action support
| | Restart VM | AWS | Terraform | `aws_instance` | Restart an EC2 instance | - |
| | | | CloudFormation | `AWS::EC2::Instance` | | |
| | | Azure | Terraform | `azurerm_virtual_machine` | Restart an Azure VM | - |
-| | Connect to VM | AWS | Terraform | `aws_instance` | Creates RDP/SSH connection directly from Torque UI | - |
+| | Connect to VM | AWS | Terraform | `aws_instance` | Creates RDP/SSH connection directly from UI | - |
| | | AWS | CloudFormation | `AWS::EC2::Instance` | | |
| | | Azure | Terraform | `azurerm_virtual_machine` | | |
| **Databases** | Stop RDS Instance | AWS | Terraform | `aws_db_instance` | Temporarily stop an RDS instance | RDS restarts after 7 days if not repeated |
diff --git a/docs/environment-services/drift-and-update.md b/docs/environment-services/drift-and-update.md
index b2616506e..e6dd2477b 100644
--- a/docs/environment-services/drift-and-update.md
+++ b/docs/environment-services/drift-and-update.md
@@ -5,13 +5,13 @@ title: Drift & Update
## Environment Updates
-In the realm of infrastructure automation, Torque streamlines the setup and provisioning phases. However, in order to achieve true operational excellence, it is crucial to address the ongoing maintenance and management of provisioned environments. With the updates feature, Torque takes a significant leap forward, enabling DevOps teams to efficiently handle day-2 operations and effortlessly maintain the reliability, adaptability, and performance of their environments. By offering seamless redeployment options for IaC components with new code or updated input values, Updates empowers organizations to excel in the maintenance and management of provisioned infrastructures.
+In the realm of infrastructure automation, streamlines the setup and provisioning phases. However, in order to achieve true operational excellence, it is crucial to address the ongoing maintenance and management of provisioned environments. With the updates feature, takes a significant leap forward, enabling DevOps teams to efficiently handle day-2 operations and effortlessly maintain the reliability, adaptability, and performance of their environments. By offering seamless redeployment options for IaC components with new code or updated input values, Updates empowers organizations to excel in the maintenance and management of provisioned infrastructures.
### Example use cases
1. Streamlined Development, Testing, and Debugging of IaC Changes:
- The Updates feature in Quali Torque significantly accelerates the development and testing phase by offering a streamlined process for implementing and validating IaC changes. DevOps engineers can leverage this feature to seamlessly redeploy specific IaC components with new code, sourced directly from git commits. This capability eliminates the need to restart the entire environment from scratch, saving valuable time and effort.
+ The Updates feature in Quali significantly accelerates the development and testing phase by offering a streamlined process for implementing and validating IaC changes. DevOps engineers can leverage this feature to seamlessly redeploy specific IaC components with new code, sourced directly from git commits. This capability eliminates the need to restart the entire environment from scratch, saving valuable time and effort.
By using Updates, DevOps engineers can make the necessary code adjustments, such as bug fixes or feature enhancements, and redeploy the affected components. This allows them to continue the environment deployment from the point of failure or modification, without wasting time on unnecessary repetitions. Engineers can focus on the specific issue at hand, analyze logs, and determine if there are problems with the IaC code.
@@ -31,7 +31,7 @@ An update is initiated for a specific grain and can encompass the following chan
- Providing new values for the grain's inputs.
- Triggering a restart of the grain (essentially redeploying it) without making any alterations.
-Torque applies a smart rolling update mechanism that calculates which grains are affected by the updated one and ensures they are updated as well. This keeps the environment up-to-date while minimizing the impact.
+ applies a smart rolling update mechanism that calculates which grains are affected by the updated one and ensures they are updated as well. This keeps the environment up-to-date while minimizing the impact.
Users can choose to update the code version, inputs, both, or none during the same update operation.
:::note Note
@@ -42,34 +42,34 @@ To enhance user awareness and control, the user will see a "review" pop-up that
### Tracking code changes
-Torque incorporates advanced tracking capabilities to monitor new commits in your IaC repository, ensuring that your environment remains up-to-date and aligned with your desired configuration. The tracking mechanism is based on the specifications outlined in your blueprint for the source of each grain.
+ incorporates advanced tracking capabilities to monitor new commits in your IaC repository, ensuring that your environment remains up-to-date and aligned with your desired configuration. The tracking mechanism is based on the specifications outlined in your blueprint for the source of each grain.
Please see the blueprint spec [here](/blueprint-designer-guide/blueprints/blueprints-yaml-structure#source).
-Here's how Torque handles tracking based on different scenarios:
+Here's how handles tracking based on different scenarios:
1. Default Branch Tracking:
- - If you haven't specified a particular branch, tag, or commit for a grain, Torque will deploy the grain from the default branch specified in your blueprint. Additionally, Torque will continuously track the default branch for new commits, allowing you to seamlessly benefit from any updates or changes.
+ - If you haven't specified a particular branch, tag, or commit for a grain, will deploy the grain from the default branch specified in your blueprint. Additionally, will continuously track the default branch for new commits, allowing you to seamlessly benefit from any updates or changes.
2. Branch-based Tracking:
- - In cases where you have specified a branch name for a grain, Torque will deploy the grain from that specific branch. Furthermore, Torque actively monitors the specified branch, enabling it to promptly detect and incorporate new commits into the deployment process.
+ - In cases where you have specified a branch name for a grain, will deploy the grain from that specific branch. Furthermore, actively monitors the specified branch, enabling it to promptly detect and incorporate new commits into the deployment process.
3. Tag-based Tracking:
- - When you have specified a tag name for a grain, Torque deploys the grain using the code associated with that particular tag. Subsequently, if the tag is applied to a different commit in the future, Torque will detect this change and notify you, ensuring that you stay informed about modifications and their potential impact.
+ - When you have specified a tag name for a grain, deploys the grain using the code associated with that particular tag. Subsequently, if the tag is applied to a different commit in the future, will detect this change and notify you, ensuring that you stay informed about modifications and their potential impact.
4. Specific Commit Deployment:
- - If you have explicitly specified a specific commit for a grain, Torque will deploy the grain using the code associated with that exact commit. In this case, Torque does not actively track changes, as it is locked to the specified commit. It ensures that the deployed grain remains consistent and unaffected by subsequent commits.
+ - If you have explicitly specified a specific commit for a grain, will deploy the grain using the code associated with that exact commit. In this case, does not actively track changes, as it is locked to the specified commit. It ensures that the deployed grain remains consistent and unaffected by subsequent commits.
-By intelligently tracking your IaC repository based on your blueprint specifications, Torque ensures that your environment remains synchronized with the latest changes while providing the flexibility to tailor the tracking behavior to your specific requirements.
+By intelligently tracking your IaC repository based on your blueprint specifications, ensures that your environment remains synchronized with the latest changes while providing the flexibility to tailor the tracking behavior to your specific requirements.
-When Torque detects a change (new commits), it will alert you visually. You can then choose to accept the new code and redeploy the grain with the new code , or dismiss this change. If you dismiss, the alert will be gone but you can always come back and update it.
+When detects a change (new commits), it will alert you visually. You can then choose to accept the new code and redeploy the grain with the new code , or dismiss this change. If you dismiss, the alert will be gone but you can always come back and update it.
If at any point in time a new change is committed, you will be alerted again.
### Auto-Retry failed deployments
In some situations, environment deployment may fail with transient errors - ones that if you just retried, will deploy successfully.
-Torque comes with out-of-the-box knowledge of such errors, and will automatically retry to deploy failed grains in case the failure matches one of the transient error signatures.
+ comes with out-of-the-box knowledge of such errors, and will automatically retry to deploy failed grains in case the failure matches one of the transient error signatures.
This capability currently applies only to terraform grains.
-If you encounter such a failure which Torque did not recognize as transient, yet you believe should be auto-retried, please send us an email to torque-feedback@quali.com, or leave a post in our [community](https://github.com/orgs/QualiTorque/discussions).
+If you encounter such a failure which did not recognize as transient, yet you believe should be auto-retried, please send us an email to torque-feedback@quali.com, or leave a post in our [community](https://github.com/orgs/QualiTorque/discussions).
#### Disabling the auto-retry mechanism
In some specific cases, you may wish to exclude a specific grain from the auto-retry mechanism.
@@ -78,6 +78,6 @@ To achieve this, see [Disabling auto-retry](/blueprint-designer-guide/blueprints
## Drift detection
-Torque continuously monitors the environment as well will notify you via the Drift tab if someone makes changes to the environment's cloud resources while the environment is running. Click the Drift tab to view and resolve the changes.
+ continuously monitors the environment as well will notify you via the Drift tab if someone makes changes to the environment's cloud resources while the environment is running. Click the Drift tab to view and resolve the changes.
diff --git a/docs/environment-services/environment-annotations.md b/docs/environment-services/environment-annotations.md
index cd2103a4a..3fe1f7a96 100644
--- a/docs/environment-services/environment-annotations.md
+++ b/docs/environment-services/environment-annotations.md
@@ -15,9 +15,9 @@ Thank you for your understanding and support.
Environment annotations are labels or metadata that can be added to environments to provide additional information about them. Annotations can be used to define the purpose, status, or configuration of an environment, as well as to track changes or updates.
-Annotations in Torque are key-value pairs that can be added to an environment or resource using a specific syntax or format. They can be used to add descriptive information, such as the description of an environment, or to provide dynamic updates, such as the current status of a deployment or the results of a test.
+Annotations in are key-value pairs that can be added to an environment or resource using a specific syntax or format. They can be used to add descriptive information, such as the description of an environment, or to provide dynamic updates, such as the current status of a deployment or the results of a test.
-Annotations can help teams manage and organize environments in Torque by providing an easy way to track and communicate important information about them. For example, annotations can be used to indicate the power-state status of virtual machines in the environment.
+Annotations can help teams manage and organize environments in by providing an easy way to track and communicate important information about them. For example, annotations can be used to indicate the power-state status of virtual machines in the environment.
Environment annotations are a powerful tool for managing and organizing environments, and can help teams streamline their software development and testing processes by providing clear and concise information about the resources they are working with.
@@ -25,7 +25,7 @@ Environment annotations are a powerful tool for managing and organizing environm
## __To create an environment annotation:__
-Since environment annotations are __dynamic__ attributes of the environments, Torque uses __rego__ files and the policy engine to evaluate the annotation upon any chance in the environment.
+Since environment annotations are __dynamic__ attributes of the environments, uses __rego__ files and the policy engine to evaluate the annotation upon any chance in the environment.
**Step 1: Create a rego file**
@@ -60,7 +60,7 @@ Since environment annotations are __dynamic__ attributes of the environments, To
Let's take a look at a full example of how this rego file would look. In this evaluation file, we are evaluating the power state of virtual machines inside the environment. If there is even one virtual machine which is running, we will annotate the environment with "Power:On" annotation. If all of the virtual machines are stopped, the annotation will be "Power:Off".
```jsx title=power_state.rego
-package torque.annotations // Use this as the first line to signal to Torque that this file is for evaluating environment annotations.
+package torque.annotations // Use this as the first line to signal to that this file is for evaluating environment annotations.
default set_annotations = [{"key": "power", "value": "off"}] // Unless we will find at least one running VM, we will return this default annotation of "Power:Off".
@@ -74,12 +74,12 @@ set_annotations = [{"key": "power", "value": "on"}] {
```
:::tip __Note__
Currently the only supported annotations are "power:on", "power:off" and "power:torque.remove". We will add more annotations and open it for custom annotations soon.
-"torque.remove" is a general annotation value which may be used with any key. It signals to Torque to remove the annotation completely from the environment. A good example of when to use it is when the environment is ended.
+"torque.remove" is a general annotation value which may be used with any key. It signals to to remove the annotation completely from the environment. A good example of when to use it is when the environment is ended.
:::
-**Step 2: Import the rego file into Torque**
+**Step 2: Import the rego file into **
-1. If the git repository where the relevant rego file resides was not yet connected to Torque, perform the following :
+1. If the git repository where the relevant rego file resides was not yet connected to , perform the following :
1. Go to __Administration > Policy Repositories__ and click __Add a Repository__.
2. Select the git repository, specify the repository's URL, and give it a name.
> 
@@ -88,7 +88,7 @@ Currently the only supported annotations are "power:on", "power:off" and "power:
A green checkmark next to the repository's URL indicates that the repository has been added successfully.
> 
2. On the added (or existing) repository where the file resides, Click __Discover Policies__.
-3. Select the policies you want to import into Torque, and click __Generate Policies__.
+3. Select the policies you want to import into , and click __Generate Policies__.
> 
The policies are displayed in the __Policies__ page.
diff --git a/docs/environment-services/environment-labels.md b/docs/environment-services/environment-labels.md
index 0453d30fa..b49bc5921 100644
--- a/docs/environment-services/environment-labels.md
+++ b/docs/environment-services/environment-labels.md
@@ -11,7 +11,7 @@ Environment Labels are metadata tags that can be assigned to different environme
## Concept
Each environment label is a value or a combination of a key and a value. For example, a label could be `purpose:production`, where "purpose" is the key and "production" is the value. Another example can be 'Kubernetes' as a value of a label indicating the environment is a Kubernetes cluster.
-Environment Labels in Torque are a powerful tool to streamline environment management by allowing users to tag, filter, and organize environments effectively. Implementing a consistent labeling strategy will enhance visibility, management efficiency, and collaboration within your organization.
+Environment Labels in are a powerful tool to streamline environment management by allowing users to tag, filter, and organize environments effectively. Implementing a consistent labeling strategy will enhance visibility, management efficiency, and collaboration within your organization.
### Flexible Categorization
Environment labels allow you to categorize environments in any way that suits your organizational needs. Common examples include:
@@ -28,14 +28,14 @@ Labels can be utilized in scripts or automation tools to perform operations on s
## Usage
### Creating and Assigning Labels
-Labels can be assigned when creating a new environment or added to existing environments via the `Torque dashboard` or `API`.
+Labels can be assigned when creating a new environment or added to existing environments via the ` dashboard` or `API`.
> 
### Best Practices
* It's recommended to establish a consistent labeling strategy within your organization to ensure labels are meaningful and useful.
* Agree on standard keys and values that everyone should use.
-There are a few system reserved labels in Torque that are used to mark certain states. Here is a list of the system labels:
+There are a few system reserved labels in that are used to mark certain states. Here is a list of the system labels:
* `Drift Detected`
* `Pending Updates`
* `EaC:Active`
diff --git a/docs/environment-services/remote-access.md b/docs/environment-services/remote-access.md
index 451b4b3dd..8e5931c28 100644
--- a/docs/environment-services/remote-access.md
+++ b/docs/environment-services/remote-access.md
@@ -3,9 +3,9 @@ sidebar_position: 3
title: Remote Access
---
-Resources deployed and managed by Torque, can be enabled to __automatic remote access__ using RDP or SSH for environment consumers. This capability is specifically useful for VM workloads where environment consumers are used to work on the OS level and can get web-based access without cloud access or the need to handle VM authentication.
+Resources deployed and managed by , can be enabled to __automatic remote access__ using RDP or SSH for environment consumers. This capability is specifically useful for VM workloads where environment consumers are used to work on the OS level and can get web-based access without cloud access or the need to handle VM authentication.
In the consumer view, click on the "connect" option or run the "Connect" action in the side pane on a resource that supports SSH or RDP connectivity.
> 
-Note: RDP or SSH connectivity is done using Torque's QualiX component that can be deployed per environment or shared between space environments or the entire account. QualiX is used as a proxy enabling to access from the consumer browser to the target VM using RDP or SSH communication.
\ No newline at end of file
+Note: RDP or SSH connectivity is done using 's QualiX component that can be deployed per environment or shared between space environments or the entire account. QualiX is used as a proxy enabling to access from the consumer browser to the target VM using RDP or SSH communication.
\ No newline at end of file
diff --git a/docs/environment-services/scheduled-environments.md b/docs/environment-services/scheduled-environments.md
index 1bb7cda22..d0368199a 100644
--- a/docs/environment-services/scheduled-environments.md
+++ b/docs/environment-services/scheduled-environments.md
@@ -3,7 +3,7 @@ sidebar_position: 18
title: Scheduled Environments
---
-Scheduled environments in Torque allow users to plan and automate environment deployments for future time slots. This capability is particularly valuable for organizations that need to coordinate resource usage, plan maintenance windows, or ensure environments are available at specific times for testing, demos, or development activities.
+Scheduled environments in allow users to plan and automate environment deployments for future time slots. This capability is particularly valuable for organizations that need to coordinate resource usage, plan maintenance windows, or ensure environments are available at specific times for testing, demos, or development activities.
## Overview
@@ -80,13 +80,13 @@ import pic2 from '/img/scheduled-env-launch-form.png';
## Custom Resource Inventory Integration
-Scheduled environments can leverage Torque's custom resource inventory to ensure that required resources are available at the scheduled time. This integration prevents scheduling conflicts and guarantees resource availability.
+Scheduled environments can leverage 's custom resource inventory to ensure that required resources are available at the scheduled time. This integration prevents scheduling conflicts and guarantees resource availability.
### Resource Reservation Process
1. **Resource Definition**: Define custom resources in the inventory (e.g., GPU instances, specialized hardware, licenses)
2. **Capacity Planning**: Set desired capacity for each resource type in blueprints
-3. **Advance Booking**: When scheduling environments, Torque reserves the required resources
+3. **Advance Booking**: When scheduling environments, reserves the required resources
4. **Conflict Prevention**: The system prevents overbooking by checking resource availability
### Example: GPU Resource Management
@@ -122,7 +122,7 @@ Here are some common "Resource Types" for scheduling:
## Scheduling Conflict Resolution
-Torque provides intelligent conflict resolution when scheduling conflicts occur, offering users alternative time slots that meet their requirements.
+ provides intelligent conflict resolution when scheduling conflicts occur, offering users alternative time slots that meet their requirements.
### Conflict Detection
@@ -134,7 +134,7 @@ The system automatically detects conflicts when:
### Next Available Time Slot
-When conflicts are detected, Torque offers the **"Next Available Time Slot"** feature:
+When conflicts are detected, offers the **"Next Available Time Slot"** feature:
1. **Conflict Notification**: User is informed that their requested time slot is unavailable
2. **Alternative Suggestions**: System presents the next available time slots that meet all requirements
diff --git a/docs/example-blueprints/application-orchestration.md b/docs/example-blueprints/application-orchestration.md
index 133b7796c..f606e2a73 100644
--- a/docs/example-blueprints/application-orchestration.md
+++ b/docs/example-blueprints/application-orchestration.md
@@ -29,6 +29,6 @@ grains:
...
```
-In the example above, Torque __normalized__ the various automation frameworks so they all share the same interface and can be used as __"building-blocks"__ and pass information between them. Note how the connection string that was generated for the RDS database is passed into the microservice application so software components will be able to use the database.
+In the example above, __normalized__ the various automation frameworks so they all share the same interface and can be used as __"building-blocks"__ and pass information between them. Note how the connection string that was generated for the RDS database is passed into the microservice application so software components will be able to use the database.
> 
diff --git a/docs/example-blueprints/cross-account-provisioning.md b/docs/example-blueprints/cross-account-provisioning.md
index c0395767a..9b6b3fcb3 100644
--- a/docs/example-blueprints/cross-account-provisioning.md
+++ b/docs/example-blueprints/cross-account-provisioning.md
@@ -5,18 +5,18 @@ title: Cross Account Provisioning (AWS)
# Cross Account Provisioning in AWS
-Torque supports multiple options for provisioning resources across multiple AWS accounts.
+ supports multiple options for provisioning resources across multiple AWS accounts.
**Here are two common approaches**
- - [Option A: Torque Agent in each account](#option-a-torque-agent-in-each-account)
- - [Option B: Single Torque Agent in the Master Account](#option-b-single-torque-agent-in-the-master-account)
+ - [Option A: Agent in each account](#option-a-torque-agent-in-each-account)
+ - [Option B: Single Agent in the Master Account](#option-b-single-torque-agent-in-the-master-account)
-## Option A: Torque Agent in each account
+## Option A: Agent in each account
### Requirements and Setup
-- Each Torque Agent is sitting in a different AWS account.
+- Each Agent is sitting in a different AWS account.
- Each Agent is deployed in a different EKS cluster.
- OIDC is enabled on the clusters, and they each have a valid default service account with an IAM role annotation.
@@ -27,14 +27,14 @@ Torque supports multiple options for provisioning resources across multiple AWS
### Architectural Diagram
-> *Option A Diagram: Cross Accounts provisioning with Torque Agent in each account*
+> *Option A Diagram: Cross Accounts provisioning with Agent in each account*
-## Option B: Single Torque Agent in the Master Account
+## Option B: Single Agent in the Master Account
### Requirements and Setup
-- Torque agent is configured with a valid default service account that authenticates into an IAM role via OIDC (known as Master account role).
+- agent is configured with a valid default service account that authenticates into an IAM role via OIDC (known as Master account role).
- Each target AWS account has an IAM role with an identical name, with a trust policy set up to allow the Master account role to assume it (known as Target account role).
- These Target Account roles have the permissions necessary to perform the actions Terraform will describe on the respective account.
- By utilizing identical names, the only difference in the IAM role ARNs is the account number.
@@ -70,7 +70,7 @@ provider "aws" {
}
```
-**Torque Blueprint Example**
+** Blueprint Example**
The Blueprint provides the user with a list of accounts to choose from, with a friendly text name for each account which is split out before passing the account number to Terraform.
@@ -108,11 +108,11 @@ grains:
### Architectural Diagram
-> *Option B Diagram: Cross Accounts provisioning with a Single Torque Agent in the Master Account
+> *Option B Diagram: Cross Accounts provisioning with a Single Agent in the Master Account
## Summary
Both options provide flexibility in provisioning resources across multiple AWS accounts based on your specific requirements and setup.
-Option A is suitable when you have separate EKS clusters for each account, while Option B allows you to manage multiple accounts from a single Torque agent in the master account.
\ No newline at end of file
+Option A is suitable when you have separate EKS clusters for each account, while Option B allows you to manage multiple accounts from a single agent in the master account.
\ No newline at end of file
diff --git a/docs/example-blueprints/k8s-as-a-service.md b/docs/example-blueprints/k8s-as-a-service.md
index 09a33bc99..d1f0fd724 100644
--- a/docs/example-blueprints/k8s-as-a-service.md
+++ b/docs/example-blueprints/k8s-as-a-service.md
@@ -9,7 +9,7 @@ In the following example, Terraform is utilized to orchestrate a GKE (Google Clo
> 
-The following blueprint is build out of two grains dependent on one another. The application will be deployed only once the GKE cluster will be fully up and running including all required networking, storage and compute elements. Part of the GKE orchestration includes saving the kube config file available for the Torque agent, so __the application can be installed without a Torque agent in the newly created cluster__. The Torque agent, will use the kube-config file to authenticate into the GKE cluster and execute the application.
+The following blueprint is build out of two grains dependent on one another. The application will be deployed only once the GKE cluster will be fully up and running including all required networking, storage and compute elements. Part of the GKE orchestration includes saving the kube config file available for the agent, so __the application can be installed without a agent in the newly created cluster__. The agent, will use the kube-config file to authenticate into the GKE cluster and execute the application.
```yaml
spec_version: 2
diff --git a/docs/example-blueprints/k8s-compliance.md b/docs/example-blueprints/k8s-compliance.md
index c6d18114a..fa7f9f66d 100644
--- a/docs/example-blueprints/k8s-compliance.md
+++ b/docs/example-blueprints/k8s-compliance.md
@@ -3,7 +3,7 @@ sidebar_position: 3
title: Kubernetes Compliance
---
-Securing and ensuring compliance for deployments across various business processes can present challenges, particularly when organizations doesn't use a centralized approach for self-service, CI/CD, and other deployment methods. Implementing a Torque blueprint that includes deployment validations offers a recommended approach to orchestrate, track changes, and maintain consistency, thus establishing a best practice for secure deployments.
+Securing and ensuring compliance for deployments across various business processes can present challenges, particularly when organizations doesn't use a centralized approach for self-service, CI/CD, and other deployment methods. Implementing a blueprint that includes deployment validations offers a recommended approach to orchestrate, track changes, and maintain consistency, thus establishing a best practice for secure deployments.
The following environment was orchestrated form a blueprint with multiple grains. The initial deployment process downloads the latest deployment files and validate them through a set of open-source tools - [Datree.io](https://www.datree.io/) and [Kubescape](https://github.com/kubescape/kubescape). Once only the validation is done and the score meets the criteria, the application deployment will take place.
diff --git a/docs/getting-started/Resources-Inventory/cloud-resources/aws-setup.md b/docs/getting-started/Resources-Inventory/cloud-resources/aws-setup.md
index 7ee2a337a..4574f2f8a 100644
--- a/docs/getting-started/Resources-Inventory/cloud-resources/aws-setup.md
+++ b/docs/getting-started/Resources-Inventory/cloud-resources/aws-setup.md
@@ -33,7 +33,7 @@ Currently the only authentication method supported is IAM Users with an Access a
---
### Minimal Permissions Required
-Torque Resources Inventory requires read-only access to inventory and manage cloud resources. The following permissions are required:
+ Resources Inventory requires read-only access to inventory and manage cloud resources. The following permissions are required:
- `AWSResourceExplorerReadOnlyAccess` assigned to the IAM User. This only gives you the ability to see resources in Cloud Curate.
- For the ability to convert resources in Terraform or manage environments, `ReadOnlyAccess` is recommended so all resource types can be used.
@@ -47,4 +47,4 @@ Navigate to the `Account Center`.
3. Select `AWS` as the cloud provider.
4. Provide the necessary details, including `Account Number`, `Access Key`, `Secret Key`, and the `View Arn`. `Cloud Account Name` can be anything as its your identifier.
5. Click Save.
-6. Once connected, Torque Resources Inventory will begin scanning and discovering your cloud resources.
\ No newline at end of file
+6. Once connected, Resources Inventory will begin scanning and discovering your cloud resources.
\ No newline at end of file
diff --git a/docs/getting-started/Resources-Inventory/cloud-resources/azure-setup.md b/docs/getting-started/Resources-Inventory/cloud-resources/azure-setup.md
index 8e163105d..c303d7583 100644
--- a/docs/getting-started/Resources-Inventory/cloud-resources/azure-setup.md
+++ b/docs/getting-started/Resources-Inventory/cloud-resources/azure-setup.md
@@ -20,7 +20,7 @@ title: Azure Setup
### Minimal Permissions Required
-Torque Resources Inventory requires read-only access to inventory and manage cloud resources. The following permissions are required:
+ Resources Inventory requires read-only access to inventory and manage cloud resources. The following permissions are required:
- Reader role assigned to the Azure subscription.
- The ability to list resources, read metadata, and access resource details for all resources within the subscription.
@@ -36,4 +36,4 @@ Navigate to the `Account Center`.
3. Select Azure as the cloud provider.
4. Provide the necessary details, including `Subscription ID`, `Tenant ID`, `Application ID`, and the `Application Secret` with read-only permissions.
5. Click Connect.
-6. Once connected, Torque Resources Inventory will begin scanning and discovering your cloud resources.
\ No newline at end of file
+6. Once connected, Resources Inventory will begin scanning and discovering your cloud resources.
\ No newline at end of file
diff --git a/docs/getting-started/Resources-Inventory/cloud-resources/index.md b/docs/getting-started/Resources-Inventory/cloud-resources/index.md
index 8e1ee22f5..e9a46a8f1 100644
--- a/docs/getting-started/Resources-Inventory/cloud-resources/index.md
+++ b/docs/getting-started/Resources-Inventory/cloud-resources/index.md
@@ -5,15 +5,15 @@ title: Cloud Resources
## Introduction
-Welcome to Torque Cloud Resources, an advanced solution designed to facilitate comprehensive visibility and governance over your cloud infrastructure. Torque Cloud Resources connects to your cloud accounts with read-only permissions, allowing for in-depth discovery, categorization, and curation of cloud resources. Users can filter their resources based on type, location, or Infrastructure as Code (IaC) status, providing fine-grained control over their cloud estate.
+Welcome to Cloud Resources, an advanced solution designed to facilitate comprehensive visibility and governance over your cloud infrastructure. Cloud Resources connects to your cloud accounts with read-only permissions, allowing for in-depth discovery, categorization, and curation of cloud resources. Users can filter their resources based on type, location, or Infrastructure as Code (IaC) status, providing fine-grained control over their cloud estate.
-Torque Cloud Resources classifies resources by their IaC status as follows:
+ Cloud Resources classifies resources by their IaC status as follows:
- **Unmanaged**: Resources that have been created manually and are not governed by IaC.
- **Codified**: Resources that are integrated with and managed by your existing IaC practices.
- **Managed**: Resources that are managed under Quali's governance framework.
-Torque Resources Inventory allows users to curate selected resources into a cart, transforming them into Terraform configuration files and state files. These artifacts are readily available for download, enabling seamless integration into Infrastructure as Code workflows.
+ Resources Inventory allows users to curate selected resources into a cart, transforming them into Terraform configuration files and state files. These artifacts are readily available for download, enabling seamless integration into Infrastructure as Code workflows.
import pic1 from '/img/resource-inventory.png';
@@ -23,7 +23,7 @@ import pic1 from '/img/resource-inventory.png';
## Key Features
-Torque Cloud Resources offers a suite of features to help you manage your cloud infrastructure effectively:
+ Cloud Resources offers a suite of features to help you manage your cloud infrastructure effectively:
- **Cloud Resource Discovery**: Automatically discovers and inventories all resources within your Azure subscription, providing a holistic view of your cloud environment.
- **Resource Filtering**: Offers advanced filtering capabilities, allowing resources to be categorized by type, geographical region, and IaC status for efficient management.
@@ -34,7 +34,7 @@ Torque Cloud Resources offers a suite of features to help you manage your cloud
## Adding a Cloud Account
-To begin using Torque Resources Inventory, you must connect your cloud account. Currently, AWS and Azure clouds are supported.
+To begin using Resources Inventory, you must connect your cloud account. Currently, AWS and Azure clouds are supported.
### Supported cloud providers
* [AWS](./cloud-resources/aws-setup)
@@ -44,13 +44,13 @@ To begin using Torque Resources Inventory, you must connect your cloud account.
## Cloud Resources Inventory
-Upon connecting your account, Torque Resources Inventory will automatically perform a full scan and inventory all resources in your subscription. The Cloud Resources Inventory page presents a comprehensive view of your resources, which can be filtered by:
+Upon connecting your account, Resources Inventory will automatically perform a full scan and inventory all resources in your subscription. The Cloud Resources Inventory page presents a comprehensive view of your resources, which can be filtered by:
- **Resource Type**: Categories such as virtual machines, databases, and networking components.
- **Location**: Filter resources by their geographical deployment region.
- **IaC Status**: Indicate whether resources are unmanaged, codified, or managed.
-Torque Resources Inventory provides insights into which resources are under IaC management and highlights unmanaged resources that may need to be incorporated into governance frameworks.
+ Resources Inventory provides insights into which resources are under IaC management and highlights unmanaged resources that may need to be incorporated into governance frameworks.
import pic2 from '/img/iac-status.png';
@@ -79,7 +79,7 @@ Curate your cloud resources with ease and transform them into Terraform configur
- **Individual Add Method**: Click the plus icon next to each resource to add it individually to the cart.
4. Review the items in your cart to ensure all desired resources are included.
5. Click Curate. A summary dialog will appear, allowing you to confirm your selection. Click Approve & Curate to proceed.
-6. Torque Resources Inventory will generate a Terraform configuration and state file for the curated resources. The curation process may take a few minutes.
+6. Resources Inventory will generate a Terraform configuration and state file for the curated resources. The curation process may take a few minutes.
7. Once completed, the generated artifacts will be available for download.
### Downloading the Artifacts
@@ -93,7 +93,7 @@ The Cart feature allows you to select and curate multiple resources before gener
### Using the Downloaded IaC Artifacts
-The Terraform configuration and state files generated by Torque Resources Inventory can be used to manage your cloud resources through Infrastructure as Code. Possible actions include:
+The Terraform configuration and state files generated by Resources Inventory can be used to manage your cloud resources through Infrastructure as Code. Possible actions include:
- **Integration with Existing IaC Projects**: Incorporate the generated Terraform files into existing IaC projects to maintain consistency in infrastructure management.
- **Manage Resources via Terraform**: Utilize the generated files to manage manually provisioned resources, simplifying their incorporation into existing IaC frameworks.
@@ -102,9 +102,9 @@ The Terraform configuration and state files generated by Torque Resources Invent
---
-## Best Practices for Using Torque Resources Inventory
+## Best Practices for Using Resources Inventory
-To maximize the benefits of Torque Resources Inventory, consider the following best practices:
+To maximize the benefits of Resources Inventory, consider the following best practices:
- **Tag Resources Consistently**: Ensure that all cloud resources are tagged appropriately for easier filtering and curation.
- **Frequent Scans**: Regularly scan your cloud accounts to maintain up-to-date visibility of resources and changes.
@@ -117,11 +117,11 @@ To maximize the benefits of Torque Resources Inventory, consider the following b
### What Cloud Providers Are Supported?
-Currently, Torque Resources Inventory supports only Azure and AWS clouds. Support for other cloud providers, such as Google Cloud, is planned for future releases.
+Currently, Resources Inventory supports only Azure and AWS clouds. Support for other cloud providers, such as Google Cloud, is planned for future releases.
-### What Permissions Are Required for Torque Resources Inventory?
+### What Permissions Are Required for Resources Inventory?
-Torque Resources Inventory requires read-only permissions to your Azure subscription, specifically the Reader role, to perform resource discovery and inventory.
+ Resources Inventory requires read-only permissions to your Azure subscription, specifically the Reader role, to perform resource discovery and inventory.
### Can I Edit the Generated Terraform Files?
@@ -137,25 +137,25 @@ It is recommended to scan your cloud account at least weekly to ensure that your
### Unable to Connect to Azure Account
-If you are experiencing issues while connecting your Azure account to Torque Resources Inventory, verify the following:
+If you are experiencing issues while connecting your Azure account to Resources Inventory, verify the following:
- The provided credentials have read-only permissions.
- The subscription ID is accurate.
-- There are no network or firewall settings preventing Torque Resources Inventory from accessing Azure.
+- There are no network or firewall settings preventing Resources Inventory from accessing Azure.
### Terraform Generation Failed
If Terraform generation fails:
- Verify that all selected resources have the necessary metadata available.
-- Ensure there are no permission issues preventing Torque Resources Inventory from accessing resource details.
-- Contact Torque Resources Inventory support if the issue persists.
+- Ensure there are no permission issues preventing Resources Inventory from accessing resource details.
+- Contact Resources Inventory support if the issue persists.
---
## Support
-For further assistance, please contact the Torque Resources Inventory support team at [support@quali.com](mailto:support@quali.com) or visit our [support page](https://support.quali.com).
+For further assistance, please contact the Resources Inventory support team at [support@quali.com](mailto:support@quali.com) or visit our [support page](https://support.quali.com).
## Glossary
@@ -163,4 +163,4 @@ For further assistance, please contact the Torque Resources Inventory support te
- **Terraform**: An open-source IaC tool that allows users to define and provision infrastructure using a declarative configuration language.
- **Reader Role**: A built-in Azure role that provides read-only access to cloud resources.
-Torque Resources Inventory provides an effective mechanism to address cloud sprawl, enabling you to transition unmanaged resources into managed, codified infrastructure seamlessly integrated into your IaC strategy.
\ No newline at end of file
+ Resources Inventory provides an effective mechanism to address cloud sprawl, enabling you to transition unmanaged resources into managed, codified infrastructure seamlessly integrated into your IaC strategy.
\ No newline at end of file
diff --git a/docs/getting-started/Resources-Inventory/custom-resources/index.md b/docs/getting-started/Resources-Inventory/custom-resources/index.md
index cd9e93708..5abce5332 100644
--- a/docs/getting-started/Resources-Inventory/custom-resources/index.md
+++ b/docs/getting-started/Resources-Inventory/custom-resources/index.md
@@ -7,7 +7,7 @@ title: Custom Resources
## Introduction
-Torque Custom Resources enables you to reserve and manage custom resource types for your environments based on blueprint requirements. This feature allows you to define logical, physical, or any custom resource type with specific attributes, create concrete resource instances, and reserve them for environments when needed.
+ Custom Resources enables you to reserve and manage custom resource types for your environments based on blueprint requirements. This feature allows you to define logical, physical, or any custom resource type with specific attributes, create concrete resource instances, and reserve them for environments when needed.
With Custom Resources, administrators can:
@@ -28,7 +28,7 @@ With Custom Resources, administrators can:
1. **Admin Setup**: Administrators define custom resource types and create concrete resource instances
2. **Blueprint Definition**: Blueprint authors specify resource requirements in the blueprint YAML
-3. **Environment Launch**: When launching an environment, Torque automatically reserves the required resources
+3. **Environment Launch**: When launching an environment, automatically reserves the required resources
4. **Resource Access**: Reserved resource data becomes available to blueprint grains for use in deployment activities
## Resource Requirements in Blueprints
diff --git a/docs/getting-started/Resources-Inventory/custom-resources/setup.md b/docs/getting-started/Resources-Inventory/custom-resources/setup.md
index fbead54b0..1ce04085d 100644
--- a/docs/getting-started/Resources-Inventory/custom-resources/setup.md
+++ b/docs/getting-started/Resources-Inventory/custom-resources/setup.md
@@ -5,11 +5,11 @@ title: Setup
# Custom Resources Setup
-This guide walks you through setting up Custom Resources in Torque, from defining resource types to creating resource instances that can be reserved by blueprints.
+This guide walks you through setting up Custom Resources in , from defining resource types to creating resource instances that can be reserved by blueprints.
## Prerequisites
-- Administrator access to Torque
+- Administrator access to
- Understanding of your infrastructure resource requirements
- Basic knowledge of YAML syntax for blueprint integration
@@ -19,7 +19,7 @@ Before creating resource instances, you need to define the resource types that w
### Creating a Resource Type
-1. Navigate to the **Admin** section in Torque
+1. Navigate to the **Admin** section in
2. Go to **Custom Resources** > **Resource Types**
3. Click **Create Resource Type**
4. Fill in the resource type details:
diff --git a/docs/getting-started/asset-discovery.md b/docs/getting-started/asset-discovery.md
index b1e7d1bad..0ee5fa306 100644
--- a/docs/getting-started/asset-discovery.md
+++ b/docs/getting-started/asset-discovery.md
@@ -3,10 +3,10 @@ sidebar_position: 8
title: Asset Discovery
---
-Torque needs access to your relevant git repositories to read your Terraform modules or Helm charts.
-Torque supports 4 version control systems: GitHub, GitLab, BitBucket, and Azure DevOps.
+ needs access to your relevant git repositories to read your Terraform modules or Helm charts.
+ supports 4 version control systems: GitHub, GitLab, BitBucket, and Azure DevOps.
-Once a repository is connected, Torque will automatically discover the assets in it (Terraform modules, Helm charts, Kubernetes manifests, CloudFormation templates, and batch scripts). See the full list [here](/overview/supported-platforms) and will ask you to select the assets to be used for the blueprints. After you select the relevant assets, Torque will automatically generate initial blueprints from your assets.
+Once a repository is connected, will automatically discover the assets in it (Terraform modules, Helm charts, Kubernetes manifests, CloudFormation templates, and batch scripts). See the full list [here](/overview/supported-platforms) and will ask you to select the assets to be used for the blueprints. After you select the relevant assets, will automatically generate initial blueprints from your assets.
:::tip __Note__:
@@ -20,7 +20,7 @@ Click an auto-generated blueprint to view the resulting yaml file. You can custo
To connect an Azure DevOps repo, use this format: `https://dev.azure.com/{organization}/{project}/_git/{repositoryName}`.
-3. Now that your repository is connected, click __Discover Assets__ to have Torque auto-generate blueprints out of the suitable assets.
+3. Now that your repository is connected, click __Discover Assets__ to have auto-generate blueprints out of the suitable assets.
> 
4. Next, go to the __Blueprints__ page and publish the new blueprints.
> 
diff --git a/docs/getting-started/getting-started-with-kubernetes.md b/docs/getting-started/getting-started-with-kubernetes.md
index 38947647a..37695c705 100644
--- a/docs/getting-started/getting-started-with-kubernetes.md
+++ b/docs/getting-started/getting-started-with-kubernetes.md
@@ -1,16 +1,16 @@
---
sidebar_position: 3
-title: Install Torque Agent
+title: Install our Agent
---
-__Torque Control plane__ offers centralized orchestration and management for Kubernetes orchestration tools such as Kubernetes manifest, Helm and Crossplane. In this guide, we will go over some of Torque basic features allowing quick onboarding of Kubernetes automation assets into the platform, standardization of Kubernetes orchestration using blueprints and securing deployment process using tagging, policies and RBAC.
+__ Control plane__ offers centralized orchestration and management for Kubernetes orchestration tools such as Kubernetes manifest, Helm and Crossplane. In this guide, we will go over some of basic features allowing quick onboarding of Kubernetes automation assets into the platform, standardization of Kubernetes orchestration using blueprints and securing deployment process using tagging, policies and RBAC.
In this quick-start guide, we will cover the following topics:
-1. Create a new Torque Space
+1. Create a new Space
2. Onboard a GitHub repository and discover the automation assets in it
3. Generate your first blueprint and modify it to include deployment credentials
4. Launch a blueprint and get access to the deployed resource in the newly created environment
-> NOTE: This guide will focus on Kubernetes manifest and Helm orchestration, [click here](/overview/supported-platforms.md) for more information about Torque supported platform.
+> NOTE: This guide will focus on Kubernetes manifest and Helm orchestration, [click here](/overview/supported-platforms.md) for more information about supported platform.
## Step #1: Create a space
:::info
@@ -25,11 +25,11 @@ __Spaces__ are logically separate area that contains an association to one or mo
Space name, image and color can always be changes in the "Administration" are under the "Spaces" tab
## Step #2: Connect a repository
-Now, that you have a new space configured, we will associate a repository to the space and generate blueprints using the automation-assets that will be discovered by Torque in that repository. We recommend using your-own repository hosted in one of the supported Git Providers. For using on-prem/hosted versions of one of the supported (Version Control System) providers, see [Repository Setup](/admin-guide/source-control/source-control-github).
+Now, that you have a new space configured, we will associate a repository to the space and generate blueprints using the automation-assets that will be discovered by in that repository. We recommend using your-own repository hosted in one of the supported Git Providers. For using on-prem/hosted versions of one of the supported (Version Control System) providers, see [Repository Setup](/admin-guide/source-control/source-control-github).
-1. In the __repository onboarding__ wizard, choose your VCS provider, provide the repository URL and click "Connect". Torque will open a new windows where you will be requested to authenticate to the VSC provider. VCS providers work differently, but usually, a token will be generated for your user and Torque will use that for any communication with that VCS.
+1. In the __repository onboarding__ wizard, choose your VCS provider, provide the repository URL and click "Connect". will open a new windows where you will be requested to authenticate to the VSC provider. VCS providers work differently, but usually, a token will be generated for your user and will use that for any communication with that VCS.
-2. Click "Discover Assets" to initiate the __Torque asset discovery process__ that will go over the repository and highlight the automation assets Torque discovered.
+2. Click "Discover Assets" to initiate the __Torque asset discovery process__ that will go over the repository and highlight the automation assets discovered.
3. To __generate a blueprint__ from one of the discovered assets, check the blueprint in the list and click on "Generate Blueprints"
4. Click on "Connect an Agent"
@@ -39,7 +39,7 @@ import pic1 from '/img/getting-repository-onboarding.gif';
## Step #3: Install an Agent
-In this step, we will configure a Torque agent that will execute, manage and monitor the Kubernetes workload we discovered and plan to deploy.
+In this step, we will configure a agent that will execute, manage and monitor the Kubernetes workload we discovered and plan to deploy.
1. In the "Connect an agent" dialog, select the __"Install new self hosted agent"__ and click "Next". Now, you are required to choose one of the supported cloud providers managed Kubernetes service or a self-managed Kubernetes cluster. Choose one of the options, In this example, we will use AWS EKS.
2. Provide a new for the agent, and click "Next"
@@ -52,10 +52,10 @@ import pic2 from '/img/k8s-agent-connected.png';
:::info
-The command creates a new namespaces, and deploys the Torque agent in it. It might take up to 2 minutes for the Agent to get up and running, so want for the Torque self-service indication to make sure the agent is connected.
+The command creates a new namespaces, and deploys the agent in it. It might take up to 2 minutes for the Agent to get up and running, so want for the self-service indication to make sure the agent is connected.
1. Now, it's associate our newly connected agent with our space. Click the "Associate to space".
-2. The space is already selected for you, but, you still need to set the default namespace and service-account that will be used by Torque to deploy workloads into the cluster. It's always possible to change the default values in the "Administration" section under the "Agents" section.
+2. The space is already selected for you, but, you still need to set the default namespace and service-account that will be used by to deploy workloads into the cluster. It's always possible to change the default values in the "Administration" section under the "Agents" section.
:::
## Step #4: Launch an Environment
diff --git a/docs/getting-started/getting-started-with-terraform.md b/docs/getting-started/getting-started-with-terraform.md
index 72a2ff464..4b66a2805 100644
--- a/docs/getting-started/getting-started-with-terraform.md
+++ b/docs/getting-started/getting-started-with-terraform.md
@@ -2,15 +2,15 @@
sidebar_position: 2
title: Provision Terraform
---
-__Torque Control Plane__ offers centralized orchestration and management for Terraform and other IaC tools. In this guide, we will go over some of Torque basic features allowing quick onboarding of Terraform modules into the platform, standardization of Terraform automation using blueprints and securing deployment process using tagging, policies and RBAC.
+__Torque Control Plane__ offers centralized orchestration and management for Terraform and other IaC tools. In this guide, we will go over some of basic features allowing quick onboarding of Terraform modules into the platform, standardization of Terraform automation using blueprints and securing deployment process using tagging, policies and RBAC.
In this quick-start guide, we will cover the following topics:
-1. Create a new Torque Space
+1. Create a new Space
2. Onboard a GitHub repository and discover the automation assets in it
3. Generate your first blueprint and modify it to include deployment credentials
4. Launch a blueprint and get access to the deployed resource in the newly created environment
-> NOTE: This guide will focus on AWS and Azure Terraform workloads, [click here](/overview/supported-platforms.md) for more information about Torque supported platform.
+> NOTE: This guide will focus on AWS and Azure Terraform workloads, [click here](/overview/supported-platforms.md) for more information about supported platform.
## Step #1: Create a space
:::info
@@ -27,12 +27,12 @@ __Spaces__ are logically separate area that contains an association to one or mo
## Step #2: Connect a repository
-Now, that you have a new space configured, we will associate a repository to the space and generate blueprints using the automation-assets that will be discovered by Torque in that repository. We recommend using your-own repository hosted in one of the supported Git Providers. For using on-prem/hosted versions of one of the supported (Version Control System)) providers, see [Repository Setup](/admin-guide/source-control/source-control-github).
+Now, that you have a new space configured, we will associate a repository to the space and generate blueprints using the automation-assets that will be discovered by in that repository. We recommend using your-own repository hosted in one of the supported Git Providers. For using on-prem/hosted versions of one of the supported (Version Control System)) providers, see [Repository Setup](/admin-guide/source-control/source-control-github).
-1. In the __repository onboarding__ wizard, choose your VCS provider, provide the repository URL and click "Connect". Torque will open a new windows where you will be requested to authenticate to the VSC provider. VCS providers work differently, but usually, a token will be generated for your user and Torque will use that for any communication with that VCS.
+1. In the __repository onboarding__ wizard, choose your VCS provider, provide the repository URL and click "Connect". will open a new windows where you will be requested to authenticate to the VSC provider. VCS providers work differently, but usually, a token will be generated for your user and will use that for any communication with that VCS.
> Note: you can always use [this](https://github.com/QualiTorque/Sample-Terraform) example repository with some pre-existing automation assets.
-2. Click "Discover Assets" to initiate the __Torque asset discovery process__ that will go over the repository and highlight the automation assets Torque discovered.
+2. Click "Discover Assets" to initiate the __Torque asset discovery process__ that will go over the repository and highlight the automation assets discovered.
3. To __generate a blueprint__ from one of the discovered assets, check the blueprint in the list and click on "Generate Blueprints"
4. Click on "Connect an Agent"
@@ -50,7 +50,7 @@ __Quali Hosted Agent__ is a free pre-configured agent hosted by Quali allowing y
3. In the following step, we will modify the blueprint using the __YAML editor__ adding authentication information for AWS or Azure so our Terraform module will be executed on them. This section is AWS or Azure specific, so make sure to follow the section matching your cloud provider.
### AWS authentication
-The Quali-hosted agent needs your __AWS credentials__ to provision the environment on your AWS account. We will edit the blueprint to add the AWS credentials as environment variables, and expose them as inputs so it will be easier to provide them upon launch of a new environment. Editing the blueprint in the blueprint editor provides syntax highlighting, auto-correcting and live validation of the YAML and data provided. Make sure to click on "Save Changes" when updating the YAML to make sure the blueprint is saved in Torque.
+The Quali-hosted agent needs your __AWS credentials__ to provision the environment on your AWS account. We will edit the blueprint to add the AWS credentials as environment variables, and expose them as inputs so it will be easier to provide them upon launch of a new environment. Editing the blueprint in the blueprint editor provides syntax highlighting, auto-correcting and live validation of the YAML and data provided. Make sure to click on "Save Changes" when updating the YAML to make sure the blueprint is saved in .
1. Add the following inputs under the input section of the blueprint:
@@ -72,7 +72,7 @@ The Quali-hosted agent needs your __AWS credentials__ to provision the environme
### Azure authentication
-The Quali-hosted agent needs your __Azure credentials__ to provision the environment on your Azure account. We will edit the blueprint to add the Azure credentials as environment variables, and expose them as inputs so it will be easier to provide them upon launch of a new environment. Editing the blueprint in the blueprint editor provides syntax highlighting, auto-correcting and live validation of the YAML and data provided. Make sure to click on "Save Changes" when updating the YAML to make sure the blueprint is saved in Torque.
+The Quali-hosted agent needs your __Azure credentials__ to provision the environment on your Azure account. We will edit the blueprint to add the Azure credentials as environment variables, and expose them as inputs so it will be easier to provide them upon launch of a new environment. Editing the blueprint in the blueprint editor provides syntax highlighting, auto-correcting and live validation of the YAML and data provided. Make sure to click on "Save Changes" when updating the YAML to make sure the blueprint is saved in .
1. Add the following inputs under the input section of the blueprint:
diff --git a/docs/getting-started/import-cloud-resources.md b/docs/getting-started/import-cloud-resources.md
index 1b97a3734..f25d4d612 100644
--- a/docs/getting-started/import-cloud-resources.md
+++ b/docs/getting-started/import-cloud-resources.md
@@ -3,13 +3,13 @@ sidebar_position: 4
title: Import Cloud Resources
---
-__Torque Control plane__ helps you to accelerate migration of existing cloud resources into fully managed Torque environments with a few simple steps regardless of how the resources were deploy in the cloud in the first place.
+__Torque Control plane__ helps you to accelerate migration of existing cloud resources into fully managed environments with a few simple steps regardless of how the resources were deploy in the cloud in the first place.
-In the below article, we will cover the following steps for importing cloud resources into Torque using Terraform generation:
+In the below article, we will cover the following steps for importing cloud resources into using Terraform generation:
1. Generate **Terraform code (modules)** representing your existing deployed resources in the cloud.
2. Generate **Terraform state file** that represent the deployment status.
-3. Generate **Torque blueprint** that uses the Terraform code as an automation grain.
-4. Import your cloud resources into a fully managed **Torque Environment**.
+3. Generate ** blueprint** that uses the Terraform code as an automation grain.
+4. Import your cloud resources into a fully managed ** Environment**.
:::info
NOTE: This guide will focus on AWS workloads as an example, but it's possible to use it for other cloud providers (cloud and on-prem), network providers, monitoring systems and more.
@@ -19,12 +19,12 @@ NOTE: This guide will focus on AWS workloads as an example, but it's possible to
-# Importing an Environment into Torque
+# Importing an Environment into
-This guide walks you through the process of importing an existing environment into Torque, starting from resource curation to final import using the API. Follow these steps to successfully onboard an environment into Torque.
+This guide walks you through the process of importing an existing environment into , starting from resource curation to final import using the API. Follow these steps to successfully onboard an environment into .
#### Step 1: Curate and codify a Resource
-- Start by curating the resource you want to manage in Torque. After curating, you'll obtain the Terraform files and the corresponding `tfstate` file.
+- Start by curating the resource you want to manage in . After curating, you'll obtain the Terraform files and the corresponding `tfstate` file.
#### Step 2: Edit the Providers File
- Open the `providers` file within the Terraform files and remove the following sensitive credentials:
@@ -39,7 +39,7 @@ This guide walks you through the process of importing an existing environment in
#### Step 4: Create a Matching Blueprint
-- Create a corresponding Torque blueprint for the environment, named `curate-example.yaml`. Here's an example blueprint:
+- Create a corresponding blueprint for the environment, named `curate-example.yaml`. Here's an example blueprint:
```yaml
spec_version: 2
@@ -67,8 +67,8 @@ This guide walks you through the process of importing an existing environment in
#### Step 6: Use the Import API
-- To import the environment using the Torque API, make the following POST request using `curl`.
-- The API response will include the `environment-id`. After importing, you will see an import step, followed by an apply step with Torque tags applied to the environment.
+- To import the environment using the API, make the following POST request using `curl`.
+- The API response will include the `environment-id`. After importing, you will see an import step, followed by an apply step with tags applied to the environment.
```bash
curl -X POST "https://portal.qtorque.io/api/spaces/{space_name}/environments/import_using_blueprint" \
@@ -102,7 +102,7 @@ This guide walks you through the process of importing an existing environment in
```
### Important Considerations
-- **Destroying Resources**: If you are importing a resource that already exists in the cloud, keep in mind that ending the environment in Torque will destroy the resource.
+- **Destroying Resources**: If you are importing a resource that already exists in the cloud, keep in mind that ending the environment in will destroy the resource.
- To avoid unintended deletion, you can release the environment by running the following API command using `curl`:
```bash
@@ -148,9 +148,9 @@ To import Terraform states from another account that cannot be accessed directly
---
:::info
-1. Make sure to provide the Torque authentication token. This can be a short or long-token
-2. The source section points to the blueprint generated and the repository name onboarded to Torque.
+1. Make sure to provide the authentication token. This can be a short or long-token
+2. The source section points to the blueprint generated and the repository name onboarded to .
3. The backend section added in under the grain should point to the state file exported and uploaded to the backend of choice.
:::
-By following these steps, you'll be able to successfully import and manage an environment in Torque while ensuring security and state management.
+By following these steps, you'll be able to successfully import and manage an environment in while ensuring security and state management.
diff --git a/docs/governance/approval-channels.md b/docs/governance/approval-channels.md
index f3dafc15b..87b37fb33 100644
--- a/docs/governance/approval-channels.md
+++ b/docs/governance/approval-channels.md
@@ -3,11 +3,11 @@ sidebar_position: 10
title: Approval Channels
---
-Torque role: Account admin
+ role: Account admin
While organizations typically want to enable their users to launch environments quickly and easily, in certain situations it may be necessary to put guardrails in place to ensure compliance with security policies or budget constraints. Defining an approval flow can provide an effective way to balance the need for agility and control.
-Torque's Approval channels define the users who can approve environment launch requests. An approval channel is basically a list of users. Currently, Torque supports 3 approval channels - Teams, Emails, and ServiceNow.
+'s Approval channels define the users who can approve environment launch requests. An approval channel is basically a list of users. Currently, supports 3 approval channels - Teams, Emails, and ServiceNow.
__To create an approval channel:__
1. Go to __Administration > Approval Channels__.
diff --git a/docs/governance/audit-log/audit-log-configuration.md b/docs/governance/audit-log/audit-log-configuration.md
index 078ba4dc0..54d90974d 100644
--- a/docs/governance/audit-log/audit-log-configuration.md
+++ b/docs/governance/audit-log/audit-log-configuration.md
@@ -9,7 +9,7 @@ title: Audit Log Configuration
## Configuration
1. Navigate to __Configuration > Audit Log__, and click __Add Audit Target__.
2. Select one of the options:
- - __Torque Audit__: Forward logs to Torque, and retain for 18 months.
+ - __Torque Audit__: Forward logs to , and retain for 18 months.
- __ElasticSearch__: With built-in Elastic Stack integration, you can forward audit data for real-time analysis and reporting.
3. When selecting ElasticSearch, please fill in the details:
> 
@@ -23,4 +23,4 @@ title: Audit Log Configuration
6. Go to __Management > Stack Management > Index Patterns__ and create a "quali" index pattern.
> 
- Congratulations! Audit Log is configured and collecting Torque events.
\ No newline at end of file
+ Congratulations! Audit Log is configured and collecting events.
\ No newline at end of file
diff --git a/docs/governance/audit-log/audit-log-overview.md b/docs/governance/audit-log/audit-log-overview.md
index c7e4ea2fa..92a2e49a6 100644
--- a/docs/governance/audit-log/audit-log-overview.md
+++ b/docs/governance/audit-log/audit-log-overview.md
@@ -3,7 +3,7 @@ sidebar_position: 2
title: Audit Log Overview
---
-Torque provides integration with Elastic Stack, allowing you to easily monitor and audit your system users' behavior, investigate and remove security risks and vulnerabilities, and more. Once integrated, Torque begins capturing events and streams them to Elastic Stack for analytic data, allowing you to gain visibility into key platform events within your account, identify the most active policies, significant changes in resource operations, or filter actions by user and space.
+ provides integration with Elastic Stack, allowing you to easily monitor and audit your system users' behavior, investigate and remove security risks and vulnerabilities, and more. Once integrated, begins capturing events and streams them to Elastic Stack for analytic data, allowing you to gain visibility into key platform events within your account, identify the most active policies, significant changes in resource operations, or filter actions by user and space.
```jsx title=
inputs:
diff --git a/docs/governance/audit-log/audit-log-usage.md b/docs/governance/audit-log/audit-log-usage.md
index 3cd6ce001..c0538f74c 100644
--- a/docs/governance/audit-log/audit-log-usage.md
+++ b/docs/governance/audit-log/audit-log-usage.md
@@ -3,11 +3,11 @@ sidebar_position: 5
title: Audit Log Event Structure and Contents
---
-Torque audit data is presented in json format. It includes events and with the following information:
+ audit data is presented in json format. It includes events and with the following information:
* Timestamp (UTC)
* Event Type
* Event Name
- * Actor (User/Automation/Torque)
+ * Actor (User/Automation/)
* Scope (Account/Space/Environment)
* Result (Success/Failure)
* Error (in case of failure)
diff --git a/docs/governance/audit-log/events.md b/docs/governance/audit-log/events.md
index 6489cc6dd..6d0aac308 100644
--- a/docs/governance/audit-log/events.md
+++ b/docs/governance/audit-log/events.md
@@ -16,8 +16,8 @@ These events are captured by Audit Log. All events are of type "string".
|Event |Description|Scopes |Data (parameters) |
|------------------------|---------------------------|-----------------------------------|--------------------------------------------|
-|Add approval channel | New approval channel was added to Torque's __Approval Channels__ administration page.. | |- Name - Type|
-|Delete approval channel | Approval channel was deleted from Torque's __Approval Channels__ administration page. | |- Name - Type|
+|Add approval channel | New approval channel was added to 's __Approval Channels__ administration page.. | |- Name - Type|
+|Delete approval channel | Approval channel was deleted from 's __Approval Channels__ administration page. | |- Name - Type|
|Policy auto approved | Policy was approved automatically by OPA. | Account/Space |- Name - Type|
|Update approval channel | Approval channel's settings were updated, like description or approvers list. | |- Approval type (auto/manual) - Approval status (approved/denied) - Entity type - Entity name - Action (Launch/Extend) - Policy path + name - Approver Email (if approval type is manual) - Notes (if exist)|
@@ -70,7 +70,7 @@ These events are captured by Audit Log. All events are of type "string".
|Termination Completed|Environment's termination completed.|Account/Space/Environment||
|Force Terminate|Environment was force terminated immediately.|Account/Space/Environment||
|Owner changed|Environment's owner was changed.|Account/Space/Environment|- New owner|
-|Updates Detected|Torque detected a change in the asset files in the repository.|Account/Space/Environment|- Grain|
+|Updates Detected| detected a change in the asset files in the repository.|Account/Space/Environment|- Grain|
|Update Started|Environment's update was initiated by the user to update the environment with the latest changes to the asset files.|Account/Space/Environment|- Grain|
|Update Complete|Environment was updated.|Account/Space/Environment|- Grain|
|Update Dismissed|User dismissed updates to the asset files, choosing to leave their environment as is.|Account/Space/Environment|- Grain|
@@ -82,7 +82,7 @@ These events are captured by Audit Log. All events are of type "string".
|Added to Space|Added an agent to a space.|Account/Space|- Host name - Cloud - Type (Docker, K8s), Space|
|Created|Created a new agent.|Account|- Host name - Cloud - Type (Docker, K8s)|
|Connected|Agent was successfully connected to the cluster.|Account|- host_name - Type (Docker, K8s)|
-|Deleted|Agent was deleted from Torque.|Account|- Host name - Cloud - Type (Docker, K8s)|
+|Deleted|Agent was deleted from .|Account|- Host name - Cloud - Type (Docker, K8s)|
|Removed From Space|Agent was removed from a space.|Account/Space|- Host name - Cloud - Type (Docker, K8s), Space|
|Renamed| Agent's name was changed.|Account|-old_host_name - new_host_name - type|
@@ -91,7 +91,7 @@ These events are captured by Audit Log. All events are of type "string".
|Event |Description|Scopes |Data (parameters) |
|------------------------|---------------------|-----------------------------------|--------------------------------------------|
|Added|New notification target was created.|Account, Space|- Name - Target|
-|Deleted|Notification target was deleted from Torque.|Account/Space|- Old Name - New Name - Old Target type - New Target type|
+|Deleted|Notification target was deleted from .|Account/Space|- Old Name - New Name - Old Target type - New Target type|
|Enabled Toggled|Notifications were enabled for a notification target.|Account/Space|- Name - Old enabled - New enabled|
|Modified|Notification target was modified (name, enabled notifications, etc.|Account/Space|- Name|
@@ -107,13 +107,13 @@ These events are captured by Audit Log. All events are of type "string".
|Event |Description|Scopes |Data (parameters) |
|------------------------|-------------------------|-----------------------------------|--------------------------------------------|
-|Deleted|Policy was deleted from Torque.|Account|- Name - approvalChannel - overridable - manualInitiation|
+|Deleted|Policy was deleted from .|Account|- Name - approvalChannel - overridable - manualInitiation|
|Disabled| Policy was disabled. |Account|- policyName - enabledValue|
|Duplicated | A copy of an existing policy was created. |Account|- policyName - existingPolicyName - isCustom - spaceNames|
|Enabled | Policy was enabled. |Account|- policyName - enabledValue|
|Imported| Policy was imported from a connected policy repository. |Account|- policyName|
|Modified| Policy's settings were modified. |Account|- policyName|
-|Synchronized| The version of a custom policy in Torque was synced with the policy version in the repository.|Account|- policyName|
+|Synchronized| The version of a custom policy in was synced with the policy version in the repository.|Account|- policyName|
## Repository
@@ -129,9 +129,9 @@ These events are captured by Audit Log. All events are of type "string".
|Event |Description|Scopes |Data (parameters) |
|------------------------|-----------------------------------|--------------------------------------------|--|
-|Create|New space was created in Torque.|Account/Space||
+|Create|New space was created in .|Account/Space||
|Modify|Space's settings were modified (name, icon, banner color).|Account/Space|- oldProperties (name, color, icon) - newProperties (name, color, icon)|
-|Delete|Space was deleted from Torque.|Account/Space||
+|Delete|Space was deleted from .|Account/Space||
## Tag
@@ -147,12 +147,12 @@ These events are captured by Audit Log. All events are of type "string".
|Event |Description|Scopes |Data (parameters) |
|------------------------|-----------------------------------|--------------------------------------------|--|
-|Invited|User was invited to join Torque (Torque invitation email).|Account|- User Email|
-|Invitation Cancelled|Torque invitation was cancelled by an admin.|Account|- User Email - User Role - Space|
-|Sign up|New user signed up to Torque.|Account|- User Email|
+|Invited|User was invited to join ( invitation email).|Account|- User Email|
+|Invitation Cancelled| invitation was cancelled by an admin.|Account|- User Email - User Role - Space|
+|Sign up|New user signed up to .|Account|- User Email|
|User Account Role Updated|User's account role was changed (or attached - for new users).|Account|- User Email - oldRole - newRole|
-|Deleted|User was deleted from Torque.|Account|- User Email|
-|Login|User logged into Torque.|Account|- User Email|
+|Deleted|User was deleted from .|Account|- User Email|
+|Login|User logged into .|Account|- User Email|
|Reset Password|User's password was reset.|Account|- User Email|
|User Added to Space|User was added to a space.|Account/Space|- User Email - reason - space name - given space role|
|User Space Role Updated|User's space role was changed (space admin/dev/member).|Account|- User Email - oldRole - newRole|
@@ -162,7 +162,7 @@ These events are captured by Audit Log. All events are of type "string".
|Event |Description|Scopes |Data (parameters) |
|------------------------|-----------------------------------|--------------------------------------------|--|
|Created| Created a new workflow.|Account |- Name|
-|Deleted| Deleted a workflow from Torque.|Account |- Name|
+|Deleted| Deleted a workflow from .|Account |- Name|
|Disabled| Disabled a workflow.|Account |- Name|
|Enabled| Enabled a workflow.|Account |- Name|
|Ended|Workflow's execution ended at the completion of all its actions. |Account/Environment |- Name - Actor (User/Schedule) -If the actor is User, user details (email) is displayed|
diff --git a/docs/governance/cost-tracking/configuring-cost-aws.md b/docs/governance/cost-tracking/configuring-cost-aws.md
index b2253e29b..f6b9a53a8 100644
--- a/docs/governance/cost-tracking/configuring-cost-aws.md
+++ b/docs/governance/cost-tracking/configuring-cost-aws.md
@@ -7,7 +7,7 @@ title: Configuring Cost for AWS
1. Ensure your IAM user that has full access to billing data (including adding cost allocation tags). For details, see this official AWS help page: [IAM tutorial: Delegate access to the billing console](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_billing.html?icmpid=docs_iam_console#tutorial-billing-step1).
2. Configure cost allocation tags in your AWS account. See the next section [AWS Cost setup](#aws-cost-setup).
-3. Create a role to be used by Torque to gather the cost information and obtain the following information :
+3. Create a role to be used by to gather the cost information and obtain the following information :
* __External Id__
* __Role ARN__
@@ -15,8 +15,8 @@ title: Configuring Cost for AWS
#### __AWS Cost setup:__
-To configure Torque’s Cost Allocation Tags:
- 1. Launch a sandbox via Torque OR add tags called __torque-account-id__ and __torque-environment-id__ to any resource in your AWS account.
+To configure ’s Cost Allocation Tags:
+ 1. Launch a sandbox via OR add tags called __torque-account-id__ and __torque-environment-id__ to any resource in your AWS account.
2. Login to your AWS management console and in the top toolbar, select __Services__.
3. Search for __Billing__ and select it from the result list.
4. Select __Cost Allocation Tags__.
@@ -34,7 +34,7 @@ To configure Torque’s Cost Allocation Tags:
3. In the navigation pane of the IAM console, select __Roles__, and then click __Create Role__.
1. From __Select trusted entity__, choose __AWS Account__.
- 2. Under An AWS account ID, select __An AWS account__ and enter 349148204654. (This is the Torque AWS account # where we will query the cost from).
+ 2. Under An AWS account ID, select __An AWS account__ and enter 349148204654. (This is the AWS account # where we will query the cost from).
3. Select __Require external ID__.
4. Enter an __External ID__ of your choosing. The External Id will be used to validate the Consumer of the ARN Role. __Keep note of the external ID as you will need it later in the configuration step__.
5. In __Next:Permissions__, select the policy you have just created in step 1 for cost exploration permission.
@@ -67,7 +67,7 @@ To configure Torque’s Cost Allocation Tags:
## Troubleshooting
-What can be done if you don't see cost in Torque's cost dashboard?
+What can be done if you don't see cost in 's cost dashboard?
1. Cost collection happens only once a day and takes time. Make sure at least *48 hours passed* since you configured cost and you have environments running during that time frame.
2. Choose one of the environments that should have cost associated with them in your AWS cloud, and do the following:
@@ -75,7 +75,7 @@ What can be done if you don't see cost in Torque's cost dashboard?
> 
2. In your AWS console, navigate to the billing service (e.g. https://us-east-1.console.aws.amazon.com/billing/home?region=us-east-1#/) and on the left panel select __Cost Expolorer > Daily Spend View__.
3. On the __Filters__ panel on the right, select __Tag__ and search for __torque-environment-id__.
- 4. Click on the __>__ sign and select the environment id that you found via the Torque URL.
+ 4. Click on the __>__ sign and select the environment id that you found via the URL.
5. If the environment id doesn't have cost associated with it, it means that the cost allocation tags are not configured correctly. Review [AWS Cost setup](#aws-cost-setup) again.
6. If you see costs associated with this tag, test your credentials: navigate to __Administration > Cloud Accounts > Cost Collection Target > Choose your cloud > In the three dot menu click on validate__.
diff --git a/docs/governance/cost-tracking/configuring-cost-azure.md b/docs/governance/cost-tracking/configuring-cost-azure.md
index 9d70b82cd..bdf995297 100644
--- a/docs/governance/cost-tracking/configuring-cost-azure.md
+++ b/docs/governance/cost-tracking/configuring-cost-azure.md
@@ -8,7 +8,7 @@ title: Configuring Cost for Azure
1. Create an application and register it in Azure AD. To do so, navigate to "App Registrations" and click on __New Registration__. Follow the steps (no need to provide redirect URl, just the name will do). Take a note of the __Tenant Id__ and __Application Id__ as they will be needed later in the process.
2. Click on __Add a Certificate or Secret --> New client secret__ --> __Add__, and take a note of the created __Value__ (it will be used later in the application secret configuration)
3. Assign the __Cost Management Reader__ (or, __Cost Management Contributor__) Role to the application:
- 1. Navigate to __Subscriptions__ and click on the subscription where you would like Torque to collect the cost
+ 1. Navigate to __Subscriptions__ and click on the subscription where you would like to collect the cost
2. On the left side panel select __Access control (IAM)__
3. Click the __Role assignments__ tab
4. Click __Add__ > __Add role assignment__. If you don't have permissions to assign roles, the Add role assignment option will be disabled, in this case contact your Azure administrator for help.
diff --git a/docs/governance/cost-tracking/configuring-cost-gcp.md b/docs/governance/cost-tracking/configuring-cost-gcp.md
index a2d237808..d116d2207 100644
--- a/docs/governance/cost-tracking/configuring-cost-gcp.md
+++ b/docs/governance/cost-tracking/configuring-cost-gcp.md
@@ -11,7 +11,7 @@ title: Configuring Cost for GCP
* `BigQuery Data Viewer`
* `BigQuery Job User`
* `Billing Account Viewer`
-4. Download the service account key in JSON format. This will be used in Torque.
+4. Download the service account key in JSON format. This will be used in .
## Configuration Steps
@@ -46,9 +46,9 @@ title: Configuring Cost for GCP
3. Select **JSON** and click **Create**.
4. Save the JSON file securely.
-### Step 3: Configure Torque
+### Step 3: Configure
-1. Go to **Administration > Cloud Accounts > Cost Collection Target** in Torque.
+1. Go to **Administration > Cloud Accounts > Cost Collection Target** in .
2. Click **Add Cost Collection Target**.
3. Select **GCP**.
4. Specify the following details:
@@ -72,12 +72,12 @@ import pic1 from '/img/gcp-cost-target.png';
## Troubleshooting
-What can be done if you don't see cost in Torque's cost dashboard?
+What can be done if you don't see cost in 's cost dashboard?
1. Ensure that cost data is being exported to the BigQuery table. Check the table in the GCP Console to verify data is present.
2. Validate the service account permissions:
* Ensure the service account has access to the BigQuery dataset and table.
* Verify the service account has the `Billing Account Viewer` role.
-3. Test your credentials in Torque:
+3. Test your credentials in :
* Navigate to **Administration > Cloud Accounts > Cost Collection Target > Choose your cloud > In the three-dot menu, click on Validate**.
4. If issues persist, review the configuration steps above and correct any errors.
diff --git a/docs/governance/cost-tracking/configuring-cost-k8s.md b/docs/governance/cost-tracking/configuring-cost-k8s.md
index 58d346750..76127a211 100644
--- a/docs/governance/cost-tracking/configuring-cost-k8s.md
+++ b/docs/governance/cost-tracking/configuring-cost-k8s.md
@@ -4,12 +4,12 @@ title: Configuring Cost for K8s
---
-Torque collects cost data using cost collection targets, which are managed in the __Administration__ page's __Cloud Accounts__ tab. For AWS and Azure clouds, you must first add a cost collection target, however for K8s, Torque automatically creates a cost collection target when an agent is installed on the cluster.
+ collects cost data using cost collection targets, which are managed in the __Administration__ page's __Cloud Accounts__ tab. For AWS and Azure clouds, you must first add a cost collection target, however for K8s, automatically creates a cost collection target when an agent is installed on the cluster.
Follow the next steps to start collecting cost on your K8s cluster:
1. Install Kubecost:
- 1. Torque collects cost data directly from the pods using a 3rd-party tool called Kubecost. To start collecting costs from your cluster, deploy Kubecost in your cluster.
+ 1. collects cost data directly from the pods using a 3rd-party tool called Kubecost. To start collecting costs from your cluster, deploy Kubecost in your cluster.
* For deployment instructions, see: https://www.kubecost.com/install.html#show-instructions
* Make sure the kubecost default namespace is used (Namespace kubecost)
2. Validate the relevant cost collection target:
@@ -26,5 +26,5 @@ Follow the next steps to start collecting cost on your K8s cluster:
1. Verify that Kubecost is deployed in the cluster.
1. Navigate your browser to http://localhost:9090/. If you can see kubecost data, it means it's working. If you can't, see [this guide](https://docs.kubecost.com/troubleshooting/troubleshoot-install) for help.
-2. In Torque, try to re-enable the K8S cost collection target and validate that it works.
-3. If the error still exists, contact Torque support.
+2. In , try to re-enable the K8S cost collection target and validate that it works.
+3. If the error still exists, contact support.
diff --git a/docs/governance/cost-tracking/cost.md b/docs/governance/cost-tracking/cost.md
index b0b0a7280..2ff3a1b85 100644
--- a/docs/governance/cost-tracking/cost.md
+++ b/docs/governance/cost-tracking/cost.md
@@ -3,7 +3,7 @@ sidebar_position: 9
title: Cost
---
-Torque's __Cost__ dashboard provides you with actionable insights into the costs of your environments. Cost data is collected using the __torque-environment-id__ and __torque-account-id__ tags which are assigned (with a unique value) to every new environment's resources. To learn more about Torque tagging, see [Tags](/governance/tags).
+'s __Cost__ dashboard provides you with actionable insights into the costs of your environments. Cost data is collected using the __torque-environment-id__ and __torque-account-id__ tags which are assigned (with a unique value) to every new environment's resources. To learn more about tagging, see [Tags](/governance/tags).
> 
@@ -13,7 +13,7 @@ With the cost dashboard, you can understand your business activities cost:
* Group by application (blueprint) , Space (team), manual/automation, and by specific environment.
-[Read more about Torque reports](/reports/reports-overview)
+[Read more about reports](/reports/reports-overview)
## Supported cloud providers
@@ -24,5 +24,5 @@ With the cost dashboard, you can understand your business activities cost:
:::note __Note__
-Torque calls your cloud provider's API to query the cost. This operation might incur additional charges from your cloud provider.
+ calls your cloud provider's API to query the cost. This operation might incur additional charges from your cloud provider.
:::
diff --git a/docs/governance/custom-roles.md b/docs/governance/custom-roles.md
index 2c7c1abdc..6560003d7 100644
--- a/docs/governance/custom-roles.md
+++ b/docs/governance/custom-roles.md
@@ -1,6 +1,6 @@
---
title: Custom Roles
-description: How to define and use custom roles in Torque for advanced governance and access control.
+description: How to define and use custom roles in for advanced governance and access control.
sidebar_position: 4
---
diff --git a/docs/governance/policies.md b/docs/governance/policies.md
index f6a1b5dd9..5ec9bca9a 100644
--- a/docs/governance/policies.md
+++ b/docs/governance/policies.md
@@ -3,15 +3,15 @@ sidebar_position: 12
title: Policies
---
-Torque role: Account admin
+ role: Account admin
## Why use policies?
Using policies for the consumption of environments offers a multitude of benefits that empower organizations to optimize their cloud usage. Firstly, policies allow for effective cost control by setting limits on resource consumption, ensuring that cloud spending remains within budgetary constraints. Moreover, these policies enable the efficient management of resources by capping the number of concurrent resources per user, preventing resource sprawl, and ensuring fair allocation. Additionally, policies can restrict the duration of an environments uptime, enhancing security and minimizing the risk of unused resources running indefinitely. In sum, the implementation of policies for environment consumption not only fosters financial prudence but also enhances resource governance and security, making it an invaluable asset in the realm of cloud management.
-Torque policies are triggered as part of the environment deployment pipeline for specific environment lifecycle events (launch, extend environment for example) or during the deployment of environments (e.g. when evaluating a Terraform module included in the environment). Torque policies are powered by OPA (Open Policy Agent). For a step-by-step tutorial, see [Video: Torque policies (end-to-end)](#video-torque-policies-end-to-end-tutorial).
+ policies are triggered as part of the environment deployment pipeline for specific environment lifecycle events (launch, extend environment for example) or during the deployment of environments (e.g. when evaluating a Terraform module included in the environment). policies are powered by OPA (Open Policy Agent). For a step-by-step tutorial, see [Video: policies (end-to-end)](#video-torque-policies-end-to-end-tutorial).
## Example Use Cases
-You can use Torque policies for cost and consumption control. Examples include:
+You can use policies for cost and consumption control. Examples include:
- Limiting the maximal duration of environments
- Limiting the concurrent number of environments per user
- Limiting the total cost of environments
@@ -22,10 +22,10 @@ You can use Torque policies for cost and consumption control. Examples include:
- [Example Use Cases](#example-use-cases)
- [How policies work](#how-policies-work)
- [Policy labels](#policy-labels)
-- [Torque built-in policies](#torque-built-in-policies)
+- [ built-in policies](#torque-built-in-policies)
- [Custom policies](#custom-policies)
- [Developing your own policies](#developing-your-own-policies)
- - [__Developing Torque policies__](#developing-torque-policies)
+ - [__Developing policies__](#developing-torque-policies)
- [__Inputs__](#inputs)
- [__data__](#data)
- [__Rego restricted functions__](#rego-restricted-functions)
@@ -33,13 +33,13 @@ You can use Torque policies for cost and consumption control. Examples include:
- [How to set up a policy](#how-to-set-up-a-policy)
- [Duplicate a policy](#duplicate-a-policy)
- [Updating policies](#updating-policies)
-- [Video: Torque policies (end-to-end tutorial)](#video-torque-policies-end-to-end-tutorial)
+- [Video: policies (end-to-end tutorial)](#video-torque-policies-end-to-end-tutorial)
## How policies work
-Policies are based on two basic elements: trigger and context. Trigger determines when the policy is activated, and context is the data the policy needs to get ("input" in OPA terms). The context is provided automatically by Torque. Users can also define user data ("data" in OPA terms) in the Torque policy. The context (or input) is the actual environment data the end user is trying to deploy, and the user data sets values to the limitations imposed by the admin who set up the policy.
+Policies are based on two basic elements: trigger and context. Trigger determines when the policy is activated, and context is the data the policy needs to get ("input" in OPA terms). The context is provided automatically by . Users can also define user data ("data" in OPA terms) in the policy. The context (or input) is the actual environment data the end user is trying to deploy, and the user data sets values to the limitations imposed by the admin who set up the policy.
-Torque supports 3 types of triggers, which are defined by the package being used in the policy's .rego file:
+ supports 3 types of triggers, which are defined by the package being used in the policy's .rego file:
- Consumption policies (triggered on catalog launch). To define a consumption policy, the ".rego" file must use the package name __torque.consumption__
- Environment lifecycle policies (triggered on launch after completing the launch dialog, or extend). To define an environment lifecycle policy, the ".rego" file must use the package name __torque.environment__
- Terraform evaluation policies (triggered on terraform plan for terraform grains). To define a terraform plan evaluation policy, the ".rego" file must use the package name __torque.terraform_plan__
@@ -49,10 +49,10 @@ Policies are applied on the space or account level, as explained in [How to set
:::
## Policy labels
-There are 5 labels that will be automatically applied to policies in Torque, in the __Policies__ administration page:
+There are 5 labels that will be automatically applied to policies in , in the __Policies__ administration page:
-* __Built-in__ label is assigned to policies that come out of the box with Torque. For details about the policies, see [https://github.com/QualiTorque/opa](https://github.com/QualiTorque/opa)
-* __Terraform__ label is assigned to policies that evaluate the Terraform plan on the environment's Terraform grain. These policies are triggered when Torque deploys the Terraform grain's plan during the environment's initialization
+* __Built-in__ label is assigned to policies that come out of the box with . For details about the policies, see [https://github.com/QualiTorque/opa](https://github.com/QualiTorque/opa)
+* __Terraform__ label is assigned to policies that evaluate the Terraform plan on the environment's Terraform grain. These policies are triggered when deploys the Terraform grain's plan during the environment's initialization
* __Environment__ label is assigned to policies that are triggered when the environment is launched (upon completing the launch wizard) or extended
* __Consumption__ label is assigned to policies that are triggered when the catalog item is clicked
* __Approval__ label is assigned to policies that could require approval to launch the environment
@@ -60,21 +60,21 @@ There are 5 labels that will be automatically applied to policies in Torque, in
> 
-## Torque built-in policies
-Torque provides many built-in policies, both for environment lifecycle and Terraform plan evaluation, which represent some of the more common use cases when deploying environments. Some examples include:
+## built-in policies
+ provides many built-in policies, both for environment lifecycle and Terraform plan evaluation, which represent some of the more common use cases when deploying environments. Some examples include:
* Allow only specific AWS instance types to be used
* Allow deploying only to specific Azure locations
* Allow only environments with an expected cost of < 10$
## Custom policies
-There may come a time when you will need to go beyond the common use case and write your own policies and rules. This is possible using custom policies. Custom policies are .rego files that reside in your git repository. When you add the policy repository to Torque, Torque automatically discovers the repository and identifies its .rego files as policies, allowing you to choose which policies to import into Torque. Same as with built-in policies, you select where to apply the policy (on the entire account or specific teams) and configure the relevant data.
+There may come a time when you will need to go beyond the common use case and write your own policies and rules. This is possible using custom policies. Custom policies are .rego files that reside in your git repository. When you add the policy repository to , automatically discovers the repository and identifies its .rego files as policies, allowing you to choose which policies to import into . Same as with built-in policies, you select where to apply the policy (on the entire account or specific teams) and configure the relevant data.
### Developing your own policies
-#### __Developing Torque policies__
+#### __Developing policies__
-1. __Package__: For Torque to recognize and be able to execute your policy, you need to use the torque packages. The packages that are currently available are torque.consumption, torque.environment and torque.terraform_plan. So your first line of the rego file which is the package name should be one of these packages.
+1. __Package__: For to recognize and be able to execute your policy, you need to use the torque packages. The packages that are currently available are torque.consumption, torque.environment and torque.terraform_plan. So your first line of the rego file which is the package name should be one of these packages.
2. __terraform_plan__ policies need at least one __deny__ rule to be valid.
For example, a __terraform_plan__ policy can look like this:
@@ -102,7 +102,7 @@ For example, an __environment__ policy can look like this:
#### __Inputs__
-Based on the policy type (__environment__ , __consumption__ or __terraform_plan__) Torque will provide *input* to OPA once the policy is injected.
+Based on the policy type (__environment__ , __consumption__ or __terraform_plan__) will provide *input* to OPA once the policy is injected.
For terraform_plan policies, the input is the terraform plan output.
For __environment__ policies, the input is the following json object:
@@ -222,7 +222,7 @@ For __consumption__ policies, the input is similar to the object in __environmen
#### __data__
-The *data* object is the user-defined inputs that will also be passed to OPA for evaluation. The data object structure is defined by the policy writer, and the values are provided through the Torque UI.
+The *data* object is the user-defined inputs that will also be passed to OPA for evaluation. The data object structure is defined by the policy writer, and the values are provided through the UI.
For example, the policy can look like this:
@@ -234,7 +234,7 @@ result = { "decision": "Denied", "reason": "Environment duration exceeds the con
In this case, the policy expects a data object with one key: ```max_duration_minutes```.
-In Torque, it would look like this:
+In , it would look like this:
> 
@@ -242,7 +242,7 @@ So you can enter whichever value you want as the maximum duration to be enforced
#### __Rego restricted functions__
-Torque supports all rego built-in functions, except the following list:
+ supports all rego built-in functions, except the following list:
- "http.send";
- "opa.runtime";
- "rego.parse_module";
@@ -253,13 +253,13 @@ Torque supports all rego built-in functions, except the following list:
For more details on how to develop policies, see [OPA documentation](https://www.openpolicyagent.org/docs/latest/) and [OPA playground](https://play.openpolicyagent.org/).
:::tip Notes
-* For example, custom policies, see [Quali Torque built-in OPA policy templates](https://github.com/QualiTorque/opa).
-* Note that Torque points to a specific commit. Therefore, to introduce a new version of a custom policy, develop, test and pass the policy through your regular git flow. Once you are done, update the commit version in Torque by clicking "Update Rego".
+* For example, custom policies, see [Quali built-in OPA policy templates](https://github.com/QualiTorque/opa).
+* Note that points to a specific commit. Therefore, to introduce a new version of a custom policy, develop, test and pass the policy through your regular git flow. Once you are done, update the commit version in by clicking "Update Rego".
:::
## Approval policies
-Torque allows you to configure your policy with conditions that will trigger manual approval of an environment request by a set of designated approvers via multiple optional channels: email, Microsoft Teams or Slack channels, ServiceNow and more.
+ allows you to configure your policy with conditions that will trigger manual approval of an environment request by a set of designated approvers via multiple optional channels: email, Microsoft Teams or Slack channels, ServiceNow and more.
For example, you could have an approval policy that sets the max_duration for environments at 3 hours, so attempting to launch an environment with a duration that is longer than 3 hours will require approval.
@@ -277,7 +277,7 @@ Approvers are defined in the __[Approval Channels](/governance/approval-channels
A green checkmark next to the repository's URL indicates that the repository has been added successfully.
> 
4. Click __Discover Policies__.
-5. Select the policies you want to import into Torque and click __Generate Policies__.
+5. Select the policies you want to import into and click __Generate Policies__.
> 
The policies are displayed in the __Policies__ page.
@@ -301,7 +301,7 @@ You can also duplicate any built-in or custom policy to create a similar version
## Updating policies
-Torque's custom policies are version controlled in git. Next to each policy, you can see the specific commit which is currently being used for that policy across the account:
+'s custom policies are version controlled in git. Next to each policy, you can see the specific commit which is currently being used for that policy across the account:
> 
From time to time, there will be a need to modify the policy's code (rego file). However, we must update the policy without any disruption to the users. This means that the data object format and the rego file must match.
@@ -309,10 +309,10 @@ From time to time, there will be a need to modify the policy's code (rego file).
Clicking on the policy there is an option to update the rego:
> 
-If there is no change in the data object format, the update is completed and applied across the account. However, if there is a change in the data object, we cannot complete the update until the user will complete the change of the data object, otherwise the policy will start failing and will cause a disruption for the account users. Therefore, when Torque detects a change in the format of the data object, it will load the new data object structure and wait for the user to modify it.
+If there is no change in the data object format, the update is completed and applied across the account. However, if there is a change in the data object, we cannot complete the update until the user will complete the change of the data object, otherwise the policy will start failing and will cause a disruption for the account users. Therefore, when detects a change in the format of the data object, it will load the new data object structure and wait for the user to modify it.
Once done, the user needs to invoke the "update-rego" again and at this point it will complete successfully as the rego code and the data format match.
-## Video: Torque policies (end-to-end tutorial)
+## Video: policies (end-to-end tutorial)