rebranding [#171728965]

Author: seviet

get-credhub-vars.html.md.erb

@@ -3,9 +3,7 @@ title: Fetching Variable Names and Values
 owner: CredHub
 ---
 
-<strong><%= modified_date %></strong>
-
-## Overview
+## <a id="overview"></a> Overview
 
 CredHub has two API endpoints to identify and re-use variables. Operators who want to see all the credentials associated with their product, or support engineers who want to troubleshoot issues specific to one virtual machine (VM), can use these APIs for those purposes.
 
@@ -14,11 +12,11 @@ The API endpoints perform these functions:
 * Identifying and printing the name of a variable
 * Using the name of the variable to identify and print the value of the variable
 
-### Using the API Endpoints
+### <a id="use-api-endpoints"></a> Using the API Endpoints
 
 Use these endpoints to view variables for any product in Ops Manager, except the BOSH Director. These endpoints are read-only. You cannot use them to add, remove, or rotate variables.
 
-## Fetching Variables
+## <a id="fetch-variables"></a> Fetching Variables
 
 This endpoint returns the list of variables associated with a product that are stored in CredHub. Not all variables are stored in CredHub. If you call a variable that is not stored in CredHub, the call returns an empty value.
 
@@ -28,7 +26,7 @@ $ curl "http<span>s</span>://OPS-MAN-FQDN/api/v0/deployed/products/product-guid/
     -H "Authorization: Bearer EXAMPLE_UAA_ACCESS_TOKEN"
 </pre>
 
-### Example Response
+### <a id="example-response"></a> Example Response
 
 <pre class="terminal">
 HTTP/1.1 200 OK
@@ -38,7 +36,7 @@ HTTP/1.1 200 OK
 }
 </pre>
 
-### Query Parameters
+### <a id="query-params"></a> Query Parameters
 
 <table class="nice">
 	<th>Parameter</th>
@@ -51,7 +49,7 @@ HTTP/1.1 200 OK
 
 This endpoint returns a variable's name. Use the name in the next endpoint to return the variable's value.
 
-## Fetching Variable Values
+## <a id="fetch-var-values"></a> Fetching Variable Values
 
 This endpoint returns the value of a variable stored in CredHub. Not all variables are stored in CredHub, so if you call a variable that isn't in CredHub, the call will return an empty value.
 
@@ -61,7 +59,7 @@ $ curl "http<span>s</span>://OPS-MAN-FQDN/api/v0/deployed/products/product-guid/
     -H "Authorization: Bearer UAA_ACCESS_TOKEN"
 </pre>
 
-### Example Response 
+### <a id="example-response"></a> Example Response 
 
 <pre class="terminal">
 HTTP/1.1 200 OK
@@ -71,7 +69,7 @@ HTTP/1.1 200 OK
 }
 </pre>
 
-### Query Parameters
+### <a id="query-params-values"></a> Query Parameters
 <table>
 	<th>Parameter</th>
 	<th>Description</th>

nozzle.html.md.erb

@@ -4,13 +4,13 @@ owner: Services
 ---
 
 
-This topic explains how to integrate <%= vars.platform_name %> services with Cloud Foundry's logging system, _Loggregator_, by writing to and reading from its _Firehose_ endpoint.
+This topic explains how to integrate services with Cloud Foundry's logging system, _Loggregator_, by writing to and reading from its _Firehose_ endpoint.
 
 ## <a id="overview"></a> Overview
 
-Cloud Foundry's Loggregator logging system collects logs and metrics from <%= vars.platform_name %> apps and platform components and streams them to a single endpoint, Firehose. Your tile can integrate its service with Loggregator in two ways:
+Cloud Foundry's Loggregator logging system collects logs and metrics from apps and platform components and streams them to a single endpoint, Firehose. Your tile can integrate its service with Loggregator in two ways:
 
