cloudify-cosmo · oloten · Feb 22, 2023 · Feb 22, 2023 · May 30, 2023 · Jun 1, 2023
diff --git a/content/about/_index.md b/content/about/_index.md
@@ -1,6 +1,6 @@
 ---
-title: About Cloudify
-description: Cloudify is an open-source cloud orchestration framework. which enables you to model applications and services and automate their entire life cycle
+title: Overview
+description: This product provides an open-source cloud orchestration framework enabling you to model applications and services, and automate their entire life cycle.
 canonical: xxx.yyy
 weight: 10
 alwaysopen: false

diff --git a/content/about/what-is-cloudify.md → content/about/introduction.md b/content/about/what-is-cloudify.md → content/about/introduction.md
@@ -1,9 +1,9 @@
 ---
-title: What Is Cloudify?
+title: Introduction
 category: Introduction
 draft: false
 weight: 100
-aliases: /intro/what-is-cloudify/
+aliases: /intro/introduction/
 ---
 
 {{< param product_name >}} is an open-source multi-cloud and edge orchestration platform.

diff --git a/content/about/cloudify-manager.md → content/about/manager-overview.md b/content/about/cloudify-manager.md → content/about/manager-overview.md
@@ -1,5 +1,5 @@
 ---
-title: Cloudify Manager
+title: Manager Overview
 category: Introduction
 draft: false
 weight: 200
@@ -28,6 +28,6 @@ In addition, the {{< param cfy_manager_name >}}:
 * Retains a history of metrics and events
 * Manages agents running on an application's host machines
 
-Although you can use Cloudify to provision resources directly from the CLI, use Cloudify Manager to manage production-level applications.
+Although you can use {{< param product_name >}} to provision resources directly from the CLI, use {{< param cfy_manager_name >}} to manage production-level applications.
 
-For more information about Cloudify Manager, see the Cloudify Manager section later in this user's guide.
+For more information about {{< param cfy_manager_name >}}, see the {{< param cfy_manager_name >}} section later in this user's guide.
diff --git a/content/developer/apis/_index.md b/content/developer/apis/_index.md
@@ -1,6 +1,6 @@
 ---
-title: Cloudify APIs
-description: Working with Cloudify APIs
+title: APIs
+description: Working with APIs
 weight: 80
 alwaysopen: false
 ---

diff --git a/content/developer/blueprints/built-in-types.md b/content/developer/blueprints/built-in-types.md
@@ -16,7 +16,7 @@ The following `node_types` are basic types from which concrete types with specif
         * `cloudify.interfaces.validation`: An interface for pre-creation and pre-deletion validation operations. These can be called by using the [*execute_operation*]({{< relref "working_with/workflows/built-in-workflows.md#the-execute-operation-workflow" >}}) built-in workflow or by a [custom workflow]({{< relref "working_with/workflows/creating-your-own-workflow.md" >}}).
         * `cloudify.interfaces.monitoring`: An interface for monitoring configuration. Operations of this interface are called from the [built-in]({{< relref "working_with/workflows/built-in-workflows.md" >}}) [*install*]({{< relref "working_with/workflows/built-in-workflows.md#the-install-workflow" >}}) and [*uninstall*]({{< relref "working_with/workflows/built-in-workflows.md#the-uninstall-workflow" >}}) workflows.
     * These are the properties, also inherited by all `cloudify.nodes.Root` children:
-        * `use_external_resource` - Indicate whether the resource exists or if Cloudify should create the resource, true if you are bringing an existing resource, false if you want cloudify to create it; Boolean, false by default.  In case this property is true, any properties marked as required will not be mandatory.
+        * `use_external_resource` - Indicate whether the resource exists or if {{< param product_name >}} should create the resource, true if you are bringing an existing resource, false if you want {{< param product_name >}} to create it; Boolean, false by default.  In case this property is true, any properties marked as required will not be mandatory.
         * `resource_id` - Property which identifies the external resource, used if the `use_external_resource` is true, not required.
 
 

diff --git a/content/developer/blueprints/how-to-scale-blueprint.md b/content/developer/blueprints/how-to-scale-blueprint.md
@@ -9,7 +9,7 @@ aliases: /blueprints/how-to-scale-blueprint/
 We will now build, from scratch, a simple system which is capable of scaling on AWS. 
 Our system will consist of a number of instances under a single load balancer.
 
-We start out by importing the tosca definitions file and corresponding cloudify types definitions file.
+We start out by importing the tosca definitions file and corresponding {{< param product_name >}} types definitions file.
 
 {{< highlight  yaml >}}
 tosca_definitions_version: cloudify_dsl_1_3

diff --git a/content/developer/blueprints/spec-deployment-settings.md b/content/developer/blueprints/spec-deployment-settings.md
@@ -7,7 +7,7 @@ aliases: /blueprints/spec-deployment-settings/
 ---
 
 Deployment Settings are additional settings and instructions provided to
