variable-ize platform product name [#168015936]

Author: pspinrad

bosh-release.html.md.erb

@@ -6,7 +6,7 @@ owner: Services
 <strong><%= modified_date %></strong>
 
 This topic provides resources for creating a BOSH release that integrates a
-software service with Pivotal Cloud Foundry (PCF) at the managed service level.
+software service with <%= vars.product_name %> at the managed service level.
 
 ## <a id="overview"></a> Overview
 
@@ -18,7 +18,7 @@ manifest containing configuration and deployment properties.
 
 The BOSH manifest specifies the following major components:
 
-- **Packages** that can be installed on PCF stemcells to create VM
+- **Packages** that can be installed on <%= vars.product_name %> stemcells to create VM
 images
 
 - **Jobs** that describe how to install, run, and remove your software
@@ -58,17 +58,17 @@ These topics explain how to create a BOSH release:
 If you have already packaged your service as Docker images, you can emulate
 a managed service deployment using the [Tile Generator](tile-generator.html)'s
 support for `docker-bosh` packages. This feature lets you deploy pre-existing
-Docker images into BOSH-managed VMs on the PCF infrastructure.
+Docker images into BOSH-managed VMs on the <%= vars.product_name %> infrastructure.
 
-While this is a great, easy way to deploy your service on PCF, we do not
+While this is a great, easy way to deploy your service on <%= vars.product_name %>, we do not
 recommend this as a long-term, production-ready solution. There is really no
 benefit of running your service in containers on the VMs, and it does have
 a number of operational ("day 2") drawbacks:
 
 - You introduce more software (Docker) which needs to be kept up-to-date, and
 has the potential for issues, downtime, and security vulnerabilities.
 
-- You can no longer take advantage of the patching capabilities of PCF for
+- You can no longer take advantage of the patching capabilities of <%= vars.product_name %> for
 stemcells and application dependencies, such as frameworks and libraries. Instead,
 you become directly responsible for managing all software that is in the Docker
 images you deploy.

brokered.html.md.erb

@@ -5,32 +5,32 @@ owner: Services
 
 <strong><%= modified_date %></strong>
 
-The topics in this subsection explain how to integrate your software service with Pivotal Cloud Foundry (PCF) to create a brokered service and service tile for PCF.
+The topics in this subsection explain how to integrate your software service with <%= vars.product_name %> to create a brokered service and service tile for <%= vars.product_name %>.
 
 ## <a id="overview"></a> Overview
 
-You can achieve the first real improvement in your PCF customers user experience by creating a [Service Broker](service-brokers.html) for your service.
+You can achieve the first real improvement in your <%= vars.product_name %> customers user experience by creating a [Service Broker](service-brokers.html) for your service.
 
-A brokered service runs external to PCF, but it has a tile on [Pivotal Network](http://network.pivotal.io) (PivNet). Operators install, configure, and upgrade the tile through the Ops Manager Installation Dashboard.
+A brokered service runs external to <%= vars.product_name %>, but it has a tile on [Pivotal Network](http://network.pivotal.io) (PivNet). Operators install, configure, and upgrade the tile through the Ops Manager Installation Dashboard.
 
 The service broker eliminates the need for your customers to know the URLs and
 credentials for your services; they are managed automatically by the
 broker.
 
 Building a broker for a (still) externally deployed service is generally
-a good way to publish a first tile that adds real value for customers who have both your software and PCF.
+a good way to publish a first tile that adds real value for customers who have both your software and <%= vars.product_name %>.
 
 ## <a id="create"></a> Create a Brokered Service
 
 * A brokered service requires a service broker, which publishes an API to the Cloud Controller.  
 [Service Brokers](./service-brokers.html) explains how to create one. 
 
-* [Route Services](./service-brokers.html#route) explains how to create a route service, for use in the routing layer of PCF rather than by hosted PCF apps.
+* [Route Services](./service-brokers.html#route) explains how to create a route service, for use in the routing layer of <%= vars.product_name %> rather than by hosted <%= vars.product_name %> apps.
 
 * [Catalog](./service-brokers.html#catalog) explains how to design the part of your service broker API that publishes service plan information to the Services Marketplace.
 
 * You can write your service broker in the language of your choice.  
-[Buildpacks](./buildpacks.html) explains how to create a language-specific buildpack that compiles and packages your service broker to run on PCF.
+[Buildpacks](./buildpacks.html) explains how to create a language-specific buildpack that compiles and packages your service broker to run on <%= vars.product_name %>.
 
 * Once you have the individual components for your brokered service integration, you can work through  [Building Your First Tile](./index.html#tile-steps) to create your tile.
 

buildpacks.html.md.erb

@@ -5,7 +5,7 @@ owner: Services
 
 <strong><%= modified_date %></strong>
 
-Buildpacks compile and package apps to run on Pivotal Cloud Foundry (PCF). This topic lists resources for using and deploying buildpacks with PCF apps, and for creating your own custom buildpack.
+Buildpacks compile and package apps to run on <%= vars.product_name %>. This topic lists resources for using and deploying buildpacks with <%= vars.product_name %> apps, and for creating your own custom buildpack.
 
 ## <a id="language"></a> Official Buildpacks
 
@@ -30,7 +30,7 @@ Buildpacks compile and package apps to run on Pivotal Cloud Foundry (PCF). This
 Buildpacks can also be used to inject additional code into the application container. 
 For more information, see the following:
 
-- The PCF documentation topic [Creating Custom Buildpacks](https://docs.pivotal.io/pivotalcf/buildpacks/custom.html)
+- The <%= vars.product_name %> documentation topic [Creating Custom Buildpacks](https://docs.pivotal.io/pivotalcf/buildpacks/custom.html)
 
 - The github repo [Eureka Registrar Sidecar](https://github.com/cf-platform-eng/eureka-registrar-sidecar)
 

cf-concepts.html.md.erb

@@ -7,46 +7,46 @@ owner: Services
 
 <strong><%= modified_date %></strong>
 
-There are many ways to integrate services with Pivotal Cloud Foundry (PCF). The right one for each service depends on what the service does, and how
+There are many ways to integrate services with <%= vars.product_name %>. The right one for each service depends on what the service does, and how
 customer applications consume it. To determine the best way to integrate your
-service, you'll need a good understanding of PCF concepts like applications, containers, services, brokers, and buildpacks.
+service, you'll need a good understanding of <%= vars.product_name %> concepts like applications, containers, services, brokers, and buildpacks.
 
 This page provides a collection of links to documentation for the most relevant
 concepts. If you prefer to learn through guided training,
 [ask us](mailto:[email protected]) about available training options.
 
 ## <a id="overview"></a>General Overview
 
-For general overview of PCF, and the various ways to interact with it,
+For general overview of <%= vars.product_name %>, and the various ways to interact with it,
 use the following links:
 
-- [Cloud Foundry Subsystems](http://docs.pivotal.io/pivotalcf/concepts/overview.html) provides high-level descriptions of internal functions performed by different PCF components.
-- [Cloud Foundry Command Line Interface (cf CLI)](http://docs.pivotal.io/pivotalcf/cf-cli/index.html) links to topics that explain how to direct PCF deployment from your local command line.
+- [Cloud Foundry Subsystems](http://docs.pivotal.io/pivotalcf/concepts/overview.html) provides high-level descriptions of internal functions performed by different <%= vars.product_name %> components.
+- [Cloud Foundry Command Line Interface (cf CLI)](http://docs.pivotal.io/pivotalcf/cf-cli/index.html) links to topics that explain how to direct <%= vars.product_name %> deployment from your local command line.
 - [Pivotal Ops Manager](http://docs.pivotal.io/pivotalcf/customizing/pcf-interface.html) describes the Ops Manager and Installation Dashboard interfaces, where cloud operators see, install, configure, and deploy service tiles.
 - [Pivotal Apps Manager](http://docs.pivotal.io/pivotalcf/console/index.html) describes the Apps Manager interface, where app developers create and configure service instances and bind them to their apps.
 
 ## <a id="applications"></a> Applications
 
 Cloud Foundry is primarily a cloud native application platform. To understand how to integrate your services with Cloud Foundry, you should understand how your customers are using the platform to develop, deploy, and operate their applications.
 
-- [Developer Guide](http://docs.pivotal.io/pivotalcf/devguide/index.html) explains how to push an app to run on PCF and enable it to use services.
-- [Logging and Monitoring](http://docs.pivotal.io/pivotalcf/loggregator/index.html) describes how PCF aggregates and streams logs and metrics from the apps it hosts and from internal system components.
+- [Developer Guide](http://docs.pivotal.io/pivotalcf/devguide/index.html) explains how to push an app to run on <%= vars.product_name %> and enable it to use services.
+- [Logging and Monitoring](http://docs.pivotal.io/pivotalcf/loggregator/index.html) describes how <%= vars.product_name %> aggregates and streams logs and metrics from the apps it hosts and from internal system components.
 
 ## <a id="services"></a> Services
 
 Most value-add integrations are done by exposing your software to customer applications as services. To understand the service concepts, and what a service integration looks like, read the following documentation:
 
 - [Services Overview](http://docs.pivotal.io/pivotalcf/devguide/services/index.html) explains how developers provision and use existing services in their apps.
-- [Cloud Foundry Service Brokers and PCF Tiles](http://docs.pivotal.io/on-demand-service-broker/about.html#cf-broker) briefly describes the two main elements of PCF service integration: the service broker API, which connects the service to PCF internally by taking commands from the Cloud Controller; and the tile, a packaged interface that cloud operators use to install and configure a service within PCF.
-- [Custom Services](http://docs.pivotal.io/pivotalcf/services/index.html) explains how service authors package their service as a [Managed Service](./managed.html) that is available for use by PCF operators and developers, and which runs locally on PCF rather than running remotely.
+- [Cloud Foundry Service Brokers and <%= vars.product_name %> Tiles](http://docs.pivotal.io/on-demand-service-broker/about.html#cf-broker) briefly describes the two main elements of <%= vars.product_name %> service integration: the service broker API, which connects the service to <%= vars.product_name %> internally by taking commands from the Cloud Controller; and the tile, a packaged interface that cloud operators use to install and configure a service within <%= vars.product_name %>.
+- [Custom Services](http://docs.pivotal.io/pivotalcf/services/index.html) explains how service authors package their service as a [Managed Service](./managed.html) that is available for use by <%= vars.product_name %> operators and developers, and which runs locally on <%= vars.product_name %> rather than running remotely.
 
 ## <a id="buildpacks"></a> Buildpacks
 
 When application code is deployed to Cloud Foundry, it is processed by a language-specific buildpack. Language buildpacks provide a convenient integration hook for any service that needs to inspect or embellish application code. 
 Supplying buildpacks also provides a language-agnostic way to inject your code into the application container image.
 
-- [Application Staging Process](http://docs.pivotal.io/pivotalcf/concepts/how-applications-are-staged.html) explains how PCF packages and deploys apps in containers with buildpacks so that they can run on multiple VMs interchangeably.
-- [Language Buildpacks](http://docs.pivotal.io/pivotalcf/buildpacks/index.html) describes the language-specific buildpacks support PCF apps.
+- [Application Staging Process](http://docs.pivotal.io/pivotalcf/concepts/how-applications-are-staged.html) explains how <%= vars.product_name %> packages and deploys apps in containers with buildpacks so that they can run on multiple VMs interchangeably.
+- [Language Buildpacks](http://docs.pivotal.io/pivotalcf/buildpacks/index.html) describes the language-specific buildpacks support <%= vars.product_name %> apps.
 - [Custom Buildpacks](https://docs.pivotal.io/pivotalcf/buildpacks/custom.html) describes how to use supply buildpacks to add dependencies or code without having to change (multiple) language-sepcific buildpacks.
 
 ## <a id="agents"></a> Embedded Agents

concourse.html.md.erb

@@ -20,10 +20,10 @@ There are two ways to do CI testing on your tile:
 ## <a id="dashboard"></a>Use Tile Dashboard CI to Test Your Tile
 
 With your tile in our Tile Dashboard CI testing system, we all win.
-You stay on top of changes to PCF that may require changes in your tile.
-Our field representatives gain a clear understanding of your tile’s compatibility across PCF versions,
+You stay on top of changes to <%= vars.product_name %> that may require changes in your tile.
+Our field representatives gain a clear understanding of your tile’s compatibility across <%= vars.product_name %> versions,
 underlying IaaS, and different flavors of environments.
-This also relieves you from maintaining your own CI system, keeping up with latest PCF versions, etc.
+This also relieves you from maintaining your own CI system, keeping up with latest <%= vars.product_name %> versions, etc.
 
 The Tile Dashboard CI is part of our Enterprise Readiness criteria
 which is used to inform the field of the quality and capabilities of your tile,
@@ -42,7 +42,7 @@ The Tile Dashboard CI runs your tile through a series of steps, which include:
   - Use of properties whose values/meanings have changed.
   - Use of features that are no longer supported.
 
-3. Configuring, installing, testing, and uninstalling your tile in several PCF environments:
+3. Configuring, installing, testing, and uninstalling your tile in several <%= vars.product_name %> environments:
   - A patch release of every supported Pivotal Application Service minor version.
   - Every supported IaaS
   - Environments with extra configuration, such as multiple availability zones and IPsec
@@ -232,7 +232,7 @@ contact us on [Pivotal Partners Slack](https://pivotalpartners.slack.com/).
 
 ### <a id="backing"></a> About Backing Services
 
-Your tile might require a backing service outside of the existing PCF environment,
+Your tile might require a backing service outside of the existing <%= vars.product_name %> environment,
 for example, your tile might be a service broker to a SaaS offering.
 
 You are responsible for maintaining the backing service in an environment
@@ -245,7 +245,7 @@ uses the CI tool [Concourse](http://concourse.ci/) to make sure that partner pro
 to work with every new release of the platform.
 
 With more effort, you can also follow the pointers below to set up your own Concourse CI pipeline
-that integrates and tests your tile on your own deployment of the latest PCF.
+that integrates and tests your tile on your own deployment of the latest <%= vars.product_name %>.
 
 While you are of course also free to use any other CI system you are familiar with,
 Pivotal's tools and documentation are built to make Concourse CI as easy as possible.
@@ -266,22 +266,22 @@ see the instructions [Concourse: Setup & Operations](https://concourse-ci.org/se
 A typical CI pipeline for a tile consists of the following jobs:
 
 - Build the tile
-- Deploy it to PCF
+- Deploy it to <%= vars.product_name %>
 - Run a set of deployment tests to verify that it deployed and works correctly
-- Remove it from PCF
+- Remove it from <%= vars.product_name %>
 
 You describe this pipeline in a `pipeline.yml` file that is then uploaded to the
 Concourse server. [Tile Generator](tile-generator.html) contains a sample
 pipeline that you can clone for your own tile. We are working on automating
 the process of generating a pipeline template for you.
 
-### <a id="pool"></a> Set Up PCF for Your CI Pipeline
+### <a id="pool"></a> Set Up <%= vars.product_name %> for Your CI Pipeline
 
-Pivotal partners who have us host their pipeline have access to a pool of PCF
+Pivotal partners who have us host their pipeline have access to a pool of <%= vars.product_name %>
 instances that are managed by us and are regularly updated with the latest
-(pre-)release versions of PCF. If you set up your own concourse server, you
-have to target your pipeline at a [PCF instance you have setup](./environments.html).
+(pre-)release versions of <%= vars.product_name %>. If you set up your own concourse server, you
+have to target your pipeline at a [<%= vars.product_name %> instance you have setup](./environments.html).
 
 Concourse has a resource type to manage a pool of resources that are shared
-between pipelines, which is what we use to serialize PCF access between the
+between pipelines, which is what we use to serialize <%= vars.product_name %> access between the
 partner pipelines that run on our concourse server.

credhub.html.md.erb

@@ -16,9 +16,9 @@ Both BOSH CredHub and runtime CredHub are instances of the CredHub credential ma
 
 Many <%= vars.product_name %> components use credentials to authenticate connections, and <%= vars.product_name %>  installations often have hundreds of active credentials. Secure credential management is essential to prevent data and security breaches.
 
-In Pivotal Cloud Foundry (PCF) v1.11.0, CredHub runs on the BOSH VM, alongside the BOSH Director and UAA. Ops Manager v1.11 stores its credentials in CredHub,
+In <%= vars.product_name %> v1.11.0, CredHub runs on the BOSH VM, alongside the BOSH Director and UAA. Ops Manager v1.11 stores its credentials in CredHub,
 and users can retrieve them using the CredHub API or the **Credentials** tab of the BOSH Director tile.
-Tile developers can embed CredHub calls in [manifest snippets](#snippets) and PCF apps can retrieve credentials using the CredHub API.
+Tile developers can embed CredHub calls in [manifest snippets](#snippets) and <%= vars.product_name %> apps can retrieve credentials using the CredHub API.
 
 See [Fetching Variable Names and Values](./get-credhub-vars.html) for how to fetch variable names and values using the CredHub API.
 
@@ -72,17 +72,17 @@ Tile developers can embed CredHub in product template and job template manifest
       password: ((( credhub-password )))
 ```
 
-## <a id="limitations"></a> PCF v1.11.0 Limitations
+## <a id="limitations"></a> <%= vars.product_name %> Limitations
 
-PCF v1.11.0 supports CredHub for credential storage, but it does not support the following:
+<%= vars.product_name %> supports CredHub for credential storage, but it does not support the following:
 
-* Automatic backup and restore for CredHub, along with other PCF system components.
+* Automatic backup and restore for CredHub, along with other <%= vars.product_name %> system components.
 
 * Automatic tile [upgrades](./tile-upgrades.html) that migrate all types of credentials defined in [property blueprints](./property-template-references.html#property-blueprints) in previous tile versions, to storage in CredHub.
 
 * Using CredHub to generate new credentials.
 
-Tile authors may choose to wait until PCF supports some or all of these features before incorporating CredHub into their service.
+Tile authors may choose to wait until <%= vars.product_name %> supports some or all of these features before incorporating CredHub into their service.
 
 ## <a id="resources"></a> CredHub Resources