-* By sending your service component logs and metrics to the Firehose, to be streamed along with <%= vars.platform_name %> core platform component logs and metrics
+* By sending your service component logs and metrics to the Firehose, to be streamed along with core platform component logs and metrics
 
 * By installing a _nozzle_ on Firehose that directs Firehose data to be consumed by external services or apps -- a built-in nozzle can enable a service to:
   - Drain metrics to an external dashboard product for system operators
@@ -22,9 +22,9 @@ For a real world production example of a nozzle see [Firehose-to-syslog](https:/
 
 ## <a id="firehose"></a> Firehose Communication
 
-<%= vars.platform_name %> components publish logs and metrics to the Firehose through Loggregator agent processes that run locally on the component VMs. Loggregator agents input the data to the Loggregator system through a co-located Loggregator agent. To see how logs and metrics travel from <%= vars.platform_name %> system components to the Firehose, see the [Cloud Foundry documentation](https://docs.cloudfoundry.org/loggregator/architecture.html).
+<%= vars.app_runtime_full %> components publish logs and metrics to the Firehose through Loggregator agent processes that run locally on the component VMs. Loggregator agents input the data to the Loggregator system through a co-located Loggregator agent. To see how logs and metrics travel from <%= vars.app_runtime_abbr %> system components to the Firehose, see the [Cloud Foundry documentation](https://docs.cloudfoundry.org/loggregator/architecture.html).
 
-Component VMs running <%= vars.platform_name %> services can publish logs and metrics the same way, by including the same component, Loggregator Agent. Historically, components used Metron for this communication.
+Component VMs running <%= vars.app_runtime_abbr %> services can publish logs and metrics the same way, by including the same component, Loggregator Agent. Historically, components used Metron for this communication.
 
 ### <a id="https"></a> HTTPS Protocol
 
@@ -79,11 +79,11 @@ Do so with the following properties:
 ## <a id="nozzle"></a> Nozzles
 
 A nozzle is a component dedicated to reading and processing data that streams from Firehose.
-A service tile can install a nozzle as either a managed service, with package type `bosh-release`, or as an app pushed to Pivotal Application Service (PAS), with the package type `app`.
+A service tile can install a nozzle as either a managed service, with package type `bosh-release`, or as an app pushed to <%= vars.app_runtime_abbr %>, with the package type `app`.
 
 ### <a id="develop"></a> Develop a Nozzle
 
-Pivotal recommends developing a nozzle in Go to leverage the
+<%= vars.company_name %> recommends developing a nozzle in Go to leverage the
 [NOAA library](https://github.com/cloudfoundry/noaa).
 NOAA does the heavy lifting of establishing
 an authenticated websocket connection to the logging system
@@ -163,7 +163,7 @@ Once you have built a nozzle, you can deploy it as a managed service or as an ap
 Visit [managed service](managed.html) for more details on what it means to be a
 managed service. See also this [example nozzle BOSH release](https://github.com/cloudfoundry-incubator/example-nozzle-release).
 
-You can also deploy the nozzle as an app on PAS. Visit the Tile Generator's
+You can also deploy the nozzle as an app on <%= vars.app_runtime_abbr %>. Visit the Tile Generator's
 [section on pushed apps](tile-generator.html#pushed-applications)
 for more details.
 
@@ -192,22 +192,22 @@ for the access control list (ACL) app name, space UUID and name, and org UUID an
  packages this nozzle as a BOSH release.
 
 * [splunk-firehose-nozzle](https://github.com/cf-platform-eng/splunk-firehose-nozzle)
-has source code based on `firehose-to-syslog` and is packaged to run an app on <%= vars.platform_name %>.
+has source code based on `firehose-to-syslog` and is packaged to run an app on <%= vars.app_runtime_abbr %>.
 
 * [datadog-firehose-nozzle](https://github.com/DataDog/datadog-firehose-nozzle) is
 another real world implementation.
 
-## <a id="syslog-format-pcf"></a> Log Format for <%= vars.platform_name %> Components
+## <a id="syslog-format-pcf"></a> Log Format for <%= vars.app_runtime_abbr %> Components
 
-Pivotal's standard log format adheres to the [RFC-5424 syslog protocol](https://tools.ietf.org/html/rfc5424), with log messages formatted as follows:
+The standard log format for <%= vars.app_runtime_abbr %> adheres to the [RFC-5424 syslog protocol](https://tools.ietf.org/html/rfc5424), with log messages formatted as follows:
 
 `<${PRI}>${VERSION} ${TIMESTAMP} ${HOST_IP} ${APP_NAME} ${PROD_ID} ${MSG_ID} ${SD-ELEMENT-instance} ${MESSAGE}`
 
 The [Syslog Message Elements table](#syslog-elements) immediately below describes each element of the log, and the [Structured Instance Data Format](#sd-element) table describes the contents of the structured data element that carries Cloud Foundry VM instance information.
 
 ### <a id="syslog-elements"></a> Syslog Message Elements
 
-This table describes each element of a standard <%= vars.platform_name %> syslog message.
+This table describes each element of a standard <%= vars.app_runtime_abbr %> syslog message.
 
 <table id='syslog-elements-table' border="1" class="nice" >
   <tr>
@@ -216,7 +216,7 @@ This table describes each element of a standard <%= vars.platform_name %> syslog
   </tr><tr>
     <td><code>${PRI}</code></td>
     <td><p><a href="https://tools.ietf.org/html/rfc5424#section-6.2.1">Priority value (PRI)</a>, calculated as <code>8 × Facility Code + Severity Code</code></p>
-    <p>Pivotal uses a Facility Code value of <code>1</code>, indicating a user-level facility. This adds <code>8</code> to the RFC-5424 Severity Codes, resulting in the numbers listed in the <a href="#severity-codes">table below</a>.</p>
+    <p><%= vars.app_runtime_abbr %> uses a Facility Code value of <code>1</code>, indicating a user-level facility. This adds <code>8</code> to the RFC-5424 Severity Codes, resulting in the numbers listed in the <a href="#severity-codes">table below</a>.</p>
     <p>If in doubt, default to <code>13</code>, to indicate Notice-level severity.</p>
 </td>
   </tr><tr>
@@ -244,7 +244,7 @@ This table describes each element of a standard <%= vars.platform_name %> syslog
     <td>The <a href="https://tools.ietf.org/html/rfc5424#section-6.2.7">type</a> of log message. If this is not easily available, default to <code>-</code> (hyphen) to indicate unknown.</td>
   </tr><tr>
     <td><code>${SD-ELEMENT-instance}</code></td>
-    <td>Structured data (SD) relevant to <%= vars.platform_name %> about the <a href="https://tools.ietf.org/html/rfc5424#section-6.3.1">source instance (VM)</a> that originates the log message. See the <a href="#sd-element">Structured Instance Data Format table</a> below for content and format.</td>
+    <td>Structured data (SD) relevant to <%= vars.app_runtime_abbr %> about the <a href="https://tools.ietf.org/html/rfc5424#section-6.3.1">source instance (VM)</a> that originates the log message. See the <a href="#sd-element">Structured Instance Data Format table</a> below for content and format.</td>
   </tr><tr>
     <td><code>${MESSAGE}</code></td>
     <td>The log message itself, ideally in JSON</td>
@@ -253,7 +253,7 @@ This table describes each element of a standard <%= vars.platform_name %> syslog
 
 ### <a id="severity"></a> RFC-5424 Severity Codes
 
-<%= vars.platform_name %> components generate log messages with the following severity levels. The most common severity level is `13`.
+<%= vars.app_runtime_abbr %> components generate log messages with the following severity levels. The most common severity level is `13`.
 
 <table id='severity-table' border="1" class="nice" >
   <tr>
@@ -288,7 +288,7 @@ This table describes each element of a standard <%= vars.platform_name %> syslog
 
 ### <a id="sd-element"></a> Structured Instance Data Format
 
-The RFC-5424 syslog protocol includes a [structured data element](https://tools.ietf.org/html/rfc5424#section-6.3.1) that people can use as they see fit. Pivotal uses this element to carry VM instance information as follows:
+The RFC-5424 syslog protocol includes a [structured data element](https://tools.ietf.org/html/rfc5424#section-6.3.1) that people can use as they see fit. <%= vars.app_runtime_abbr %> uses this element to carry VM instance information as follows:
 
 <table id='sd-element-table' border="1" class="nice" >
   <tr>

ssi-creds-tiledev.html.md.erb

@@ -4,13 +4,13 @@ owner: Services
 ---
 
 
-This topic describes how to develop your <%= vars.platform_name %> service tile to support secure service instance (SSI) credentials using Runtime CredHub. For more information about Runtime CredHub, see [Runtime CredHub](https://docs.pivotal.io/pivotalcf/credhub/#runtime) in the _CredHub_ topic.
+This topic describes how to develop your <%= vars.platform_name %> service tile to support secure service instance (SSI) credentials using runtime CredHub. For more information about runtime CredHub, see [Runtime CredHub](https://docs.pivotal.io/pivotalcf/credhub/#runtime).
 
 ## <a id="background"></a> Background
 
 When developers bind an app to a service instance, the binding typically includes _binding credentials_ required to access the service.
 
-In <%= vars.platform_name %> (formerly PCF) and later, service brokers can store binding credentials as SSI credentials in runtime CredHub and apps can retrieve these credentials from CredHub. This secures service instance credential management by avoiding the following:
+In <%= vars.app_runtime_full %>, service brokers can store binding credentials as SSI credentials in runtime CredHub and apps can retrieve these credentials from CredHub. This secures service instance credential management by avoiding the following:
 
 * Leaking environment variables to logs, which increases risk of disclosure.
 * Sending credentials between components, which increases risk of disclosure.
@@ -26,23 +26,23 @@ To store binding credentials in runtime CredHub, your service tile needs to supp
 
 SSI credentials, which let apps access services through service instances, are distinct from the credentials that service tiles store in [BOSH CredHub](./credhub.html) for their own internal use. 
 
-When a service uses SSI credentials, its service broker stores the binding credentials in runtime CredHub. Then, when PAS binds an app to an instance of the service, the broker retrieves the credentials from runtime CredHub and delivers them to the Cloud Controller (CC) to enable the app to access the service.
+When a service uses SSI credentials, its service broker stores the binding credentials in runtime CredHub. Then, when %= vars.app_runtime_abbr %> binds an app to an instance of the service, the broker retrieves the credentials from runtime CredHub and delivers them to the Cloud Controller (CC) to enable the app to access the service.
 
-These SSI credentials are different from credentials that the tile uses internally, for example, to give the service broker access to an internal database. PAS generates the internal tile credentials for a service when the service is first installed and stores them in BOSH CredHub, not runtime CredHub.
+These SSI credentials are different from credentials that the tile uses internally, for example, to give the service broker access to an internal database. <%= vars.app_runtime_abbr %> generates the internal tile credentials for a service when the service is first installed and stores them in BOSH CredHub, not runtime CredHub.
 
 For more information on the CredHub credential management component, see the [CredHub documentation](https://docs.cloudfoundry.org/credhub/index.html) topic.
 
 The sections below describe an example implementation of how to add SSI credentials functionality to a service tile.
 
 ## <a id="step1"></a> Step 1: Modify Your BOSH Release
 
-To use runtime CredHub, your service tile needs to retrieve the location of the CredHub server, which is published in the Pivotal Application Service (PAS) tile, through a BOSH link.
+To use runtime CredHub, your service tile needs to retrieve the location of the CredHub server, which is published in the <%= vars.app_runtime_abbr %> tile, through a BOSH link.
 
 <p class="note"><strong>Note</strong>: BOSH Links let multiple jobs share deployment-time configuration properties. This helps to avoid redundant configurations in BOSH releases and deployment manifests. For more information about BOSH Links, see <a href="http://docs.pivotal.io/tiledev/1-11/release-notes.html#bosh-links">BOSH Links</a>.</p>
 
 ### <a id="spec"></a> Update Spec File and Templates
 
-The location of runtime CredHub is stored in the `credhub.internal_url` and `credhub.port` properties of the PAS tile. To enable your service tile to retrieve these CredHub-provided properties, add a `consumes:` section with the BOSH link from the PAS tile to the spec file of the BOSH job that will use them and edit the job's templates to access the values in the link:
+The location of runtime CredHub is stored in the `credhub.internal_url` and `credhub.port` properties of the <%= vars.app_runtime_abbr %> tile. To enable your service tile to retrieve these CredHub-provided properties, add a `consumes:` section with the BOSH link from the <%= vars.app_runtime_abbr %>  tile to the spec file of the BOSH job that will use them and edit the job's templates to access the values in the link:
 
 ```
     consumes:
@@ -54,9 +54,9 @@ For information about using BOSH Links in the spec file and templates of a job a
 
 ### <a id="errand"></a> Save the Runtime CredHub Location
 
-To use the runtime CredHub location retrieved from the PAS tile, you must write a `post_deploy` [tile errand](tile-structure.html#errands) that saves the value out in some way and enables the service broker to access it.
+To use the runtime CredHub location retrieved from the <%= vars.app_runtime_abbr %> tile, you must write a `post_deploy` [tile errand](tile-structure.html#errands) that saves the value out in some way and enables the service broker to access it.
 
-Depending on how your tile deploys the service broker app, the service instance errand can save the CredHub location in different ways. If the tile pushes the broker as a Cloud Foundry app, the errand can store the location in an environment variable such as `CREDHUB_URL` for the service broker to call. If BOSH deploys the service broker outside of of PAS, the errand could write the CredHub location out to a templated configuration file that the service broker reads.
+Depending on how your tile deploys the service broker app, the service instance errand can save the CredHub location in different ways. If the tile pushes the broker as a Cloud Foundry app, the errand can store the location in an environment variable such as `CREDHUB_URL` for the service broker to call. If BOSH deploys the service broker outside of <%= vars.app_runtime_abbr %>, the errand could write the CredHub location out to a templated configuration file that the service broker reads.
 
 ### <a id="manifest"></a> Update Deployment Manifest
 
@@ -97,7 +97,7 @@ properties:
         - '*.credhub.(( ..cf.credhub.network )).(( ..cf.deployment_name )).bosh'
 ```
 
-In the example, the runtime CredHub instance can be accessed at `credhub.service.cf.internal`. If your broker runs as an app, you can resolve this address with BOSH DNS. If your broker runs on a VM with a Consul agent, you can resolve the address with Consul. Alternatively, from a VM, you can resolve the address with `dig credhub.service.cf.internal @169.254.0.2`. This command uses the PAS BOSH DNS server to do lookup.
+In the example, the runtime CredHub instance can be accessed at `credhub.service.cf.internal`. If your broker runs as an app, you can resolve this address with BOSH DNS. If your broker runs on a VM with a Consul agent, you can resolve the address with Consul. Alternatively, from a VM, you can resolve the address with `dig credhub.service.cf.internal @169.254.0.2`. This command uses the  <%= vars.app_runtime_abbr %> BOSH DNS server to do lookup.
 
 ## <a id="step3"></a> Step 3: Provide Operators with the Choice to Use CredHub
 
@@ -111,7 +111,7 @@ form_types:
   property_inputs:
   - reference: .JOB-NAME.secure_credentials
     label: Secure service instance credentials
-    description: "When checked, service instance credentials are stored in CredHub. Enable only when installing with <%= vars.platform_name %> (formerly PCF) or later and this feature is also enabled in the PAS tile."
+    description: "When checked, service instance credentials are stored in CredHub. Enable only when installing with Ops Manager and this feature is also enabled in the <%= vars.app_runtime_abbr %> tile."
 
 property_blueprints:
   - name: hidden_credhub_selector