-Cloudify manager on how to handle a deployment created out of this blueprint.
+{{< param product_name >}} manager on how to handle a deployment created out of this blueprint.
 
 # Declaration
 

diff --git a/content/developer/blueprints/spec-imports.md b/content/developer/blueprints/spec-imports.md
@@ -84,8 +84,8 @@ you're in luck. You can perform a _plugins update_.
 You can find more information on the CLI command [here](/cli/orch_cli/plugins/#update).
 
 # Namespace
-You can import any resource and add a namespace context to all included Cloudify DSL elements, with
-the exception of adding namespace to Cloudify basic types.
+You can import any resource and add a namespace context to all included {{< param product_name >}} DSL elements, with
+the exception of adding namespace to {{< param product_name >}} basic types.
 
 Import command with a namespace format is `namespace--RESOURCE`.
 

diff --git a/content/developer/blueprints/spec-node-types.md b/content/developer/blueprints/spec-node-types.md
@@ -68,7 +68,7 @@ default     | no       | \<any\>     | An optional default value for the propert
 required    | no       | boolean     | Specifies whether the property is required. (Default: `true`, Supported since: [cloudify_dsl_1_2]({{< relref "developer/blueprints/spec-versioning.md" >}}))
 
 {{% note title="Built-in Node Types" %}}
-Cloudify provides some built-in node types, which you can find out about [here]({{< relref "developer/blueprints/built-in-types.md" >}}).
+{{< param product_name >}} provides some built-in node types, which you can find out about [here]({{< relref "developer/blueprints/built-in-types.md" >}}).
 {{% /note %}}
 # Examples
 

diff --git a/content/developer/blueprints/spec-plugins.md b/content/developer/blueprints/spec-plugins.md
@@ -189,7 +189,7 @@ plugins:
     properties_description: |
       Description regarding the credentials and
       the link to AWS documentation how to generate
-      or the link to cloudify documentation on
+      or the link to {{< param product_name >}} documentation on
       different types of authentication methods
     properties:
       aws_access_key_id:

diff --git a/content/developer/blueprints/spec-relationships.md b/content/developer/blueprints/spec-relationships.md
@@ -6,7 +6,7 @@ weight: 700
 aliases: /blueprints/spec-relationships/
 ---
 
-`relationships` in Cloudify are DSL elements that establish dependencies between [node templates](../spec-node-templates), but also can be used to perform operations (i.e. execute code).  Relationships are declared in a relationships section in a node template declaration at the same level as properties and interfaces, and are often defined in [plugins](../spec-plugins).  A node template can contain any number of relationship declarations, within certain constraints noted below.  Each relationship declaration refers to two node templates in a blueprint: the source and the target.  The source node is implicit; it is the node template that the relationship is declared in.  The target is explicit, and refered to by node id.  Example:
+`relationships` in {{< param product_name >}} are DSL elements that establish dependencies between [node templates](../spec-node-templates), but also can be used to perform operations (i.e. execute code).  Relationships are declared in a relationships section in a node template declaration at the same level as properties and interfaces, and are often defined in [plugins](../spec-plugins).  A node template can contain any number of relationship declarations, within certain constraints noted below.  Each relationship declaration refers to two node templates in a blueprint: the source and the target.  The source node is implicit; it is the node template that the relationship is declared in.  The target is explicit, and refered to by node id.  Example:
 
 ```yaml
   node1: 
@@ -21,7 +21,7 @@ aliases: /blueprints/spec-relationships/
     ....
 ```
 
-Relationships in Cloudify are explicit; a blueprint that contains no relationships will operate on all contained nodes simultaneously, regardless whether the node templates refer to each other via [intrinsic functions](../spec-intrinsic-functions).  The fundamental relationship type in Cloudify is called `cloudify.relationships.depends_on`.  It (and other relationships derived from it) is used by built-in workflows such as [install](/working_with/workflows/built-in-workflows#the-install-workflow) for ordering of node instance evaluation, and in some cases executing code.
+Relationships in {{< param product_name >}} are explicit; a blueprint that contains no relationships will operate on all contained nodes simultaneously, regardless whether the node templates refer to each other via [intrinsic functions](../spec-intrinsic-functions).  The fundamental relationship type in {{< param product_name >}} is called `cloudify.relationships.depends_on`.  It (and other relationships derived from it) is used by built-in workflows such as [install](/working_with/workflows/built-in-workflows#the-install-workflow) for ordering of node instance evaluation, and in some cases executing code.
 
 Relationships are declared in individual node templates, and have a type and a target. If node `A` declares a `depends_on` relationship to node `B`, this conveys a sense of order to the built-in workflows.  In the case of the `install` workflow, it means ‘process node B before node A’.  In the case of the `uninstall` workflow it means ‘process node A before node B’.  
 
@@ -59,7 +59,7 @@ By default, nodes can be related using the relationship types described below. Y
 
 ## Fundamental Built-in Relationships
 
-There are three fundamental relationships defined by Cloudify, which underlie all other relationship types, including those defined in plugins or blueprint authors.  The base/root relationship type is `cloudify.relationships.depends_on`, which indicates processing order to the built-in workflows.    All relationships, even custom relationships, must ultimately derive from the depends_on relationship. Derived from this relationship are `cloudify.relationships.connected_to`, and `cloudify.relationships.contained_in`.
+There are three fundamental relationships defined by {{< param product_name >}}, which underlie all other relationship types, including those defined in plugins or blueprint authors.  The base/root relationship type is `cloudify.relationships.depends_on`, which indicates processing order to the built-in workflows.    All relationships, even custom relationships, must ultimately derive from the depends_on relationship. Derived from this relationship are `cloudify.relationships.connected_to`, and `cloudify.relationships.contained_in`.
 
 ![Basic Relationships](/images/blueprint/basic_rels.png)
 
@@ -237,8 +237,8 @@ please visit [SharedResource]({{< relref "working_with/service_composition/share
 As an extension of `cloudify.relationships.depends_on` relationship type, this can only target a node of
 SharedResource type. This relationship will allow running any workflow (custom or not) ,which is defined
 in the target node's deployment, as a part from establish and unlink relationship lifecycle operations.
-Also if the SharedResource node has been created with different Cloudify client connection, those settings
-will be taken from the node properties if exists else it will use default Cloudify client.
+Also if the SharedResource node has been created with different {{< param product_name >}} client connection, those settings
+will be taken from the node properties if exists else it will use default {{< param product_name >}} client.
 
 #### Relationship settings:
 
@@ -281,8 +281,8 @@ As an extension of `cloudify.relationships.connected_to` relationship type, this
 type of SharedResource. This relationship will allow running any workflow (custom or not) ,which is defined
 in the target node's deployment, as a part from establish and unlink relationship lifecycle.
 With support for scaling the relationship according to `cloudify.relationships.connected_to` features.
-Also if the SharedResource node has been created with different Cloudify client connection, those settings
-will be taken from the node properties if exists else it will use default Cloudify client.
+Also if the SharedResource node has been created with different {{< param product_name >}} client connection, those settings
+will be taken from the node properties if exists else it will use default {{< param product_name >}} client.
 
 #### Relationship settings:
 

diff --git a/content/developer/blueprints/spec-versioning.md b/content/developer/blueprints/spec-versioning.md
@@ -15,7 +15,7 @@ The currently defined versions are
 
 <br>
 
-| Cloudify Manager Version | DSL 1.3 | DSL 1.4 |
+| {{< param cfy_manager_name >}} Version | DSL 1.3 | DSL 1.4 |
 |--------------------------|---------|---------|
 | 5.1 and higher           | V       | V       |
 | 6.4 and higher           |         | V       |

diff --git a/content/developer/cfy_lint.md b/content/developer/cfy_lint.md
@@ -1,16 +1,16 @@
 +++
 title = "CFY-Lint CLI"
-description = "A Cloudify blueprint linter for identifying and fixing stylistic and syntactical DSL issues."
+description = "A blueprint linter for identifying and fixing stylistic and syntactical DSL issues."
 weight = 80
 alwaysopen = false
 +++
 
 ## About CFY-Lint
 
-CFY-Lint is a command line tool that can identify and fix stylistic and syntactical issues in Cloudify blueprints, for example:
+CFY-Lint is a command line tool that can identify and fix stylistic and syntactical issues in {{< param product_name >}} blueprints, for example:
 
  - YAML stylistic conventions
- - Cloudify DSL conventions
+ - {{< param product_name >}} DSL conventions
  - Deprecated node types and relationship types
  - Unimported node types and relationship types
  - Node and relationship dependencies
@@ -50,7 +50,7 @@ Options:
 -b, --blueprint-path
 ```
 
-Provide the relative or absolute path to a Cloudify DSL file, such as a blueprint or a plugin YAML.
+Provide the relative or absolute path to a {{< param product_name >}} DSL file, such as a blueprint or a plugin YAML.
 
 __NOTE:__ The `CWD` must be the same directory as the file, if you want to use relative imports to other YAML files.
 

diff --git a/content/developer/writing_plugins/_index.md b/content/developer/writing_plugins/_index.md
@@ -1,6 +1,6 @@
 ---
 title: Writing Plugins
-description: How to write and package plugins for Cloudify
+description: How to write and package plugins
 weight: 30
 alwaysopen: false
 ---
@@ -31,7 +31,7 @@ for more information, see:
 
 {{< param product_name >}} distributes plugins in [Wagon](https://github.com/cloudify-cosmo/wagon/blob/master/README.md) format. Wagon packages are a sets of Python [Wheels](https://packaging.python.org/tutorials/distributing-packages/#wheels) for dependency management. {{< param product_name >}} publishes official wagons, which are found on [plugins download page](http://cloudify.co/plugins).
 
-_Note: The [Script plugin]({{< relref "working_with/official_plugins/Configuration/script.md" >}}) is distributed with Cloudify._
+_Note: The [Script plugin]({{< relref "working_with/official_plugins/Configuration/script.md" >}}) is distributed with {{< param product_name >}}._
 
 
 # Plugin Installation

diff --git a/content/developer/writing_plugins/container-support.md b/content/developer/writing_plugins/container-support.md
@@ -1,5 +1,5 @@
 ---
-title: A Guide To Cloudify Container Support For Kubernetes And Docker
+title: A Guide To Container Support For Kubernetes And Docker
 category: Writing Plugins
 draft: false
 weight: 1450

diff --git a/content/developer/writing_plugins/how-to-work-with-cm.md b/content/developer/writing_plugins/how-to-work-with-cm.md
@@ -1,5 +1,5 @@
 ---
-title: Integrating Cloudify with Configuration Management Tools
+title: Integrating Configuration Management Tools
 category: Writing Plugins
 draft: false
 weight: 3000

diff --git a/content/developer/writing_plugins/plugins-common.html b/content/developer/writing_plugins/plugins-common.html
@@ -3,7 +3,7 @@
 title: Plugins Common API Reference
 category: Writing Plugins
 draft: false
-abstract: Plugins Common API Documentation for the Cloudify Manager
+abstract: Plugins Common API Documentation for the Manager
 weight: 200
 aliases: /apis/plugins-common/
 ---

diff --git a/content/developer/writing_widgets/_index.md b/content/developer/writing_widgets/_index.md
@@ -1,6 +1,6 @@
 ---
 title: Writing Widgets
-description: How to customize the Cloudify Console by writing your own widgets
+description: How to customize the Console by writing your own widgets
 weight: 60
 alwaysopen: false
 aliases: ["/manager_webui/custom-widgets/", "/developer/custom_console/", "/developer/custom_console/custom-widgets/"]

diff --git a/content/developer/writing_widgets/development-methods.md b/content/developer/writing_widgets/development-methods.md
@@ -1,7 +1,7 @@
 ---
 title: Widget Development Methods
 description: Different development methods available for widget creation.
-category: Cloudify Console
+category: Console
 draft: false
 weight: 100
 ---

diff --git a/content/developer/writing_widgets/useful-links.md b/content/developer/writing_widgets/useful-links.md
@@ -1,7 +1,7 @@
 ---
 title: Useful Links
 description: Resources helpful during widget development.
-category: Cloudify Console
+category: Console
 draft: false
 weight: 900
 ---

diff --git a/content/developer/writing_widgets/widget-apis.md b/content/developer/writing_widgets/widget-apis.md
@@ -1,7 +1,7 @@
 ---
 title: Widget APIs
 description: Description of APIs exposed for widget development.
-category: Cloudify Console
+category: Console
 draft: false
 weight: 400
 ---

diff --git a/content/developer/writing_widgets/widget-backend.md b/content/developer/writing_widgets/widget-backend.md
@@ -1,7 +1,7 @@
 ---
 title: Widget Backend
 description: Description of Widget Backend feature.
-category: Cloudify Console
+category: Console
 draft: false
 weight: 500
 ---

diff --git a/content/developer/writing_widgets/widget-definition.md b/content/developer/writing_widgets/widget-definition.md
@@ -1,7 +1,7 @@
 ---
 title: Widget Definition
 description: Description of widget definition including all available configuration parameters.
-category: Cloudify Console
+category: Console
 draft: false
 weight: 300
 api_link: "https://docs.cloudify.co/api/v3.1"

diff --git a/content/developer/writing_widgets/widget-structure.md b/content/developer/writing_widgets/widget-structure.md
@@ -1,7 +1,7 @@
 ---
 title: Widget Structure
 description: Description of widget definition and directory structure.
-category: Cloudify Console
+category: Console
 draft: false
 weight: 200
 ---

diff --git a/content/developer/writing_widgets/widgets-components.md b/content/developer/writing_widgets/widgets-components.md
@@ -1,7 +1,7 @@
 ---
 title: Widget Components Reference
-description: Documentation for all ReactJS components developed by Cloudify team.
-category: Cloudify Console
+description: Documentation for all ReactJS components.
+category: Console
 draft: false
 weight: 700
 aliases: ["/apis/widgets-components/", "/developer/custom_console/widgets-components/"]