diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 00000000..7bab1667 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,6 @@ +# Normalise all text files to LF in the repo and working directory. +* text=auto eol=lf + +# Bash scripts must use LF so they run correctly in Git Bash/WSL. +*.sh text eol=lf +*.inc.sh text eol=lf \ No newline at end of file diff --git a/README.md b/README.md index c182b1e1..78cc35b4 100644 --- a/README.md +++ b/README.md @@ -1,15 +1,11 @@ # Guide for Developers Pushing Apps to Cloud Foundry -This is a guide for developers on deploying and troubleshooting apps running in Cloud Foundry. +This is a guide for developers on deploying and troubleshooting apps running in Tanzu Elastic Application Runtime (EAR). -This is one of several repositories that go into a complete documentation set. +This is one of several repositories that go into a complete documentation set; this branch is used only for Tanzu Elastic Application Runtime. -The contents here are structured as a topic repository intended to be compiled -into a larger document with -[Bookbinder](http://github.com/cloudfoundry-incubator/bookbinder). - -See the [docs-book-cloudfoundry](http://github.com/cloudfoundry/docs-book-cloudfoundry) -repository for the complete list of open source documentation repositories, as well as information about the publishing process. +See the [docs book repo](https://github.gwd.broadcom.net/TNZ/docs-book-application-service) +for the full TOC and the index files used to organize the book. docs-dev-guide/deploy-apps subdirectory: Develop and Manage Apps @@ -22,5 +18,19 @@ docs-dev-guide/services subdirectory: Custom Services Create and publish free or metered services for Cloud Foundry apps. - -This repository used to contain the subdirectory docs-dev-guide/cf-cli, documenting the Cloud Foundry Command Line Interface (cf CLI). The content from this subdirectory has been moved to its own repository, [docs-cf-cli](http://github.com/cloudfoundry/docs-cf-cli). +## Branch map + +| Branch | EART version | Doc Link | +|---------|------------------|---------------| +| 11.0 | EART 11.0 | [EART v11.0 staging](https://author-techdocs2-prod.adobecqms.net/us/en/vmware-tanzu/platform/elastic-application-runtime/11-0/eart/runtime-rn.html) +| tcf-104 | EART 10.4 | [EART v10.4](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-4/eart/runtime-rn.html) +| tcf-103 | EART 10.3 | [EART v10.3](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-3/eart/concepts-overview.html) | +| tcf-102 | TPCF 10.2 | [TPCF v10.2](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/elastic-application-runtime/10-2/eart/concepts-overview.html) | +| tcf-10 | TPCF 10.0 | archived PDF | +| 6.0 | TAS 6.0 (EOGS) | archived PDF | +| 5.0 | TAS 5.0 (EOGS) | archived PDF | +| 4.0 | TAS v4.0 (EOGS) | archived PDF | +| 3.0 | TAS v3.0 (EOGS) | archived PDF | +| 2.13 | TAS v2.13 (EOGS) | archived PDF | +| 2.12 | TAS v2.12 (EOGS) | archived PDF | +| 2.11 | TAS v2.11 (EOGS) | archived PDF | \ No newline at end of file diff --git a/egress-policies.html.md.erb b/archive/egress-policies.html.md.erb similarity index 100% rename from egress-policies.html.md.erb rename to archive/egress-policies.html.md.erb diff --git a/capi/client-libraries.html.md.erb b/capi/client-libraries.html.md.erb index f51ba076..1561810c 100644 --- a/capi/client-libraries.html.md.erb +++ b/capi/client-libraries.html.md.erb @@ -4,11 +4,7 @@ owner: CAPI --- Here is a list of the client libraries you can use with the Cloud Foundry API (CAPI) -<% if vars.platform_code == "CF" %> -. -<% else %> - for <%= vars.app_runtime_first %>. -<% end %> +for <%= vars.app_runtime_first %>. ## CAPI overview @@ -17,6 +13,11 @@ platform. You can use it to manage orgs, spaces, and apps, which includes user r <%= vars.capi_link %> +

CAPI v2 Deprecation and End of Life +
CAPI v2 endpoints are deprecated in both Open Source Cloud Foundry since 2021 and <%= vars.app_runtime_abbr %> in version 6.0 and forward. Given that these endpoints are deprecated, new development should use the v3 endpoints. +Open Source Cloud Foundry has plans to end of life the v2 endpoints following this RFC: https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0032-cfapiv2-eol.md +<%= vars.app_runtime_abbr %> does not have plans to end support for the V2 endpoints in the current LTS releases.

+ ## Client libraries While you can develop apps that use CAPI by calling it directly as in the API documentation, you might want to use an existing client library. See the following available client libraries. @@ -26,20 +27,17 @@ While you can develop apps that use CAPI by calling it directly as in the API do <%= vars.app_runtime_abbr %> supports the following clients for CAPI: * [Java](https://github.com/cloudfoundry/cf-java-client) -* [Scripting](http://cli.cloudfoundry.org/en-US/cf/curl.html) with the Cloud Foundry Command Line Interface (cf CLI) +* Scripting: Enter `cf curl --help` in the Tanzu cf CLI ### Experimental The following client is experimental and is a work in progress: -* [Golang](https://godoc.org/github.com/cloudfoundry/cli/api/cloudcontroller) +* [Golang](https://github.com/cloudfoundry/go-cfclient) ### Unofficial <%= vars.app_runtime_abbr %> does not support the following clients, but might be supported by third parties: -* Golang: - * [cloudfoundry-community/go-cfclient](https://github.com/cloudfoundry-community/go-cfclient) * Python: * [cloudfoundry-community/cf-python-client](https://github.com/cloudfoundry-community/cf-python-client) - * [hsdp/python-cf-api](https://github.com/hsdp/python-cf-api) diff --git a/custom-per-route-options.html.md.erb b/custom-per-route-options.html.md.erb new file mode 100644 index 00000000..39b7fe79 --- /dev/null +++ b/custom-per-route-options.html.md.erb @@ -0,0 +1,98 @@ +--- +title: Configuring per-route options +owner: CF for VMs Networking +--- + +By default, communication between Gorouter and backends is configured via general settings at the platform level. + +This topic describes how to specify per-route Gorouter options scoped at the application level. +This greater granularity lets developers tailor optimal routing behavior for applications' unique load profiles or other requirements. + +Gorouter supports the following per-route option, described in the section below: + +- `loadbalancing`: Configures the load balancing algorithm used by Gorouter for this particular route. <%= vars.per_route_lb_version %> + - Settings: `round-robin`, `least-connections`. + +## loadbalancing: Configure Gorouter's Load Balancing Algorithm + +<%= vars.per_route_lb_version %> + +The per-route option `loadbalancing` allows configuring the load balancing algorithm, which defines how the load is distributed between Gorouters and backends. + +This option supports two settings for load balancing: + +- `round-robin` distributes the load evenly across all available backends +- `least-connections` directs traffic to the backend with the fewest active connections at any given time, optimizing resource utilization + + +### Configure Load Balancing in an App Manifest + +To configure per-route load balancing for an application that has not yet been pushed: + +1. In the application manifest, include a `route` definition with an `options: loadbalancing` attribute set to `round-robin` or `least-connections`. For example: + + ```yaml + --- + applications: + - name: MY-APP + routes: + - route: MY-APP.EXAMPLE.COM + options: + loadbalancing: least-connections + ``` + + Where `MY-APP` is the name of your app and `MY-APP.EXAMPLE.COM` is the route you want to map to your app. + +1. Push the app with the manifest: + + ``` + cf push -f manifest.yml + ``` + +1. To confirm the setting, query the `routes` API endpoint for the app's route: + + ``` + cf curl /v3/routes/?hosts=MY-APP + ``` + + Where `MY-APP` is the host attribute of the route. The response lists the chosen `loadbalancing` algorithm setting: + + + ``` + "options": { + "loadbalancing": "least-connections" + } + ``` + +### Change Load Balancing of an Existing App + +To change the per-route `loadbalancing` setting of an app that has already been pushed, `cf curl` the `/v3/routes` API. +For example, to change an app route's algorithm from `least-connections` to `round-robin`: + +1. Execute a `PATCH` request to the targeted API endpoint: + + + ``` + cf curl /v3/routes/GUID -X PATCH -H "Content-type: application/json" \ + -d '{ + "options": { + "loadbalancing": "round-robin" + } + }' + ``` + + Where `GUID` is the unique identifier for the route. + +1. To confirm the setting, query the `routes` API endpoint for the route: + + ``` + cf curl /v3/routes/GUID + ``` + + Where `GUID` is the unique identifier for the route. The response lists the new `round-robin` setting: + + ``` + "options": { + "loadbalancing": "round-robin" + } + ``` diff --git a/custom-ports.html.md.erb b/custom-ports.html.md.erb index b546250d..c69cbd93 100644 --- a/custom-ports.html.md.erb +++ b/custom-ports.html.md.erb @@ -122,7 +122,6 @@ To configure your app to receive HTTP or TCP requests on custom ports:

- Caution This API call removes all destinations for a route and replaces them with the destinations you provide in the API request.

## Additional resources diff --git a/deploy-apps/_c2c_oss_enable.html.md.erb b/deploy-apps/_c2c_oss_enable.html.md.erb index 701f1b73..a68eba21 100644 --- a/deploy-apps/_c2c_oss_enable.html.md.erb +++ b/deploy-apps/_c2c_oss_enable.html.md.erb @@ -8,7 +8,7 @@ Container networking has properties you can configure to change the default beha The following table has a list of properties and instructions for editing them. -For more information about container networking configuration, see [Configuration Information for Operators](https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/configuration.md). +For more information about container networking configuration, see [Configuration Information for Operators](https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/06-c2c.md). diff --git a/deploy-apps/_c2c_oss_overlay.html.md.erb b/deploy-apps/_c2c_oss_overlay.html.md.erb index fa644abf..2eb048dd 100644 --- a/deploy-apps/_c2c_oss_overlay.html.md.erb +++ b/deploy-apps/_c2c_oss_overlay.html.md.erb @@ -33,7 +33,6 @@ To change the number of Diego Cells supported by the overlay network in your Clo

-Caution The overlay network IP address range must not conflict with any other IP addresses in the network. If a conflict exists, Diego Cells cannot reach any endpoint that has a conflicting IP address.

### Configure the number of containers per cell diff --git a/deploy-apps/_routing_conflict.html.md.erb b/deploy-apps/_routing_conflict.html.md.erb index e26a1c08..61970449 100644 --- a/deploy-apps/_routing_conflict.html.md.erb +++ b/deploy-apps/_routing_conflict.html.md.erb @@ -1,3 +1,3 @@ -<%=vars.product_short%> allows multiple apps, or versions of the same app, to be mapped to the same route. This feature activates blue-green deployment. For more information see [Using blue-green deployment to reduce downtime and risk](./blue-green.html). +<%=vars.app_runtime_abbr%> allows multiple apps, or versions of the same app, to be mapped to the same route. This feature activates blue-green deployment. For more information see [Using blue-green deployment to reduce downtime and risk](./blue-green.html). -Routing multiple apps to the same route might cause undesirable behavior in some situations by routing incoming requests randomly to one of the apps on the shared route. \ No newline at end of file +Routing multiple apps to the same route might cause undesirable behavior in some situations by routing incoming requests randomly to one of the apps on the shared route. diff --git a/deploy-apps/_v3-note.html.md.erb b/deploy-apps/_v3-note.html.md.erb index cb7001d1..6d9bbcaf 100644 --- a/deploy-apps/_v3-note.html.md.erb +++ b/deploy-apps/_v3-note.html.md.erb @@ -1,11 +1,8 @@
-Important -This attribute is available with CAPI V3 only. To push a manifest that uses this attribute, do one of the following: -

-

-

+This attribute is available with CAPI V3 only. To push a manifest that uses this attribute, use the Tanzu cf CLI. +
Run +
cf push APP-NAME
+
For information about this function, enter: +
cf push --help
+

For more details, see the Tanzu cf CLI documentation.
diff --git a/deploy-apps/app-lifecycle.html.md.erb b/deploy-apps/app-lifecycle.html.md.erb index 81d43fae..7c0ea187 100644 --- a/deploy-apps/app-lifecycle.html.md.erb +++ b/deploy-apps/app-lifecycle.html.md.erb @@ -43,15 +43,12 @@ During app duplication, singleton app instances might become temporarily unavail To stop the app, <%= vars.app_runtime_abbr %> sends the app process in the container a SIGTERM. By default, the process has ten seconds to shut down gracefully. If the process has not exited after ten seconds, <%= vars.app_runtime_abbr %> sends a SIGKILL. By default, apps must finish their in-flight jobs within ten seconds of receiving the SIGTERM before <%= vars.app_runtime_abbr %> stops the app with a SIGKILL. For example, a web app must finish processing existing requests and stop accepting new requests. -<% if vars.platform_code == 'PCF' %> - To change the timeout period on the <%= vars.app_runtime_abbr %> tile or IST tile, go to the Advanced Settings tab and edit the "app graceful shutdown period" property. -<% else %> -To change the timeout period, change the BOSH property containers.graceful_shutdown_interval_in_seconds on the replacement jobs. -<% end %> + +To change the timeout period on the <%= vars.app_runtime_abbr %> tile or IST tile, go to the Advanced Settings tab and edit the "app graceful shutdown period" property. + This might increase the time it takes to drain Diego Cells, which causes increased deployment time. <%= vars.app_graceful_shutdown_config %>

-Note An exception to the cases previously mentioned is when monit restarts a Diego Cell replacement or Garden server that has failed. In this case, <%= vars.app_runtime_abbr %> immediately stops the apps that are still running using SIGKILL.

diff --git a/deploy-apps/app-ssh-overview.html.md.erb b/deploy-apps/app-ssh-overview.html.md.erb index b25a2b25..7ff163b5 100644 --- a/deploy-apps/app-ssh-overview.html.md.erb +++ b/deploy-apps/app-ssh-overview.html.md.erb @@ -6,8 +6,6 @@ owner: Diego If you need to troubleshoot an instance of an application, you can gain SSH access to the app using the SSH proxy and daemon. For example, one of the app instances might be unresponsive, or the log output from the app is inconsistent or incomplete. You can SSH into the individual VM to troubleshoot the problem instance. -<%= vars.mutual_tls_ssh %> - ## About SSH access @@ -32,11 +30,11 @@ for spaces, and for apps as described in the table: Space manager Space - cf CLI allow-space-ssh and disallow-space-ssh commands + cf CLI cf allow-space-ssh and cf disallow-space-ssh commands Space developer App - cf CLI enable-ssh and disable-ssh commands + cf CLI cf enable-ssh and cf disable-ssh commands @@ -58,7 +56,7 @@ Space C does not have SSH Access allowed for all three apps, indicated by a red ## SSH access for apps and spaces -Space managers and space developers can configure SSH access from the CLI. The Cloud Foundry Command Line Interface (cf CLI) also includes commands to return the value of the SSH access setting. To use and configure SSH at both the app level and the space level, see [Accessing apps with Diego SSH](./ssh-apps.html). +Space managers and space developers can configure SSH access from the CLI. The Tanzu cf CLI also includes commands to return the value of the SSH access setting. To use and configure SSH at both the app level and the space level, see [Accessing apps with Diego SSH](./ssh-apps.html). ## Configuring SSH access for <%= vars.app_runtime_full %> diff --git a/deploy-apps/blue-green.html.md.erb b/deploy-apps/blue-green.html.md.erb index 3606e792..58137d40 100644 --- a/deploy-apps/blue-green.html.md.erb +++ b/deploy-apps/blue-green.html.md.erb @@ -13,8 +13,8 @@ serving all production traffic. For the example discussed here, Blue is live and Green is idle. As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green. -After deploy and fully tested the software in Green, you switch the -router so that all incoming requests now go to Green instead of Blue. +After deploying and fully testing the software in Green, you switch the router +so that all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle. This technique can eliminate downtime due to app deployment. @@ -25,8 +25,7 @@ version by switching back to Blue. You can adjust the route mapping pattern to display a static maintenance page during a maintenance window for time-consuming tasks such as migrating a database. In this scenario, the router switches all incoming requests from Blue to Maintenance to Green.

-Important -If your app uses a relational database, blue-green deployment can lead to discrepancies between your green and glue databases during an update. To maximize data integrity, configure a single database for backward and forward compatibility.

+If your app uses a relational database, blue-green deployment can lead to discrepancies between your green and blue databases during an update. To maximize data integrity, configure a single database for backward and forward compatibility.

## Blue-green deployment with Cloud Foundry example @@ -37,11 +36,13 @@ the server. ### Step 1: Push an app -Use the Cloud Foundry Command Line Interface (cf CLI) to push the app. +Use the Tanzu cf CLI to push the app. Name the app "Blue" with the subdomain "demo-time." 
-$ cf push Blue -n demo-time
+$ cf create-route example.com --hostname demo-time
+$ cf push Blue
+$ cf map-route Blue example.com --hostname demo-time
As shown in the graphic: @@ -49,7 +50,7 @@ As shown in the graphic: * Blue is now running on Cloud Foundry. * The Cloud Foundry Router sends all traffic for `demo-time.example.com` traffic to Blue. -![cf CLI pushing an app.](./images/../../images/blue-green/blue.png) +![Tanzu cf CLI pushing an app.](./images/../../images/blue-green/blue.png) ### Step 2: Update app and push @@ -58,14 +59,16 @@ Now make a change to the app. 1. Run `cf push` again, but use the name "Green" for the app and provide a different subdomain to create a temporary route: 
-$ cf push Green -n demo-time-temp
+$ cf create-route example.com --hostname demo-time-temp
+$ cf push Green
+$ cf map-route Green example.com --hostname demo-time-temp
After this push: * Two instances of the app are now running on Cloud Foundry: the original Blue and the updated Green. * The Cloud Foundry Router continues sending all traffic for `demo-time.example.com` to Blue. -The router now also sends any traffic for `demo-time-temp.example.com` to Green. +The router also sends any traffic for `demo-time-temp.example.com` to Green. ![The CF Router directs traffic to both Blue and Green sides.](../images/blue-green/blue-green.png) @@ -73,7 +76,7 @@ The router now also sends any traffic for `demo-time-temp.example.com` to Green. Now that both apps are up and running, switch the router so all incoming requests go to both the Green app and the Blue app. -Use the [cf map-route](http://cli.cloudfoundry.org/en-US/cf/map-route.html) command to map the original URL route (`demo-time.example.com`) to the Green app. +Use the `cf map-route` command to map the original URL route (`demo-time.example.com`) to the Green app. 
 $ cf map-route Green example.com -n demo-time
@@ -90,7 +93,7 @@ After the `cf map-route` command :
 ### Step 4: Unmap route to Blue
 
 After you verify that Green is running as expected, stop routing requests to Blue
-using the [cf unmap-route](http://cli.cloudfoundry.org/en-US/cf/unmap-route.html) command:
+using the `cf unmap-route` command:
 
 
 $ cf unmap-route Blue example.com -n demo-time
@@ -107,12 +110,10 @@ Now all traffic for `demo-time.example.com` is sent to Green.
 
 ### Step 5: Remove temporary route to Green
 
-You can now use `cf unmap-route` to remove the route `demo-time-temp.example.com` from Green. You can delete the route using `cf delete-route` or reserved it for later use. You can also decommission Blue, or keep it in case you need to roll back your changes.
+You can now use `cf unmap-route` to remove the route `demo-time-temp.example.com` from Green. You can delete the route using `cf delete-route` or reserve it for later use. You can also decommission Blue, or keep it in case you need to roll back your changes.
 
 ![After all traffic is routed to Green, the Blue side can be removed or replaced.](./images/../../images/blue-green/green.png)
 
-## Implementation
+## Alternative
 
-Cloud Foundry community members have written a plug-in to automate blue-green deployment:
-
-* [BlueGreenDeploy](https://github.com/bluemixgaragelondon/cf-blue-green-deploy): cf-blue-green-deploy is a plug-in, written in Go, for the Cloud Foundry Command Line Interface (cf CLI) that automates a few steps involved in zero-downtime deployments.
+Cloud Foundry offers an alternative way to deploy new versions of an app with zero downtime using the `cf push` command with the rolling deployment strategy. For more information, see [Deploying apps with zero downtime](./rolling-deploy.html#rolling).
diff --git a/deploy-apps/cf-networking.html.md.erb b/deploy-apps/cf-networking.html.md.erb
index da54173c..2fea6bf3 100644
--- a/deploy-apps/cf-networking.html.md.erb
+++ b/deploy-apps/cf-networking.html.md.erb
@@ -4,54 +4,40 @@ owner: CF for VMs Networking
 ---
 
 
-The container-to-container networking feature, also known as CF Networking, allows direct network traffic between apps. For an overview of how container-to-container networking works, see [Container-to-container networking](../../concepts/understand-cf-networking.html).
+The container-to-container networking feature allows direct network traffic between apps. For an overview of how container-to-container networking works, see [Container-to-container networking](../../concepts/understand-cf-networking.html).
 
 

-Important
 Container-to-container networking is not available for apps hosted on Microsoft Windows.

 
 <%= vars.app_traffic_logging %>
 
-<% if vars.platform_code == "CF" %>
-<%= partial 'c2c_oss_enable' %>
-<% end %>
-
-<% if vars.platform_code == "CF" %>
-<%= partial 'c2c_oss_overlay' %>
-<% else %>
 <%= partial "/pcf/core/c2c_overlay" %>
-<% end %>
-
-<% if vars.platform_code == "CF" %>
-<%= partial 'c2c_oss_logging' %>
-<% end %>
 
 
 ##  Create and manage networking policies
 
-This section describes how to create and edit container-to-container networking policies using the Cloud Foundry Command Line Interface (cf CLI).
+This section describes how to create and edit container-to-container networking policies using the Tanzu cf CLI.
 
 <%= vars.app_man_network %>
 
 ###  Prerequisites
 
-Ensure that you are using cf CLI v6.42 or later:
+Ensure that you are using Tanzu cf CLI v10 or later:
 
 
 $ cf version
 

 
-For more information about updating the cf CLI, see [Installing the cf CLI](../../cf-cli/install-go-cli.html).
+For more information about updating the cf CLI, see [Upgrading to Tanzu cf CLI v10](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/standalone-cf-cli-v10.html).
 
-<% if vars.platform_code == "CF" || vars.platform_code == "PCF" %>
 
 ###  Grant permissions
 
-Cloud Foundry admins use the following UAA scopes to grant specific users or groups permissions to configure network policies:
+Cloud Foundry admins use the following Tanzu UAA scopes to grant specific users or groups permissions to configure network policies:
 
 
-    
+    
@@ -75,19 +61,12 @@ To grant all Space Developers permissions to configure network policies, <%=  va
 
 By default, Space Developers can add a maximum of 150 network policies per
 source app.
-<% end %>
-<% if vars.platform_code == "PCF" %>
+
 Operators can increase this limit by changing the **Maximum number of network
 policies per app source** property in the **App Developer Controls** tab.
-<% end %>
-<% if vars.platform_code == "CF" %>
-Operators can change this limit by changing the `max_policies_per_app_source` property in the policy-server job in
-the Cloud Foundry deployment manifest.
-<% end %>
-<% if vars.platform_code == "CF" || vars.platform_code == "PCF" %>
+
 This limit does not apply to users with the network.admin scope.
 
-<% end %>
 
 ###  Add a network policy
 
@@ -176,35 +155,8 @@ You can deactivate Silk network policy enforcement between apps. Deactivating ne
 
 To deactivate network policy enforcement between apps:
 
-<% if vars.platform_code == "CF" %>
-
-1. To target your BOSH deployment, run:
-   
-   bosh target -e MY-ENV -d MY-DEPLOYMENT
-   

-   Where:
-   - `MY-ENV` is the alias you set for your BOSH Director.
-   - `MY-DEPLOYMENT` is your deployment name. You can see your deployment name by running `bosh -e MY-ENV deployments`.
-
-2. To download and save the BOSH manifest, run:
-   
-   bosh -e MY-ENV -d MY-DEPLOYMENT manifest > MY-MANIFEST.yml
-   

-   Where `MY-MANIFEST.yml` is the name you choose for the saved manifest.
-
-3. In your BOSH manifest, change the `disable_container_network_policy` value to `false`.
-
-4. To redeploy BOSH using the edited BOSH manifest, run:
-   
-   bosh -e MY-ENV -d MY-DEPLOYMENT deploy MY-MANIFEST.yml
-   

-
-<% else %>
-
 <%= partial "/pcf/core/disable_network_policy_enforcement" %>
 
-<% end %>
-
 
 ##  App service discovery
 
@@ -222,11 +174,3 @@ To establish container-to-container communications between a front end and back
 See [Cats and Dogs with Service Discovery](https://github.com/cloudfoundry/cf-networking-examples/blob/master/docs/c2c-with-service-discovery.md) in GitHub for an example, written in Go, that demonstrates communication between front end and back end apps.
 
 To use TLS developer adds a network policy for port 61443. After that the front end app can reach the back end app using HTTPS, `https://backend-app.apps.internal:61443`, for example.
-
-<% if vars.platform_code == "CF" %>
-
-###  Activate app service discovery
-
-To activate app service discovery, <%= vars.enable_c2c_discovery %>.
-
-<% end %>
diff --git a/deploy-apps/cf-scale.html.md.erb b/deploy-apps/cf-scale.html.md.erb
index a74c5970..f70ecc1e 100644
--- a/deploy-apps/cf-scale.html.md.erb
+++ b/deploy-apps/cf-scale.html.md.erb
@@ -1,17 +1,16 @@
 ---
-title: Scaling an app using Cloud Foundry CLI (cf scale)
+title: Scaling an app using Tanzu cf CLI (cf scale)
 owner: CAPI
 ---
 
 
-
 Factors such as user load, or the number and nature of tasks performed by an app, can change the disk space and memory the app uses.
-This topic describes how to scale an app using the Cloud Foundry Command Line Interface (cf CLI).
+This topic describes how to scale an app using the Tanzu cf CLI.
 For many apps, increasing the available disk space or memory can improve overall performance.
 Similarly, running additional instances of an app can allow the app to handle increases in user load and concurrent requests.
 These adjustments are called "scaling" an app.
 
-Use [cf scale](http://cli.cloudfoundry.org/en-US/cf/scale.html) to scale your app up or down to meet changes in traffic
+Use `cf scale` to scale your app up or down to meet changes in traffic
 or demand.
 
 <%=vars.autoscaler_note_dev_guide%>
@@ -27,20 +26,19 @@ Adding more instances allows your app to handle increased traffic and
 demand.
 
 Use `cf scale APP -i INSTANCES` to horizontally scale your app.
-Cloud Foundry increases or decreases the number of instances of your app to match `INSTANCES`.
+The number of instances of your app increases or decreases to match `INSTANCES`.
 
 
 $ cf scale myApp -i 5
 

-Note
-In cf CLI v7, you can also use --process with cf scale to scale specific processes of your app.

+In Tanzu cf CLI v10+, you can also use --process with cf scale to scale specific processes of your app.

 
 ## Scaling vertically
 
 Vertically scaling an app changes the disk space limit or memory limit
-that Cloud Foundry applies to all instances of the app.
+that is applied to all instances of the app.
 
 Use `cf scale APP -k DISK` to change the disk space limit applied to all
 instances of your app.
diff --git a/deploy-apps/deploy-app.html.md.erb b/deploy-apps/deploy-app.html.md.erb
index 702fc2f1..406c42ca 100644
--- a/deploy-apps/deploy-app.html.md.erb
+++ b/deploy-apps/deploy-app.html.md.erb
@@ -1,10 +1,10 @@
 ---
-title: Pushing your app with Cloud Foundry CLI (cf push)
+title: Pushing your app with Tanzu cf CLI (cf push)
 owner: CAPI
 ---
 
 
-The cf CLI command `cf push` pushes apps to <%= vars.app_runtime_abbr %>. There are two main ways to run the `cf push` command:
+The Tanzu cf CLI command `cf push` pushes apps to <%= vars.app_runtime_abbr %>. There are two main ways to run the `cf push` command:
 
 * Run `cf push APP-NAME` to push an app using default settings. For more information, see [Push with defaults](#default-push).
 
@@ -25,7 +25,7 @@ Before you push your app to <%= vars.app_runtime_abbr %>, ensure that:
 
 * Your app is "cloud-ready." <%= vars.app_runtime_abbr %> behaviors related to file storage, HTTP sessions, and port usage might require modifications to your app. To prepare an app to be pushed to <%= vars.app_runtime_abbr %>, see:
   * [Considerations for designing and running an app in the cloud](prepare-to-deploy.html)
-  * Any [Buildpacks](../../buildpacks/index.html) guides specific to your app language or framework, such as [Getting started deploying Ruby on Rails apps](../../buildpacks/ruby/gsg-ror.html)
+  * Any [Buildpacks](../../commercial-buildpacks/using-buildpacks.html) guides specific to your app language or framework, such as [Getting started deploying Ruby on Rails apps](../../commercial-buildpacks/ruby/gsg-ror.html)
 
 * Your <%= vars.app_runtime_abbr %> deployment supports the type of app you are going to push, or you have the URL of an externally-available buildpack that can stage the app.
 
@@ -166,17 +166,6 @@ Basic settings to customize when pushing an app include:
 
 * **Start command:** This is the command that <%= vars.app_runtime_abbr %> uses to start each instance of your app. This start command differs by app framework.
 
-###  Customize the route (optional)
-
-To customize an app's route:
-
-1. (Optional) Customize the host name by including the `-n` flag followed by a custom host name in your `cf push` command.
-
-1. (Optional) Customize the domain by including the `-d` flag followed by a custom domain in your `cf push` command. The custom domain must be registered,
-and mapped to the org that contains the app's target space.
-
-1. Ensure that the route is unique. The app's route must be globally unique, whether you customize its host or domain, or allow it to use the default route described in [Default route](#default-route). To help ensure route uniqueness, include the `--random-route` flag in your `cf push` command. This creates a route that includes the app name and random words.
-
 ###  Limit the upload files (optional)
 
 By default, <%= vars.app_runtime_abbr %> uploads all app files except version control files and directories with names such as `.svn`, `.git`, and `_darcs`.
@@ -199,14 +188,8 @@ You can configure the  `cf push` command to run custom initialization tasks for
 These tasks run after <%= vars.app_runtime_abbr %> loads the app droplet but before it starts the app to allow the initialization script to access the app language runtime environment. For example, your script can map values from `$VCAP_SERVICES` into other environment variables or a config file that the app uses.
 
 

-Important
-The following notes include important information about configuring app initialization when you use certain buildpacks:
+See the following important information about configuring app initialization when you use certain buildpacks:
   
    
-    
  • Java: Initialization scripts for the Java buildpack require additional configuration.
-    <% if vars.platform_code != 'CF' %> For more information, see
-      How to Modify the Application Container Environment prior to Application Execution in the VMware Tanzu Knowledge Base.
-      <% end %>
-      
    • 
     
  • PHP: <%= vars.app_runtime_abbr %> does not support initialization scripts for the PHP buildpack versions prior to v4.3.18. If you use
       one of these buildpack versions, your app hosts the .profile script's contents. This means that any app staged using the affected buildpack
       versions can leak credentials placed in the .profile script.
@@ -218,7 +201,7 @@ To run initialization tasks:
 
 1. Create a `.profile` script that contains the initialization tasks.
 
-1. Save the `.profile` script to the directory where you run the `cf push` command.
+2. Save the `.profile` script to the directory where you run the `cf push` command.
 
 The following example `.profile` file uses `bash` to set a value for the environment variable `LANG`:
 
@@ -231,7 +214,7 @@ Setting this value at the operating system level allows the app to find out whic
 
 Your app root directory might also include a `.profile.d` directory that contains bash scripts that perform initialization tasks for the buildpack. Developers
 must not edit these scripts unless they are using a custom buildpack. For more information about custom buildpacks, see [Custom
-Buildpacks](../../buildpacks/custom.html).
+Buildpacks](../../commercial-buildpacks/custom.html).
 
 Initialization tasks as described here are also called *pre-runtime hooks* and _`.profile` tasks_.
 
@@ -250,7 +233,7 @@ To specify custom options when pushing an app with `cf push`, you can include th
 For information about how app settings change from push to push, including how command-line options, manifests, and commands like `cf scale` interact, see
 [Deploying with App Manifests](manifest.html).
 
-For a full list of `cf push` options, see the [Cloud Foundry CLI reference guide](https://cli.cloudfoundry.org/en-US/cf/push.html).
+For a full list of `cf push` options, enter `cf push --help`.
 
 ###  Configure app services (optional)
 
@@ -262,18 +245,25 @@ For apps that are not already set up for the services that they use:
 1. Bind the services to the app. For more information about services, see [Services overview](../services/index.html).
 
 1. (Optional) Configure the app with the service URL and credentials, if needed. For more information, see [Configuring Service
-Connections](../../buildpacks/java/configuring-service-connections.html).
+Connections](../../commercial-buildpacks/java/configuring-service-connections.html).
+
+###  Build custom push workflows (optional)
+
+The Tanzu cf CLI includes [composable push sub-step commands](../push-sub-commands.html) that empower you to build your own push.
+These are useful if the default behavior of `cf push` does not match your
+needs, or if you want to implement more complicated app build, promotion, and
+run workflows.
 
 ##  App updates and downtime
 
-When you push an app that is already running, <%= vars.app_runtime_abbr %> stops all existing instances of that app. Users who try to access the app see a `404 Not Found` message while `cf push` runs.
+By default, when you push an app that is already running, <%= vars.app_runtime_abbr %> stops all existing instances of that app. Users who try to access the app see a `404 Not Found` message while `cf push` runs.
 
-With some app updates, old and new versions of your code must never run at the same time. A worst-case example is if your app update migrates a database schema, causing old app instances to fail and lose user data. To prevent this, you must stop all running instances of your app before you push the new version.
+When old and new versions of your app can run simultaneously, you can avoid app downtime by using [Rolling deployments](./rolling-deploy.html). Alternatively, you can use the blue-green deployment method to swap routes between app versions running in parallel. For more information, see [Using blue-green deployment to reduce downtime and risk](blue-green.html).
 
-When old and new versions of your app can run simultaneously, you can avoid app downtime by using the blue-green deployment method to swap routes between app versions running in parallel. For more information, see [Using blue-green deployment to reduce downtime and risk](blue-green.html).
+With some app updates, old and new versions of your code must never run at the same time. A worst-case example is if your app update migrates a database schema, causing old app instances to fail and lose user data. To prevent this, you must stop all running instances of your app before you push the new version.
 
 ##  Troubleshoot app push problems
 
 If your app does not start on <%= vars.app_runtime_abbr %>, first ensure that the app can run locally.
 
-To troubleshoot your app in the cloud using the cf CLI, see [Troubleshoot app deployment and health](troubleshoot-app-health.html).
+To troubleshoot your app in the cloud using the Tanzu cf CLI, see [Troubleshoot app deployment and health](troubleshoot-app-health.html).
diff --git a/deploy-apps/environment-variable.html.md.erb b/deploy-apps/environment-variable.html.md.erb
index 55e3c6e7..d5c9706b 100644
--- a/deploy-apps/environment-variable.html.md.erb
+++ b/deploy-apps/environment-variable.html.md.erb
@@ -1,37 +1,28 @@
 ---
-title: Cloud Foundry environment variables
+title: Environment Variables
 owner: CAPI
 ---
 
-<%# Reset page title based on platform type %>
-<% if vars.platform_code != 'CF' %>
-
-<% set_title(vars.app_runtime_abbr, "Environment Variables") %>
-
-<% end %>
-
 Environment variables are the means <%= vars.app_runtime_abbr %> uses to communicate with a deployed app about its environment.
 
 For information about setting your own app-specific environment variables, see the [Environment variable](./manifest.html#env-block) in _Deploying with app manifests_.
 
 
    
-Important
-Do not use user-provided environment variables for security-sensitive information such as credentials. They might unintentionally show up in cf CLI output and Cloud Controller logs. Use user-provided service instances instead. The system-provided environment variable VCAP_SERVICES is properly redacted for user roles such as Space Supporter and in Cloud Controller log files.
    
+Do not use user-provided environment variables for security-sensitive information such as credentials. They might unintentionally show up in Tanzu cf CLI output and Cloud Controller logs. Use user-provided service instances instead. The system-provided environment variable VCAP_SERVICES is properly redacted for user roles such as Space Supporter and in Cloud Controller log files.
    
 
 
    
-Important
 The maximum size of an environment variable is 130 KB. This limit applies also to <%= vars.app_runtime_abbr %> system environment variables such as VCAP_SERVICES and VCAP_APPLICATION.
    
 
    
 
 ##  View environment variables
 
-Using the Cloud Foundry Command Line Interface (cf CLI), you can run the `cf env` command to view the <%= vars.app_runtime_abbr %> environment variables for your app. The `cf env` command displays the following environment variables:
+Using the Tanzu cf CLI, you can run the `cf env` command to view the <%= vars.app_runtime_abbr %> environment variables for your app. The `cf env` command displays the following environment variables:
 
 * The `VCAP_APPLICATION` and `VCAP_SERVICES` variables provided in the container environment
 
 * The user-provided variables set using the `cf set-env` command
 
-For more information about the `cf env` command, see [env](http://cli.cloudfoundry.org/en-US/cf/env.html) in the cf CLI documentation. For more information about the `cf set-env` command, see [set-env](http://cli.cloudfoundry.org/en-US/cf/set-env.html) in the cf CLI documentation.
+For more information about the `cf env` command, enter `cf env --help`. 
    For more information about the `cf set-env` command, enter `cf set-env --help`.
 
 The following example demonstrates the environment variables `cf env` displays:
 
@@ -79,7 +70,7 @@ MY_ENV_VARIABLE: 100
 
 This section describes the environment variables that <%= vars.app_runtime_abbr %> makes available to your application container. Some of these variables are the same across instances of a single app, and some vary from instance to instance.
 
-You can access environment variables programmatically, including variables defined by the buildpack. For more information, see the buildpack documentation for [Java](../../buildpacks/java/java-tips.html#env-var), [Node.js](../../buildpacks/node/node-tips.html#env-var), and [Ruby](../../buildpacks/ruby/ruby-tips.html#env-var).
+You can access environment variables programmatically, including variables defined by the buildpack. For more information, see the buildpack documentation for [Java](../../commercial-buildpacks/java/java-tips.html#env-var), [Node.js](../../commercial-buildpacks/nodejs/node-tips.html#env-var), and [Ruby](../../commercial-buildpacks/ruby/ruby-tips.html#env-var).
 
 The following table lists the system variables available to your application container.
 
@@ -206,7 +197,7 @@ For example: `LANG=en_US.UTF-8`
 
 ###  MEMORY_LIMIT
 
-The maximum amount of memory that each instance of the app can consume. You specify this value in an app manifest or with the cf CLI when pushing an app. The value is limited by space and org quotas.
+The maximum amount of memory that each instance of the app can consume. You specify this value in an app manifest or with the Tanzu cf CLI when pushing an app. The value is limited by space and org quotas.
 
 If an instance exceeds the maximum limit, it is restarted. If <%= vars.app_runtime_abbr %> is asked to restart an instance too frequently, the instance is stopped.
 
@@ -274,7 +265,7 @@ For bindable services, <%= vars.app_runtime_abbr %> adds connection details to t
 
 <%= vars.app_runtime_abbr %> returns the results as a JSON document that contains an object for each service for which one or more instances are bound to the app. The service object contains a child object for each instance of the service that is bound to the app.
 
-The following a table defines the attributes that describe a bound service. The key for each service in the JSON document is the same as the value of the "label" attribute.
+The following table defines the attributes that describe a bound service. The key for each service in the JSON document is the same as the value of the "label" attribute.
 
 | Attribute | Description |
 | --------- | ----------- |
diff --git a/deploy-apps/healthchecks.html.md.erb b/deploy-apps/healthchecks.html.md.erb
index 80f61484..4eb5a887 100644
--- a/deploy-apps/healthchecks.html.md.erb
+++ b/deploy-apps/healthchecks.html.md.erb
@@ -13,8 +13,7 @@ restarted. Readiness health checks are performed to validate that app instances
 ready to serve requests. When readiness health checks fail, the app instance is
 marked as not ready and removed from the route pool for the app.
 
-You can configure a liveness health check for an app using the Cloud Foundry
-Command Line Interface (cf CLI) or by specifying a combination of the
+You can configure a liveness health check for an app using the Tanzu cf CLI or by specifying a combination of the
 `health-check-http-endpoint`, `health-check-type`,
 `health-check-invocation-timeout`, and `health-check-interval` fields in an
 [app manifest](manifest.html).
@@ -26,7 +25,7 @@ To use readiness health checks, you must have:
 * diego-release 2.81.0
 * capi-release 1.158.0
 
-To configure a health check using the cf CLI, see:
+To configure a health check using the Tanzu cf CLI, see:
 
 * [Configure health checks when creating or updating](#setting-health-checks)
 
@@ -66,11 +65,9 @@ types are `port`, `process`, and `http`. For more information, see [Health check
 * `LIVENESS-HEALTH-CHECK-TIMEOUT` is the amount of time allowed to elapse between starting an app and the
 first healthy response. For more information, see [Health check timeouts](#health_check_timeout).
 
-For more information about the `cf push` command, see
-[push](http://cli.cloudfoundry.org/en-US/cf/push.html) in the Cloud Foundry CLI Reference Guide.
+For more information about the `cf push` command, enter `cf push --help`.
 
 
    
-Important
 The health check configuration that you provide with
 cf push overrides any configuration in the app manifest.
    
 
@@ -92,14 +89,11 @@ Where:
 * `CUSTOM-HTTP-ENDPOINT` is the custom HTTP endpoint that you want to add to the health check. By default, an `http` health check uses `/` as its endpoint unless you specify a custom endpoint. For more information, see [Health check HTTP endpoints](#health_check_uri).
 
 You can also change the health check invocation timeout for
-an app. If you are using cf CLI v6, use cf v3-set-health-check. If you have cf CLI v7, use cf set-health-check. This option also requires restarting the app. For more information, see Apps in the Cloud Foundry CLI Reference Guide.
+an app, use cf set-health-check. This option also requires restarting the app.
 
-For more information about the `cf set-health-check` command, see
-[set-health-check](http://cli.cloudfoundry.org/en-US/cf/set-health-check.html) in
-the Cloud Foundry CLI Reference Guide.
+For more information about the `cf set-health-check` command, enter `cf set-health-check`.
 
 
    
-Important
 After you set the health check configuration of a deployed
 app with the cf set-health-check command, you must restart the app for the change to
 take effect.
    
@@ -134,7 +128,6 @@ circumstances in which to use them:
     

-  
@@ -145,7 +138,6 @@ circumstances in which to use them:
     web app is ready to serve HTTP requests. The configured endpoint must respond within one second
     to be considered healthy.

-    Important
     To prevent false
     negatives, use a dedicated endpoint for health checks where response time and result do not
     depend on business logic.

@@ -184,5 +176,4 @@ path portion of a URI that must be served by the app and return `HTTP 200` when
 This command only checks the health of the default port of the app.
 
 

-Important
 For HTTP apps, <%= vars.company_name %> recommends setting the health check type to http instead of a simple port check.

diff --git a/deploy-apps/large-app-deploy.html.md.erb b/deploy-apps/large-app-deploy.html.md.erb
index 6c0130e5..ff57c5e9 100644
--- a/deploy-apps/large-app-deploy.html.md.erb
+++ b/deploy-apps/large-app-deploy.html.md.erb
@@ -28,17 +28,17 @@ To deploy large apps to <%= vars.app_runtime_abbr %>, ensure that:
 
 * You push only the files that are necessary for your app. To meet this requirement, push only the directory for your app, and remove unneeded files or use the `.cfignore` file to specify excluded files. For more information about specifying excluded files, see [Ignore unnecessary files when pushing](prepare-to-deploy.html#exclude) in _Considerations for Designing and Running an App in the Cloud_.
 
-* You configure Cloud Foundry Command Line Interface (cf CLI) staging, startup, and timeout settings to override settings in the manifest, as necessary:
+* You configure Tanzu cf CLI staging, startup, and timeout settings to override settings in the manifest, as necessary:
+
   	* `CF_STAGING_TIMEOUT`: The maximum time in minutes that the cf CLI waits for an app to stage after <%= vars.app_runtime_abbr %> uploads and
     packages the app.
   	* `CF_STARTUP_TIMEOUT`: The maximum time in minutes that the cf CLI waits for an app to start
   	* `cf push -t TIMEOUT`: The maximum time in seconds that <%= vars.app_runtime_abbr %> allows to elapse between starting an app and the first healthy response from the app. When you use this flag, the cf CLI ignores any app start timeout value set in the manifest.
 
-For more information about using the cf CLI to deploy apps, see [Push](../../cf-cli/getting-started.html#push) in _Getting Started with the cf CLI_.
+For more information about using the Tanzu cf CLI to deploy apps, see [Tanzu cf CLI documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/standalone-index.html).
 
 

-Important
-Changing the timeout setting for the cf CLI does not change the timeout limit for <%= vars.app_runtime_abbr %>
+Changing the timeout setting for the Tanzu cf CLI does not change the timeout limit for <%= vars.app_runtime_abbr %>
 server-side jobs such as staging or starting apps. You must change server-side timeouts in the manifest. Because of the differences between the
 <%= vars.app_runtime_abbr %> and cf CLI timeout values, your app might start even though the cf CLI reports App failed. To review the status of your app, run cf apps APP-NAME, where APP-NAME is the name of your app.

 
@@ -62,13 +62,13 @@ The following table provides a summary of the constraints and default settings t
   
-    
-    
@@ -82,6 +82,14 @@ The following table provides a summary of the constraints and default settings t
     
+  
+    
+    
+  
+  
+    
+    
+  
diff --git a/deploy-apps/manifest-attributes.html.md.erb b/deploy-apps/manifest-attributes.html.md.erb
index 14a70d93..c7448ef1 100644
--- a/deploy-apps/manifest-attributes.html.md.erb
+++ b/deploy-apps/manifest-attributes.html.md.erb
@@ -3,7 +3,7 @@ title: App manifest attribute reference
 owner: CLI
 ---
 
-You can manage app properties and behavior using cf CLI commands or the app manifest (a YAML properties file). This topic describes manifest formatting and provides a list of attributes available for app manifests. You can use it with [Deploying with app manifests](manifest.html), which provides basic procedures and guidance for deploying apps with manifests.
+You can manage app properties and behavior using Tanzu cf CLI commands or the app manifest (a YAML properties file). This topic describes manifest formatting and provides a list of attributes available for app manifests. You can use it with [Deploying with app manifests](manifest.html), which provides basic procedures and guidance for deploying apps with manifests.
 
 For more information about V3 manifest properties, see the [Cloud Foundry API (CAPI) V3 documentation](http://v3-apidocs.cloudfoundry.org/index.html#space-manifest).
 
@@ -32,8 +32,7 @@ applications:
 ```
 
 

-Important
-If your app name begins with the dash character (-), you cannot interact with the app using the cf CLI. This is because the cf CLI interprets the dash as a flag.

+If your app name begins with the dash character (-), you cannot interact with the app using the Tanzu cf CLI. This is because the Tanzu cf CLI interprets the dash as a flag.

 
 ###  Add schema version to a manifest
 
@@ -73,7 +72,6 @@ To add variables to an app manifest:
       command: go_calls_ruby
     ```
     

-    Note
     You can also use variables for partial values. For example, you can specify host in your variables file and - route: ((host)).env.com in your manifest file.

 
 1. Run:
@@ -114,12 +112,6 @@ memory for `bigapp`.
 
 This section explains how to describe optional app attributes in manifests. You can also specify each of these attributes using a command line option. Command-line options override the manifest.
 
-

-Important
-In cf CLI v6, the route component attributes domain, domains, host,
-hosts, and no-hostname are deprecated in favor of the routes attribute. In cf CLI v7, these attributes are
-removed. For more information, see domain, domains, host, hosts, and no-hostname.

-
 ###  buildpacks
 
 You can refer to a buildpack by name in a manifest or a command-line option. The `cf buildpacks` command lists the buildpacks that you can use.
@@ -146,7 +138,6 @@ You can refer to a buildpack by name in a manifest or a command-line option. The
           - buildpack_URL
       ```
       

-      Important
         
    
           
  • This feature does not work with the deprecated buildpack attribute. For more information, see
             buildpack.
    • 
@@ -156,11 +147,11 @@ You can refer to a buildpack by name in a manifest or a command-line option. The
 
 The `-b` command-line flag overrides this attribute.
 
-For more information, see [Pushing an app with multiple buildpacks](../../buildpacks/use-multiple-buildpacks.html).
+For more information, see [Pushing an app with multiple buildpacks](../../commercial-buildpacks/use-multiple-buildpacks.html).
 
 ###  command
 
-Some languages and frameworks require that you provide a custom command to start an app. To find out if you need to provide a custom start command, see [Buildpacks](../../buildpacks/index.html).
+Some languages and frameworks require that you provide a custom command to start an app. To find out if you need to provide a custom start command, see [Using Classic Buildpacks in Cloud Foundry](../../commercial-buildpacks/using-buildpacks.html).
 
 You can provide the custom start command in your app manifest or on the command line. For more information about how <%= vars.app_runtime_abbr %> determines its default start command, see [Starting, restarting, and restaging apps](start-restart-restage.html).
 
@@ -236,7 +227,6 @@ The `--docker-image` or `-o` command-line flag overrides `docker.image`.  The `-
 The manifest attribute `docker.username` is optional. If it is used, the password must be provided in the environment variable `CF_DOCKER_PASSWORD`. If a Docker user name is specified, then a Docker image must also be specified.
 
 
    
-Important
 Using the docker attribute with the buildpacks or path attributes causes an error.
    
 
 ###  health-check-type
@@ -253,8 +243,6 @@ For example:
 
 The `-u` command-line flag overrides this attribute.
 
-In cf CLI v6, the value of `none` is deprecated in favor of `process`. In cf CLI v7, `none` is removed.
-
 ###  health-check-http-endpoint
 
 The `health-check-http-endpoint` attribute customizes the endpoint for the `http` health check type. If you do not provide a `health-check-http-endpoint` attribute, it uses endpoint `/`.
@@ -368,6 +356,23 @@ The default number of instances is 1.
 
 To ensure that platform maintenance does not interrupt your app, <%= vars.recommended_by %> recommends running at least two instances.
 
+###  lifecycle
+
+The `lifecycle` attribute specifies which application lifecycle to use for staging and running the application. Three variants are supported at the moment:
+
+- [`buildpack`](../../commercial-buildpacks/classic.html)
+- [`docker`](push-docker.html)
+
+For example:
+
+```
+---
+  ...
+  lifecycle: buildpack
+```
+
+The default is `buildpack` unless the [`docker`](#docker) attribute is specified.
+
 ###  log-rate-limit-per-second
 
 The `log-rate-limit-per-second` attribute specifies the log rate limit for all instances of an app. This attribute requires a unit of measurement: `B`, `K`, `KB`, `M`, `MB`, `G`, or `GB`, in either uppercase or lowercase.
@@ -423,7 +428,6 @@ For more information about metadata, see [Using metadata](../../adminguide/metad
 ###  no-route
 
 
    
-Important
 If you use the no-route flag attribute in the manifest or the flag option, it overrides all route-related attributes.
    
 
 By default, `cf push` assigns a route to every app. But, some apps process data while running in the background and must not be assigned routes.
@@ -470,7 +474,7 @@ For example:
 
 The `-p` command-line flag overrides this attribute.
 
-For more information, see [How cf push finds the app](../../cf-cli/getting-started.html#find-app) in _Getting Started with the cf CLI_.
+For more information, see [Tanzu cf CLI documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/standalone-index.html).
 
 ###  processes
 
@@ -507,9 +511,9 @@ For more information about pushing an app with multiple processes, see [Pushing
 
 ###  random-route
 
-If you push your app without specifying any route-related CLI options or app manifest flags, the cf CLI attempts to generate a route based on the app name, which can cause collisions.
+If you push your app without specifying any route-related CLI options or app manifest flags, the Tanzu cf CLI attempts to generate a route based on the app name, which can cause collisions.
 
-You can use the `random-route` attribute to generate a unique route and avoid name collisions. When you use `random-route`, the cf CLI generates one of the following:
+You can use the `random-route` attribute to generate a unique route and avoid name collisions. When you use `random-route`, the Tanzu cf CLI generates one of the following:
 
 * An HTTP route with a random host, if no value is specified for `host`
 
@@ -535,14 +539,9 @@ The `--random-route` command-line flag overrides this attribute.
 
 The `routes` attribute in the manifest provides multiple HTTP and TCP routes. Each route for this app is created if it does not already exist.
 
-
    
-Important
-This attribute is a combination of push options that include --hostname, -d, and --route-path flags in v6. These flags are not supported in cf CLI v7, so the routes flag must be used.
    
-
 You can specify the `protocol` attribute to configure which network protocol the route uses for app ingress traffic. This is optional. The available protocols are `http2`, `http1`, and `tcp`.
 
 
    
-Important
 The protocol route attribute is available only for <%= vars.app_runtime_abbr %> deployments that use HTTP/2 routing. <%= vars.http2_admin_link %> 
    
 
 For example:
@@ -557,6 +556,26 @@ For example:
   - route: tcp-example.com:1234
 ```
 
+Under each route, you can optionally include an `options` attribute to configure per-route options as described in [Configuring per-route options](../custom-per-route-options.html).
+
+Available options are:
+
+- `loadbalancing` - defines how Gorouter distributes requests across the application backends. Valid values are `round-robin` and `least-connections`.
+
+For example:
+
+```
+---
+  ...
+  routes:
+  - route: example.com
+    options:
+      loadbalancing: round-robin
+  - route: example2.com
+    options:
+      loadbalancing: least-connections
+```
+
 ####  Manifest attributes
 
 If you use the `routes` attribute with the `host`, `hosts`, `domain`, `domains`, or `no-hostname` attributes, an error results.
@@ -564,7 +583,6 @@ If you use the `routes` attribute with the `host`, `hosts`, `domain`, `domains`,
 ####  push flag options
 
 This attribute has unique interactions with different command-line options.
-This table is updated for cf CLI v7; several of the flags were removed (`--route-path`, `-d`, `--hostname`, `--no-hostname`)
 
 

   
UAA ScopeTanzu UAA Scope
     Suitable for…
     Allows users to create policies…
   

 
 
Recommended use case
     Explanation
   

   

     http
     The app can provide an HTTP 200 response.
     

   

     CF_STAGING_TIMEOUTcf CLI environment variable
+    Tanzu cf CLI environment variable
       

       Default: 15 minutes		
   

   

     CF_STARTUP_TIMEOUTcf CLI environment variable
+    Tanzu cf CLI environment variable
       

       Default: 5 minutes		
   
Disk space allocation
     Default: 1024 MB
   
Minimum staging memoryDefault: 1024 MB
Minimum staging disk spaceDefault: 4096 MB

   

     Internet connection speed
     Recommended minimum: 874 KB per second

@@ -573,7 +591,7 @@ This table is updated for cf CLI v7; several of the flags were removed (`--route
   
-    
+    
@@ -640,7 +658,6 @@ You can increase the timeout length for very large apps that require more time t
 The `-t` command-line flag overrides this attribute.
 
 

-Important
 If you configure timeout with a value greater than
 cc.maximum_health_check_timeout, the Cloud Controller reports a validation error with the maximum limit.

 
@@ -662,10 +679,9 @@ For example:
 `cf push` deploys the app to a container on the server. The variables belong to the container environment.
 
 

-Important
   
    
     
  • You must name variables with alphanumeric characters and underscores. Non-conforming variable names might cause unpredictable behavior.
    • 
-    
  • Do not use user-provided environment variables for security sensitive information such as credentials, because they might unintentionally show up in cf CLI output and Cloud Controller logs. Use user-provided service instances instead. The system-provided environment variable VCAP_SERVICES is properly redacted for user roles such as Space Supporter and in Cloud Controller log files.
    • 
+    
  • Do not use user-provided environment variables for security sensitive information such as credentials, because they might unintentionally show up in Tanzu cf CLI output and Cloud Controller logs. Use user-provided service instances instead. The system-provided environment variable VCAP_SERVICES is properly redacted for user roles such as Space Supporter and in Cloud Controller log files.
    • 
   

 

 
@@ -755,7 +771,6 @@ service](../services/application-binding.html#bind) in _Delivering Service Crede
 This section describes app manifest features that are deprecated in favor of other features.
 
 

-Caution
 Running cf push app -f manifest.yml fails if your manifest uses any of these deprecated features with the feature that replaces it.

 
 ###  Top-level attributes
@@ -802,47 +817,6 @@ applications:
 When pushing the app, make explicit the attributes in each app's declaration. To do this, assign the anchors and include the app-level attributes with YAML
 aliases in each app declaration.
 
-###  domain, domains, host, hosts, and no-hostname attributes
-
-These flags are removed in cf CLI v7.
-
-Previously, you could specify routes by listing them all at once using the `routes` attribute, or by using their hosts and domains.
-
-For example:
-
-```
----
-applications:
-- name: webapp
-  host: www
-  domains:
-  - example.com
-  - example.io
-```
-
-The following route component attributes are deprecated:
-
-* `domain`
-
-* `domains`
-
-* `host`
-
-* `hosts`
-
-* `no-hostname`
-
-You can only specify routes using the `routes` attribute:
-
-```
----
-applications:
-- name: webapp
-  routes:
-  - route: www.example.com/foo
-  - route: tcp.example.com:1234
-```
-
 ###  Inheritance
 
 This feature is deprecated and replaced by variable substitution. For more information, see [Variable substitution](#variable-substitution).
diff --git a/deploy-apps/manifest.html.md.erb b/deploy-apps/manifest.html.md.erb
index c59a86a1..a8c4e960 100644
--- a/deploy-apps/manifest.html.md.erb
+++ b/deploy-apps/manifest.html.md.erb
@@ -16,6 +16,8 @@ Both manifests and command line options allow you to override the default attrib
 
 * Command line options override manifests.
 
+* The manifest configuration is additive and will not modify any unspecified properties or remove any existing environment variables, routes, or services.
+
 For a full list of attributes you can specify in an app manifest, see [App manifest attribute reference](manifest-attributes.html).
 
 
diff --git a/deploy-apps/prepare-to-deploy.html.md.erb b/deploy-apps/prepare-to-deploy.html.md.erb
index 1f3f148f..9ad12e4f 100644
--- a/deploy-apps/prepare-to-deploy.html.md.erb
+++ b/deploy-apps/prepare-to-deploy.html.md.erb
@@ -6,15 +6,15 @@ owner: CAPI
 
 These are best practices for developing modern apps for cloud platforms. For more detailed reading about good app design for the cloud, see [The Twelve-Factor App](http://www.12factor.net).
 
-Following these guidelines facilitates app deployment to <%= vars.platform_name %> and other cloud platforms, and apps written in supported frameworks often run unmodified.
+Following these guidelines facilitates app deployment to <%= vars.app_runtime_abbr %> and other cloud platforms, and apps written in supported frameworks often run unmodified.
 
-For more information about the features of HTTP routing handled by the Gorouter in <%= vars.platform_name %>,
+For more information about the features of HTTP routing handled by the Gorouter in <%= vars.app_runtime_abbr %>,
 see [HTTP routing](../../concepts/http-routing.html).
 For more information about the life cycle of application containers, see [Application container life cycle](app-lifecycle.html).
 
 ##  Avoid writing to the local file system
 
-Apps running on <%= vars.platform_name %> must not write files to the local file system because:
+Apps running on <%= vars.app_runtime_abbr %> must not write files to the local file system because:
 
 * **Local file system storage is short-lived.** When an app instance fails or stops, the resources assigned to that instance are reclaimed by the platform, including any local disk changes made since the app started. When the instance is restarted, the app starts with a new disk image. Although your app can write local files while it is running, the files disappear after the app restarts.
 
@@ -27,7 +27,7 @@ Apps running on <%= vars.platform_name %> must not write files to the local file
   the local file system must not be used. <%= vars.company_name %> recommends
   using a shared data service like a database or blobstore for this purpose.
 
-For example, instead of using the local file system, you can use a <%= vars.platform_name %> service
+For example, instead of using the local file system, you can use a <%= vars.app_runtime_abbr %> service
 such as the MongoDB document database or a relational database like MySQL or PostgreSQL.
 Another option is to use cloud storage providers such as [Amazon S3](http://aws.amazon.com/s3/),
 [Google Cloud Storage](https://cloud.google.com/products/cloud-storage),
@@ -52,28 +52,28 @@ You must decide whether you want your apps or tools that use cookies to set and
 
 ##  Port considerations
 
-Clients connect to apps running on <%= vars.platform_name %> by making requests to URLs associated with the app.
-<%= vars.platform_name %> allows HTTP requests to apps on ports 80 and 443.
+Clients connect to apps running on <%= vars.app_runtime_abbr %> by making requests to URLs associated with the app.
+<%= vars.app_runtime_abbr %> allows HTTP requests to apps on ports 80 and 443.
 For more information, see [Routes and domains](routes-domains.html).
 
-<%= vars.platform_name %> also supports WebSocket handshake requests over HTTP containing the `Upgrade` header.
-The <%= vars.platform_name %> router handles the upgrade and initiates a TCP connection
+<%= vars.app_runtime_abbr %> also supports WebSocket handshake requests over HTTP containing the `Upgrade` header.
+The <%= vars.app_runtime_abbr %> router handles the upgrade and initiates a TCP connection
 to the app to form a WebSocket connection.
 
 <%= vars.port_limitations %>
 
-##  <%= vars.platform_name %> updates and your app
+##  <%= vars.app_runtime_abbr %> updates and your app
 
-For app management purposes, <%= vars.platform_name %> might need to stop and restart your app instances.
-If this occurs, <%= vars.platform_name %> performs the following steps:
+For app management purposes, <%= vars.app_runtime_abbr %> might need to stop and restart your app instances.
+If this occurs, <%= vars.app_runtime_abbr %> performs the following steps:
 
-1. <%= vars.platform_name %> sends a single `termination signal` to the root process
+1. <%= vars.app_runtime_abbr %> sends a single "termination signal" to the root process
    that your start command runs.
 
-1. <%= vars.platform_name %> waits 10 seconds to allow your app to cleanly shut down any child processes
+1. <%= vars.app_runtime_abbr %> waits 10 seconds to allow your app to cleanly shut down any child processes
    and handle any open connections.
 
-1. After 10 seconds, <%= vars.platform_name %> shuts down your app.
+1. After 10 seconds, <%= vars.app_runtime_abbr %> shuts down your app.
 
 Your app must accept and handle the termination signal to ensure that it shuts down gracefully. To achieve this, the app is expected to do these steps when shutting down:
 
@@ -89,7 +89,7 @@ For an implementation of the expected shutdown behavior in Golang, see the [Samp
 ##  Ignore unnecessary files when pushing
 
 By default, when you push an app, all files in the app's project directory tree are uploaded
-to your <%= vars.platform_name %> instance, except version control and configuration files
+to your <%= vars.app_runtime_abbr %> instance, except version control and configuration files
 or directories with these names:
 
 * `.cfignore`
@@ -119,10 +119,10 @@ The file types you might want to exclude vary, based on the app frameworks you u
 
 Singleton apps might become temporarily unavailable for reasons that include:
 
-* During an upgrade, <%= vars.platform_name %> gracefully shuts down the apps running on each Diego Cell
+* During an upgrade, <%= vars.app_runtime_abbr %> gracefully shuts down the apps running on each Diego Cell
 and restarts them on another Diego Cell. Single app instances might become temporarily unavailable if the replacement instance does not become healthy within the Diego Cell's evacuation timeout. The default timeout is 10 minutes.
 
-* Unexpected faults in <%= vars.platform_name %> system components or underlying infrastructure,
+* Unexpected faults in <%= vars.app_runtime_abbr %> system components or underlying infrastructure,
 such as container-host VMs or IaaS availability zones, might cause lone app instances to disappear
 or become unroutable for a minute or two.
 
@@ -133,7 +133,7 @@ To avoid the risk of an app becoming temporarily unavailable, developers can run
 
 A buildpack consists of bundles of detection and configuration scripts that provide framework
 and runtime support for your apps.
-When you deploy an app that requires a buildpack, <%= vars.platform_name %> installs the buildpack
+When you deploy an app that requires a buildpack, <%= vars.app_runtime_abbr %> installs the buildpack
 on the Diego Cell where the app runs.
 
-For more information, see [Buildpacks](../../buildpacks/index.html).
+For more information, see [Using Classic Buildpacks in Cloud Foundry](../../commercial-buildpacks/using-buildpacks.html).
diff --git a/deploy-apps/push-docker.html.md.erb b/deploy-apps/push-docker.html.md.erb
index 1af1dfaf..bf80c9b9 100644
--- a/deploy-apps/push-docker.html.md.erb
+++ b/deploy-apps/push-docker.html.md.erb
@@ -1,16 +1,16 @@
 ---
-title: Deploying your app with docker
+title: Deploying an app based on a Docker image
 owner: Diego
 ---
 
-You can use the [Cloud Foundry Command Line Interface (cf CLI)](../../cf-cli/install-go-cli.html) to push an app with a new or updated Docker image. <%= vars.app_runtime_first %> then uses the Docker image to create containers for the app.
+You can use the [Tanzu cf CLI](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/install-cf-cli.html) to push an app with a new or updated Docker image. <%= vars.app_runtime_first %> then uses the Docker image to create containers for the app.
 
 <%= vars.using_docker_link %>
 
 
 ##  Requirements
 
-To push apps with Docker, you need:
+To push an app based on a Docker image, you need:
 
 * A <%= vars.app_runtime_abbr %> deployment with Docker support activated. <%= vars.enable_docker_link %>
 
@@ -20,7 +20,6 @@ To push apps with Docker, you need:
 
   * The total size of the Docker image file system layers must not exceed the disk quota for the app. The maximum disk allocation for apps is set by the Cloud Controller. The default maximum disk quota is 2048 MB per app.
     

-    Important
     If the total size of the Docker image file system layers exceeds the disk quota, the app instances do not start.

 
 * The location of the Docker image on Docker Hub or another Docker registry. <%= vars.docker_auth1 %>
@@ -61,16 +60,14 @@ If you do not specify a port in the `EXPOSE` directive, then the app listens on
 
 If you set the `PORT` environment variable via an `ENV` directive in a Dockerfile, <%= vars.app_runtime_abbr %> overrides the value with the system-determined value.
 
-<%= vars.app_runtime_abbr %> supports only one exposed port on the image.
+<%= vars.app_runtime_abbr %> supports multiple exposed ports on an container. By default, routes will be mapped to the first exposed port. Additional ports can be routed to with the `port` property on [Route Destinations](https://v3-apidocs.cloudfoundry.org#the-destination-object)
 
 For more information about the `PORT` environment variable, see the [PORT](environment-variable.html#PORT) section of _<%= vars.app_runtime_abbr %> Environment variables_. For more information about the `EXPOSE` directive, see the [EXPOSE](https://docs.docker.com/engine/reference/builder/#expose) in the Docker documentation.
 
 
 ##  Start command
 
-By default, Docker uses the start command specified in the Docker image. You can override the start command either by using a command-line parameter or by specifying it in a manifest file.
-
-For more information about command-line parameters for `docker start`, see [docker start](https://docs.docker.com/engine/reference/commandline/start/) in the Docker Documentation.
+By default, Docker uses the start command specified by the `CMD` and/or `ENTRYPOINT` directives in the Docker image. You can override the start command either by using the `-c` flag on `cf push` or by setting the `command` property in a manifest file.
 
 
 ##  Push a Docker image from a registry
@@ -162,11 +159,25 @@ Where:
 
 * `USER` is the user name to use for authentication with the registry.
 
-If container registry credentials change, you have two options for an update: either you push the app with the new credentials or you update the latest package with the new credentials using [PATCH /v3/packages](https://v3-apidocs.cloudfoundry.org/version/3.150.0/index.html#update-a-package) and then restage your app.
-Apps require access to the container registry when starting.
+If container registry credentials change, you have three options for an update: 
+
+* push the app with the new credentials
+
+* update the latest package with the new credentials using [PATCH /v3/packages](https://v3-apidocs.cloudfoundry.org/version/3.150.0/index.html#update-a-package) and then restage your app.
+
+* Using Global, Organization, or Space-scoped Registry Credentials, you can update the credentials. The app is automatically updated to use the new credentials when it is scaled, restarted, or rescheduled, and so on.
+
 If you do not update the app with the new credentials, <%= vars.app_runtime_abbr %> fails to start the app.
 When you rotate container credentials, <%= vars.recommended_by %> recommends using a set of two credentials, where the old credentials can be deactivated after all apps are pushed with the new credentials.
 
+###  Basic Authentication with stored Registry Credentials
+
+Admins, Org Managers, and Space Developers can store Docker registry credentials for reuse among developers using Registry Credentials.
+
+When using Registry Credentials, apps can use the stored credentials instead of requiring credentials on each push.
+
+For more information, see [Using stored Registry Credentials to push Docker apps](registry-credentials.html).
+
 ###  Amazon Elastic Container Registry (ECR)
 
 <%= vars.app_runtime_abbr %> supports pushing apps from images hosted on Amazon Web Services ECR, which authenticates with temporary password tokens.
@@ -198,9 +209,11 @@ Running `cf push` with an ECR registry triggers <%= vars.app_runtime_abbr %> to:
 
 1. Use the temporary tokens to retrieve the image.
 
+<%= vars.app_runtime_abbr %> will retrieve new tokens when the app is scaled, restarted, rescheduled, etc. so that the app will continue to run without interruption after the token's 12 hour expiration mark.
+
 ###  Google Container Registry (GCR)
 
-<%= vars.app_runtime %> supports pushing apps from images hosted on Google Container Registry (GCR) service.
+<%= vars.app_runtime_full %> supports pushing apps from images hosted on Google Container Registry (GCR) service.
 This feature requires that you use JSON key-based authentication.
 For more information about JSON key authentication,
 see the [Google Cloud documentation](https://cloud.google.com/container-registry/docs/advanced-authentication#json_key).
@@ -259,7 +272,7 @@ To create a JSON key file and associate it with your project:
 
 ####  Step 2: Deploy the GCP image
 
-To deploy your GCR image using the cf CLI, run:
+To deploy your GCR image using the Tanzu cf CLI, run:
 
 ```
 CF_DOCKER_PASSWORD="$(cat key.json)" cf push APP-NAME --docker-image docker://YOUR-REGISTRY-URL/YOUR-PROJECT/YOUR-IMAGE-NAME --docker-username _json_key`
@@ -278,7 +291,6 @@ Where:
 * The key.json file must point to the file you created earlier.
 
 

-Note
 For information about specifying YOUR-REGISTRY-URL, see Pushing and Pulling Images in the Google Cloud documentation.

 
 
diff --git a/deploy-apps/registry-credentials.html.md.erb b/deploy-apps/registry-credentials.html.md.erb
new file mode 100644
index 00000000..ed5d64ac
--- /dev/null
+++ b/deploy-apps/registry-credentials.html.md.erb
@@ -0,0 +1,142 @@
+---
+title: Using stored Registry Credentials to push Docker apps
+owner: CAPI
+---
+
+Registry Credentials provide a way to share Docker registry credentials across a foundation, organization, or space. Without using Registry Credentials, credentials must be provided for every push when trying to push with an image from a private registry:
+
+```
+CF_DOCKER_PASSWORD=PASSWORD cf push APP-NAME --docker-image REPO/IMAGE:TAG --docker-username USER
+```
+
+By creating Registry Credentials, Admins, Org Managers, and Space Developers can save Docker credentials for reuse among developers.
+
+Registry Credentials can be created at four different levels:
+    
+* Foundation
+* Organization
+* Space
+* App
+
+For example, an Org Manager can create a Registry Credential for an Organization, which will be available to all Apps within that Organization:
+
+```
+cf target -o ORG
+CF_DOCKER_PASSWORD=PASSWORD cf create-org-registry-credential REGISTRY-LOCATION --username USER
+```
+
+After the Registry Credential is created, Space Developers can push apps referencing images in the private registry without providing credentials:
+
+```
+cf push APP-NAME --docker-image REGISTRY-LOCATION/REPO/IMAGE:TAG
+```
+
+##  Creating Registry Credentials for a Foundation, Organization, or Space
+
+Registry Credentials can be created for a Foundation, Organization, or Space using the `cf create-foundation-registry-credential`, `cf create-org-registry-credential`, or `cf create-space-registry-credential` commands.
+
+For example, an Admin can create a Registry Credential for the Foundation:
+
+```
+cf create-foundation-registry-credential REGISTRY-LOCATION --username USER
+```
+
+The password for the Registry Credential can be provided using the `CF_DOCKER_PASSWORD` environment variable. If the environment variable is not set, users are prompted for the password.
+
+- **Foundation-scoped Registry Credentials** are available to all Apps on the platform and can only be created or altered by an Admin.
+- **Organization-scoped Registry Credentials** are available to Apps within the Organization and can only be created or altered by an Org Manager or Admin.
+- **Space-scoped Registry Credentials** are available to all Apps within the Space and can be created or altered by a Space Developer or Admin.
+  
+The `create-org-registry-credential` and `create-space-registry-credential` commands are context sensitive and create Registry Credentials for the Organization or Space that the user is currently targeting. For example, to create a Space-scoped Registry Credential, the user must target the Space first:
+
+```
+cf target -o ORG -s SPACE
+cf create-space-registry-credential REGISTRY-LOCATION --username USER
+```
+
+`REGISTRY-LOCATION` must include a host name, and may include paths and/or ports; for example, `registry.example.com`, `registry.example.com/path`, `registry.example.com/path/to/repo:5000`. Protocols such as `https://` must not be included.
+
+##  Creating Registry Credentials for an app
+
+If an App is pushed with Docker credentials provided, an App-scoped Registry Credential is created automatically for the App, allowing future pushes to omit credentials.
+
+This Registry Credential is only available to the App and cannot be shared with other Apps; it takes precedence over any other Registry Credential for that particular private registry.
+
+Providing new credentials on future pushes updates the App-scoped Registry Credential.
+
+App-scoped Registry Credentials are only created or updated during the 'start' phase of the push. If a push fails during staging (potentially due to incorrect credentials), for example, the App-scoped Registry Credential is not created.
+
+##  Using Registry Credentials
+
+When pushing an app, the Registry Credential is selected by the following order of precedence:
+
+1. App-scoped Registry Credential
+1. Space-scoped Registry Credential
+1. Organization-scoped Registry Credential
+1. Foundation-scoped Registry Credential
+
+Among each level, the Registry Location is extracted from the image reference and used to find a possible matching Registry Credentials. More specific matches are preferred.
+
+For example, if an App is pushed with the image reference `registry.example.com/repo/image:tag`, App-scoped Registry Credentials are searched for in the following order:
+
+1. `registry.example.com/repo`
+1. `registry.example.com`
+1. `example.com`
+
+If no App-scoped Registry Credential is found, the same search is performed for Space-scoped Registry Credentials, then Organization-scoped Registry Credentials, and finally, Foundation-scoped Registry Credentials.
+
+If no matching Registry Credential is found, the app push continues as normal, in case the image is publically accessible.
+
+Images references of the form `REPO/IMAGE:TAG` (i.e. with no registry host name) search for Registry Credentials for `docker.io/libary` or `docker.io`.
+
+##  Deleting Registry Credentials
+
+Registry Credentials can be deleted using the appropriate command:
+
+```
+cf delete-foundation-registry-credential REGISTRY-LOCATION
+cf delete-org-registry-credential REGISTRY-LOCATION
+cf delete-space-registry-credential REGISTRY-LOCATION
+cf delete-app-registry-credential REGISTRY-LOCATION APP-NAME
+```
+
+Deleting a Registry Credential causes any apps that were pushed with that Registry Credential to fail to stage and start in the future, unless other Registry Credentials are made available to them.
+
+##  Updating Registry Credentials
+
+Registry Credentials can be updated using the appropriate command:
+
+```
+cf update-foundation-registry-credential REGISTRY-LOCATION --username USER
+cf update-org-registry-credential REGISTRY-LOCATION --username USER
+cf update-space-registry-credential REGISTRY-LOCATION --username USER
+```
+
+App-scoped Registry Credentials can be updated by pushing the app with new credentials:
+
+```
+cf push APP-NAME --docker-image REGISTRY-LOCATION/REPO/IMAGE:TAG --docker-username USER
+```
+
+Like the creation commands, the password for the Registry Credential can be provided using the `CF_DOCKER_PASSWORD` environment variable. If the environment variable is not set, users are prompted for the password.
+
+Only username or password may be updated; the registry location cannot be changed.
+
+Updating Registry Credentials automatically updates any apps that were pushed with the Registry Credential. This means that apps do not need to be repushed or restarted for the new credentials to take effect. This allows apps to be scaled, restarted, rescheduled, etc., without needing to push the app with the new credentials.
+
+##  Listing Registry Credentials
+
+All Registry Credentials available to the currently targeted Organization and Space can be listed with the `cf registry-credentials` command:
+
+```
+$ cf registry-credentials
+Showing registry credentials available to org 'myorg' and space 'myspace'...
+location                       scope          username            app name
+docker.io/library              app            myuser              myapp
+registry.example.com           space          spaceuser
+registry.example.com/repo      organization   orguser
+docker.io/libary               foundation     docker-user
+registry.example.com/repo      foundation     private-repo-user
+```
+
+If no space or organization is targeted, only Registry Credentials available to the foundation are listed.
diff --git a/deploy-apps/rolling-deploy.html.md.erb b/deploy-apps/rolling-deploy.html.md.erb
index 35e577b9..be6e9729 100644
--- a/deploy-apps/rolling-deploy.html.md.erb
+++ b/deploy-apps/rolling-deploy.html.md.erb
@@ -1,12 +1,11 @@
 ---
-title: Configuring rolling app deployments
+title: Configuring app deployments
 owner: CAPI
 ---
 
-You can use Cloud Foundry Command Line Interface (cf CLI) commands
-or the Cloud Foundry API (CAPI) to push your apps to <%= vars.app_runtime_first %> using a rolling deployment.
+This page describes how to use the Tanzu cf CLI or API (CAPI) to push apps to <%= vars.app_runtime_first %> using rolling deployment or canary deployment strategies, which update apps safely and avoid downtime.
 
-For information about the traditional method for addressing app downtime while pushing app updates,
+For information about the older method for avoiding app downtime while pushing app updates,
 see [Using blue-green deployment to reduce downtime and risk](./blue-green.html).
 
 For more information about CAPI, see the
@@ -15,15 +14,245 @@ For more information about CAPI, see the
 
 ##  Prerequisites
 
-The procedures in this topic require one of the following:
+The procedures in this topic require Tanzu cf CLI v10 or later.
+
If you are preparing a canary deployment, you need CAPI V3.173.0 or later.
 
-* **cf CLI v7:** Install cf CLI v7.
+##  How Deployment Strategies Work
 
-* **cf CLI v6:** If you use cf CLI v6:
-  * You must install cf CLI v6.40 or later.
-  * The rolling deployment feature must be activated for your deployment. <%= vars.zdt_enable %>
+Cloud Foundry provides two different strategies for deployments:
 
-* **CAPI V3:** If you use CAPI V3, you must install the cf CLI.
+* A **Rolling** deployment brings up one or more web processes for the new app version, with the number set by `max-in-flight`, which defaults to 1. After those instances report as healthy and routable, it brings down the same number of instances of the old version. The deployment repeats this process to replace all web process instances and then updates all old non-web processes.
+* A **Canary** deployment brings up one or more web processes for the new app version, defaulting to one. It then pauses to let app operators or developers evaluate the health of a new version instances. App operators can then choose to either `cancel` or `continue` the deployment. When the deployment is continued, the canary deployment proceeds in the same way as a rolling deployment.
+  * To gradually increase instance counts and check app health in multiple steps, the Tanzu cf CLI supports an `--instance-steps` option that sets a series of increasing instance counts.
+
+Each rolling or canary deployment increments the `revision` count for the new app deployment, as listed by the `cf revisions` command.
+
+The following sections describe the rolling and canary deployment strategies and their limitations.
+
+###  Rolling Deployments
+
+This section describes pushing an app with the rolling deployment strategy.
+
+1. The `cf push APP-NAME --strategy rolling` command:
+    1. Stages the updated app package.
+    2. Creates a droplet with the updated app package.
+    3. Creates a deployment with the new droplet and any new configuration.
+        * This starts up to `max_in_flight` processes that shares the route with the old process.
+        * If you run `cf app` on your app at this point, you see multiple `web` processes.
+        

+        For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation.
+
+2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the
+background, updating deployments as follows:
+    1. Adds up to `max_in_flight` instances of the new web process and removes instances from the old web process. This step repeats until the new web process reaches the required number of instances.
+        

+        This happens only if all instances of the new web process are running.

+    2. Removes the old web process. The new web process now fully replaces the old web process.
+    3. Restarts all non-web processes of the app.
+    4. Sets the deployment to `DEPLOYED`.
+
+###  Canary Deployments
+
+This section describes pushing an app with the default canary deployment strategy, without specifying specific step weights as described in [Canary Deployments with Step Weights](#canary-step).
+
+1. The `cf push APP-NAME --strategy canary` command:
+    1. Stages the updated app package.
+    2. Creates a droplet with the updated app package.
+    3. Creates a deployment with the new droplet and any new configuration.
+    

+    For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation.
+
+2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the
+background, updating deployments as follows:
+    1. Adds one instance of the new web process (the `canary` instance).
+        * This process shares routes with the old process.
+        * If you run `cf app` on your app at this point, you see multiple `web` processes.
+    2. Sets the deployment to `PAUSED`.
+
+1. After validating that the canary instance is running as expected, execute the command `cf continue-deployment APP-NAME`:
+    * Changes the deployment reason to `DEPLOYING` and resumes following the same process as a rolling deployment.
+
+2. After the command changes the status of the deployment, the `cc_deployment_updater` BOSH job runs in the
+background, updating deployments as follows:
+    1. Adds MaxInFlight number of instances (**by default it is 1**) of the new web process and removes MaxInFlight number of instance from the old web process. This step repeats until the new web process reaches the required number of instances.
+        

+        This happens only if all instances of the new web process are running.

+    2. Removes the old web process. The new web process now fully replaces the old web process.
+    3. Restarts all non-web processes of the app.
+    4. Sets the deployment to `DEPLOYED`.
+
+###  Canary Deployments with Step Weights
+
+By default, as described in [Canary Deployments](#canary), when you push an app with the canary deployment strategy, the process pauses after it deploys one canary instance, and you manually continue as described in [Continue a canary deployment](#continue) to update the remaining instances to the full-scale deployment.
+
+To run a canary deployment more gradually, you can pass a series of step weights to the `--instance-steps` option of `cf push`.
+
+  - The series specifies increasing numbers of canary instances to deploy.
+    - The deployment will pause after each step, allowing you to manually [continue](#continue) the deployment and proceed to the next step, or [cancel](#cancel) the deployment.
+    - Each value represents a **percentage** or **weight** of the web process's instances of the web process to be rolled out as canary instances.
+  - Separate step weights with commas and without spaces, for example `5,10,20`.
+  - Continuing after the last canary step proceeds to the full-scale deployment.
+  - As with the default canary deployment process, a rolling deployment strategy updates instances to the new instance count at each step.
+
+For example, to update gradually in four steps, running 5, 10, and 20 canary instances before replacing all running instances of an app:
+
+  ```
+  cf push APP-NAME --strategy canary --instance-steps 5,10,20
+  ```
+
+####  Detailed Example
+
+Steps are configured as a percentage of instances rather than as an explicit instance value. This allows the deployment definition to be independent of the number of instances used by a process.
+
+**Cloud Controller matches a step weight to the nearest non-zero instance number, rounding down.**
+
+For example, take an application with 10 instances and the following step configuration:
+
+```
+cf push APP-NAME --strategy canary --instance-steps 1,20,45,80,100
+```
+
+This results in the following deployment plan:
+
+

   

   

     --no-routeAll declared routes are ignored. In cf CLI v7, this flag no longer unbinds all existing routes associated with the app.All declared routes are ignored. This flag does not unbind all existing routes associated with the app.
   

   

     --random-route

+  
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+  
+   
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+  
+  
+    
+    
+    
+    
+    
+  
+
StepStep WeightOriginal InstancesCanary InstancesActual Weighting
Pre-deployn/a1000
11%1019%
220%9218%
345%6545%
480%3872%
5100%010100%
Post-deployn/a010100%

+
+A **Step Weight** of `100` allows app operators to use the `cancel-deployment` command even after all instances have been replaced.
+
+

+The cancel command is designed to revert the app to its
+original state as quickly as possible and does not guarantee zero downtime.
+
It is important to note that changes
+to environment variables and service bindings are not reverted.

+
+###  Testing Canary Deployments
+
+To test an in-progress canary deployment, you can route HTTP requests to the canary process, or to an individual canary instance using the `X-Cf-Process-Instance` header, as described in [HTTP headers for process instance routing](../../concepts/http-routing.html#process-instance-routing).
+
+Alternatively, you can use session affinity to force a particular client to persistently make requests to a canary instance as described in [Session affinity](../../concepts/http-routing.html#sessions).
+
+###  Limitations
+
+The following table describes the limitations when using these deployments.
+
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
LimitationDescription
Multiple app versionsDuring a deployment, <%= vars.app_runtime_abbr %> serves both the old and new version of your app at the
+    same route. This can lead to user issues if you push API changes that are not backwards-compatible.
Database migrationsDeployments do not handle database migrations. Migrating an app database when the existing
+    app is not compatible with the migration can result in downtime.
Non-web processesDeployments only run web processes through the update sequence described
+    earlier. The commands restart worker and other non-web processes in bulk after updating all web
+    processes.


+		The CAPI V3 API introduces the concept of processes as runnable units of an app. Each app has a
+    web process by default. You can specify additional processes with a Procfile, and in some cases
+    buildpacks create additional processes. For more information about processes, see
+    Processes in the CAPI V3
+    documentation.
QuotasPushing updates to your app using a deployment strategy creates up to max_in_flight new instances (defaults to 1).
+    Additionally, canary deployments use an extra instance when pausing with the canary instance deployed.
+    If you lack sufficient quota, the deployment fails. Administrators might need to increase quotas to accommodate deployments.
Simultaneous apps when interrupting a pushIf you push an app before your previous push command for the same app has completed, your
+    first push gets interrupted. Until the last deployment completes, there might be many versions
+    of the app running at the same time. Eventually, the app runs the code from your most recent
+    push.
V3 APIsDuring a rolling deploy for an app, requests to the V3 APIs for scaling or updating a process fail with an error message
+    like Cannot scale this process while a deployment is in flight. For more information, see Scale a process
+    or Update a process in the CAPI V3 documentation.
New or stopped applications
+      When pushing an application for the first time, or if the app is stopped, no deployment strategy is used and all application instances are started immediately.
+    
Evaluating the canary instance
+      Because the current processes share the same route, the best way to validate that traffic is reaching the canary instance is by looking at the logs.
+      If app revision logging is enabled, the logs for all instances will be tagged with process_id and revision_version values. e.g. APP/REV/4/PROC/WEB/1
+      

+      

+      Retrieve the logs by running the Tanzu cf CLI command cf logs APP_NAME.
+    

 
 
 ##  Commands
@@ -32,174 +261,185 @@ This section describes the commands for working with rolling app deployments.
 
 ###  Deploy an app
 
-To deploy an app without incurring downtime:
-
 

-Caution
 Review the limitations of this feature before running the command. For more information, see
 Limitations.

 
-* **For cf CLI v7, run:**
+To deploy an app without incurring downtime:
 
-    ```
-    cf push APP-NAME --strategy rolling
-    ```
-    Where `APP-NAME` is the name that you want to give your app.
+Run:
 
-    

-    Note
-    cf CLI v7 exits when one instance of each process is healthy.
-    It also includes a --no-wait flag on push for users who don't want to wait
-    for the operation to complete.
-    cf push used with the --no-wait flag exits as soon as one instance is healthy.
-    

+```
+cf push APP-NAME --strategy rolling
+```
 
-    If the deployment stops and doesn't restart, cancel it and run it again as described in an earlier step.
-    To cancel, see [Cancel a deployment](#cancel).
+Where `APP-NAME` is the name that you want to give your app.
 
-* **For cf CLI v6, run:**
+

+Tanzu cf CLI exits when one instance of each process is healthy.
+It also includes a --no-wait flag for users who don't want to wait
+for the operation to complete.
+When cf push is used with the --no-wait flag, the process exits as soon as one instance is healthy.
+

+
+If the deployment stops and doesn't restart, cancel it and run it again as described in an earlier step.
+To cancel, see [Cancel a deployment](#cancel).
+
+#### For CAPI V3.173.0 or later
+
+Run:
+
+```
+cf push APP-NAME --strategy STRATEGY --max-in-flight MAX_IN_FLIGHT
+```
+
+Where:
+
+
+#### For CAPI V3
+
+1. Log in to the Tanzu cf CLI.
 
     ```
-    cf v3-zdt-push APP-NAME
+    cf login
     ```
-    Where `APP-NAME` is the name that you want to give your app.
 
-    

-    Important
-    This command is experimental and unsupported. Upgrade to cf CLI v7 (Upgrading to cf CLI v7) or or cf CLI v8 (Upgrading to cf CLI v8).
-    

+2. Create an empty app by running the following `curl` command  with `POST /v3/apps`. 
Record the
+app GUID from the output.
 
-* **For CAPI V3:**
-    1. Log in to the cf CLI.
+    ```
+    cf curl /v3/apps \
+      -X POST \
+      -H "Content-type: application/json" \
+      -d '{
+        "name": "APP-NAME",
+        "relationships": {
+          "space": {
+            "data": {
+              "guid": "SPACE-GUID"
+            }
+          }
+        }
+      }'
+    ```
 
-        ```
-        cf login
-        ```
-    2. Create an empty app by running the following `curl` command  with `POST /v3/apps`. Record the
-    app GUID from the output.
+    Where:
 
-        ```
-        cf curl /v3/apps \
-          -X POST \
-          -H "Content-type: application/json" \
-          -d '{
-            "name": "APP-NAME",
-            "relationships": {
-              "space": {
-                "data": {
-                  "guid": "SPACE-GUID"
-                }
-              }
-            }
-          }'
-        ```
-
-        Where:
-        
-    3. Create a package with the following `curl` command with `POST /v3/packages`. Record the package
-    GUID from the output.
-
-        ```
-        cf curl /v3/packages \
-          -X POST \
-          -H "Content-type: application/json" \
-          -d '{
-            "type": "bits",
-            "relationships": {
-              "app": {
-                "data": {
-                  "guid": "APP-GUID"
-                }
-              }
-            }
-          }'
-        ```
-        Where `APP-GUID` is the app GUID that you recorded in an earlier step. This app GUID is a
-        unique identifier for your app.
-    4. Upload the package bits by running the following `curl` command with
-    `POST /v3/packages/PACKAGE-GUID/upload`.
-
-        ```
-        cf curl /v3/packages/PACKAGE-GUID/upload \
-        -X POST \
-        -F bits=@"PACKAGED-APP" \
-        ```
-
-        Where:
-        
-    5. Create the build by running the following `curl` command with `POST /v3/builds`. Record the
-    droplet GUID from the output.
-
-        ```
-        cf curl /v3/builds \
-          -X POST \
-          -H "Content-type: application/json" \
-          -d '{
-            "package": {
-               "guid": PACKAGE-GUID"
-            }
-          }'
-        ```
-        Where `PACKAGE-GUID` is the package GUID that you recorded in an earlier step.
-    6. Deploy your app by running the following `curl` command with `POST /v3/deployments`. To verify
-    the status of the deployment or take action on the deployment, record the deployment GUID from the
-    output.
-
-        ```
-        cf curl /v3/deployments \
-        -X POST \
-        -H "Content-type: application/json" \
-        -d '{
-          "droplet": {
-            "guid": "DROPLET-GUID"
-          },
-          "strategy": "rolling",
-          "relationships": {
-            "app": {
-              "data": {
-                "guid": "APP-GUID"
-              }
+    
+
+1. Create a package with the following `curl` command with `POST /v3/packages`. Record the package
+GUID from the output.
+
+    ```
+    cf curl /v3/packages \
+      -X POST \
+      -H "Content-type: application/json" \
+      -d '{
+        "type": "bits",
+        "relationships": {
+          "app": {
+            "data": {
+              "guid": "APP-GUID"
             }
           }
-        }'
-        ```
-        Where `DROPLET-GUID` and `APP-GUID` are the GUIDs that you recorded in earlier steps.
+        }
+      }'
+    ```
 
-For more information about this command, see [How it works](#how-it-works).
+    Where `APP-GUID` is the app GUID that you recorded in an earlier step. This app GUID is a
+    unique identifier for your app.
 
-###  Cancel a deployment
+1. Upload the package bits by running the following `curl` command with
+`POST /v3/packages/PACKAGE-GUID/upload`.
+
+    ```
+    cf curl /v3/packages/PACKAGE-GUID/upload \
+    -X POST \
+    -F bits=@"PACKAGED-APP" \
+    ```
+
+    Where:
 
-To stop the deployment of an app that you pushed:
+    
 
-* **For cf CLI v7, run:**
+1. Create the build by running the following `curl` command with `POST /v3/builds`. Record the
+droplet GUID from the output.
 
     ```
-    cf cancel-deployment APP-NAME
+    cf curl /v3/builds \
+      -X POST \
+      -H "Content-type: application/json" \
+      -d '{
+        "package": {
+          "guid": PACKAGE-GUID"
+        }
+      }'
     ```
-    Where `APP-NAME` is the name of the app.
 
-* **For cf CLI v6, run:**
+    Where `PACKAGE-GUID` is the package GUID that you recorded in an earlier step.
+
+1. Deploy your app by running the following `curl` command with `POST /v3/deployments`. To verify
+the status of the deployment or take action on the deployment, record the deployment GUID from the
+output.
 
     ```
-    cf v3-cancel-zdt-push APP-NAME
+    cf curl /v3/deployments \
+    -X POST \
+    -H "Content-type: application/json" \
+    -d '{
+      "droplet": {
+        "guid": "DROPLET-GUID"
+      },
+      "strategy": STRATEGY,
+      "options": {
+        "max_in_flight": MAX_IN_FLIGHT
+      },
+      "relationships": {
+        "app": {
+          "data": {
+            "guid": "APP-GUID"
+          }
+        }
+      }
+    }'
     ```
-    Where `APP-NAME` is the name of the app.
 
-    

-    Important
-    This command is experimental and unsupported. Upgrade to cf CLI v7 (Upgrading to cf CLI v7) or or cf CLI v8 (Upgrading to cf CLI v8).
+    Where:
+
+    

+
+For more information about this command, see [How Deployment Strategies Work](#how-deployment-strategies-work).
+
+###  Cancel a deployment
+
+To stop the deployment of an app that you pushed, run:
+
+    ```
+    cf cancel-deployment APP-NAME
+    ```
+
+    Where `APP-NAME` is the name of the app.
 
 * **For CAPI V3, run:**
 
     ```
     cf curl /v3/deployments/DEPLOYMENT-GUID/actions/cancel" -X POST
     ```
+
     Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the
     CAPI procedure in [Deploy an app](#deploy).
 
@@ -209,34 +449,59 @@ This reverts the app to its state from before the deployment started by:
 * Removing any deployment artifacts
 * Resetting the `current_droplet` on the app
 
-

-Note
+

 The cancel command is designed to revert the app to its
-original state as quickly as possible and does not guarantee zero downtime. Additionally, changes
-to environment variables and service bindings will not be reverted. 

+original state as quickly as possible and does not guarantee zero downtime.
+
It is important to note that changes
+to environment variables and service bindings are not reverted.

+
+###  Continue a canary deployment
+
+To finish a canary deployment after the deployment has paused and the canary instance has been validated:
+
+    ```
+    cf continue-deployment APP-NAME
+    ```
+    Where `APP-NAME` is the name of the app.
+
+* **For CAPI V3, run:**
+
+    ```
+    cf curl /v3/deployments/DEPLOYMENT-GUID/actions/continue" -X POST
+    ```
+    Where `DEPLOYMENT-GUID` is the GUID of the deployment that you recorded after following the
+    CAPI procedure in [Deploy an app](#deploy).
+
+This continues the deployment of the app, following the same process as a rolling deployment.
 
 ###  Restart an app
 
-To restart your app without downtime, run the appropriate command. Restart an app to apply
-configuration updates that require a restart, such as environment variables or service bindings.
+Restart your app to apply configuration updates that require a restart, such as environment variables or service bindings.
 
-* **For cf CLI v7, run:**
+To restart your app without downtime, run the appropriate command as shown here. Run:
 
     ```
-    cf restart APP-NAME --strategy rolling
+    cf restart APP-NAME --strategy STRATEGY
     ```
-    Where `APP-NAME` is the name of the app.
 
-* **For cf CLI v6, run:**
+    Where:
+    
+
+* **For CAPI V3.173.0 or later, run:**
 
     ```
-    cf v3-zdt-restart APP-NAME
+    cf restart APP-NAME --strategy STRATEGY --max-in-flight MAX_IN_FLIGHT
     ```
-    Where `APP-NAME` is the name of the app.
 
-    

-    Important
-    This command is experimental and unsupported. Upgrade to cf CLI v7 (Upgrading to cf CLI v7) or or cf CLI v8 (Upgrading to cf CLI v8).
+    Where:
+    

 
 * **For CAPI V3, run:**
 
@@ -246,119 +511,37 @@ configuration updates that require a restart, such as environment variables or s
     -H "Content-type: application/json" \
     -d '{
       "droplet": {
-        "guid": "DROPLET-GUID"
+        "guid": DROPLET-GUID
+      },
+      "strategy": STRATEGY,
+      "options": {
+        "max_in_flight": MAX_IN_FLIGHT
       },
-      "strategy": "rolling",
       "relationships": {
         "app": {
           "data": {
-            "guid": "APP-GUID"
+            "guid": APP-GUID
           }
         }
       }
     }'
     ```
-    Where `DROPLET-GUID` and `APP-GUID` are the GUIDs that you recorded in earlier steps.
 
+    Where:
+      
 
-##  How it works
 
-This section describes the rolling deployments and their limitations.
+##  View the status of deployments
 
-###  Rolling deployment
+You can use CAPI to view the status of deployments.
 
-This section describes pushing an app with a rolling deployment strategy.
+To view the status of a deployment:
 
-1. The `cf push APP-NAME --strategy rolling` command:
-  1. Stages the updated app package.
-  2. Creates a droplet with the updated app package.
-  3. Creates a deployment with the new droplet and any new configuration.
-      * This starts a new process with one instance that shares the route with the old process.
-      * Now, if you run `cf app` on your app, you see multiple `web` processes.
-    

-    For more information about the deployment object, see the [Deployments](http://v3-apidocs.cloudfoundry.org/index.html#deployments) section of the CAPI V3 documentation.
-
-2. After the command creates the deployment, the `cc_deployment_updater` BOSH job runs in the
-background, updating deployments as follows:
-    1. Adds another instance of the new web process and removes an instance from the old web process. This step repeats until the new web process reaches the required number of instances.
-        

-        Important
-        This happens only if all instances of the new web process are running.

-    2. Removes the old web process. The new web process now fully replaces the old web process.
-    3. Restarts all non-web processes of the app.
-    4. Sets the deployment to `DEPLOYED`.
-
-###  Limitations
-
-The following table describes the limitations of when using rolling deployments.
-
-
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-  
-    
-    
-  
-
LimitationDescription
App manifestsThe cf v3-zdt-push command does not support providing an app manifest with the
-    -f flag. If you have a manifest.yml file in your app directory, it is
-    ignored. This limitation only applies to cf CLI v6.
SSH to app instancesPushing updates to your app with a cf v3-zdt-push command causes the new web process
-    and app GUID to mismatch. cf ssh does not handle this scenario. You must use the
-    cf v3-ssh command instead. This limitation only applies to cf CLI v6.
Multiple app versionsDuring a deployment, <%= vars.app_runtime_abbr %> serves both the old and new version of your app at the
-    same route. This can lead to user issues if you push backwards-incompatible API changes.
Database migrationsDeployments do not handle database migrations. Migrating an app database when the existing
-    app is not compatible with the migration can result in downtime.
Non-web processesRolling deployments only run web processes through the rolling update sequence described
-    earlier. The commands restart worker and other non-web processes in bulk after updating all web
-    processes.


-		The CAPI V3 API introduces the concept of processes as runnable units of an app. Each app has a
-    web process by default. You can specify additional processes with a Procfile, and in some cases
-    buildpacks create additional processes. For more information about processes, see
-    Processes in the CAPI V3
-    documentation.
QuotasPushing updates to your app using a rolling deployment strategy creates an extra instance
-    of your app. If you lack sufficient quota, the deployment fails. Administrators might need to increase
-    quotas to accommodate rolling deployments.
Simultaneous apps when interrupting a pushIf you push app before your previous push command for the same app has completed, your
-    first push gets interrupted. Until the last deployment completes, there might be many versions
-    of the app running at the same time. Eventually, the app runs the code from your most recent
-    push.
V3 APIsDuring a rolling deploy for an app, requests to the V3 APIs for scaling or updating a process fail with an error message
-    like Cannot scale this process while a deployment is in flight.. For more information, see Scale a process
-    or Update a process in the CAPI V3 documentation.

-
-
-##  View the status of rolling deployments
-
-You can use CAPI to view the status of rolling deployments.
-
-To view the status of a rolling deployment:
-
-1. Log in to the cf CLI:
+1. Log in to the Tanzu cf CLI:
 
     ```
     cf login
@@ -369,6 +552,7 @@ To view the status of a rolling deployment:
     ```
     cf app APP-NAME --guid
     ```
+
     Where `APP-NAME` is the name of the app.
 
 1. Find the deployment for that app by running:
@@ -377,16 +561,16 @@ To view the status of a rolling deployment:
     cf curl GET /v3/deployments?app_guids=APP-GUID&status_values=ACTIVE
     ```
     Where `APP-GUID` is the GUID of the app. Deployments are listed in chronological order, with
-    the latest deployment displayed as the last in a list.
+    the latest deployment displayed as the last in the list.
 
 1. Run:
 
     ```
     cf curl GET /v3/deployments/DEPLOYMENT-GUID
     ```
-    Where `DEPLOYMENT-GUID` is the GUID of the rolling deployment.
+    Where `DEPLOYMENT-GUID` is the GUID of the deployment.
 
-`cf curl GET /v3/deployments/DEPLOYMENT-GUID` returns these status properties for rolling deployments:
+The `cf curl GET /v3/deployments/DEPLOYMENT-GUID` command returns the following status properties:
 
 * `status.value`: Indicates if the deployment is `ACTIVE` or `FINALIZED`.
 
@@ -401,14 +585,23 @@ The following table describes the possible values for the `status.value` and `st
 properties:
 
 
-  
-  
-  
+  
+    
+      
+      
+      
+    
+  
+  
+    
+    
+    
+  
@@ -417,7 +610,7 @@ properties:
   
-    
+    
@@ -427,8 +620,8 @@ properties:
   
-    
@@ -437,3 +630,15 @@ properties:
     
status.valuestatus.reasonDescription
status.valuestatus.reasonDescription

   

     ACTIVE
     DEPLOYING
     The deployment is deploying.
   
ACTIVEPAUSEDThe deployment is paused waiting for the user to continue with the deployment. Used only for canary Deployments.

   

     ACTIVE
     CANCELLING

     FINALIZED
     DEPLOYEDThe deployment was deployed.The deployment is complete.
   

   

     FINALIZED

     FINALIZED
     SUPERSEDEDThe deployment was stopped and did not finish deploying because there was another
-    deployment created for the app.
+    The deployment was stopped and did not finish deploying because another
+    deployment was created for the app.
     
   

   
The deployment was created incorrectly by the system.
   

 

+
+##  Scaling with Deployments
+
+Traditionally, all scaling actions are taken at once among all instances. This meant that all instances are restarted at once to enact changes to memory, disk, or other scaling configurations *before* the Deployment starts rolling out new instances.
+
+With CAPI 1.205.0 and cf CLI v8.16.0, Deployments can optionally take scaling parameters when using `cf push`.  For example:
+
+```
+cf push myapp --strategy=rolling -i 5 -m 256M -k 500M
+```
+
+Scaling changes will no longer affect the current instances; they will apply only to new instances created by the deployment, leaving your current application instances unaltered until all instances are replaced by the new instances with the new scaling parameters.
diff --git a/deploy-apps/routes-domains.html.md.erb b/deploy-apps/routes-domains.html.md.erb
index 13aa2a63..481439cb 100644
--- a/deploy-apps/routes-domains.html.md.erb
+++ b/deploy-apps/routes-domains.html.md.erb
@@ -3,15 +3,14 @@ title: Configuring routes and domains
 owner: CF for VMs Networking
 ---
 
-Developers and administrators can configure routes and domains for their apps using the Cloud Foundry Command Line Interface (cf CLI).
-This topic describes how routes and domains work in <%= vars.app_runtime_full %> (<%= vars.app_runtime_abbr %>).
+Developers and administrators can configure routes and domains for their apps using the Tanzu cf CLI.
+This topic describes how routes and domains work in <%= vars.app_runtime_full %>.
 For more information about routing capabilities in <%= vars.app_runtime_abbr %>, see [HTTP routing](../../concepts/http-routing.html).
 
 
 ##  Routes
 
-The <%= vars.app_runtime_abbr %> Gorouter routes requests to apps by associating an app with an address, known as a route. This is known as a _mapping_. Use
-the cf CLI [cf map-route](https://cli.cloudfoundry.org/en-US/cf/map-route.html) command to associate an app and route.
+The <%= vars.app_runtime_abbr %> Gorouter routes requests to apps by associating an app with an address, known as a route. This is known as a _mapping_. Use the Tanzu cf CLI `cf map-route` command to associate an app and route.
 
 The routing tier compares each request with a list of all the routes mapped to apps and attempts to find the best match. For example, the Gorouter makes the following matches for the two routes `example-app.<%= vars.app_domain %>` and `example-app.<%= vars.app_domain %>/products`:
 
@@ -94,40 +93,29 @@ To create an internal route:
       1.app.apps.internal has address 10.255.49.7
       

 
-1. Create a network policy that allows your apps to communicate with each other. By default, apps cannot communicate over the container network. For more
-information, see [Configuring container-to-container networking](cf-networking.html) and the [Cloud Foundry CLI reference guide](https://cli.cloudfoundry.org/en-US/cf/add-network-policy.html).
+1. Create a network policy that allows your apps to communicate with each other. By default, apps cannot communicate over the container network. For more information, see [Configuring container-to-container networking](cf-networking.html). 
For information about the command, enter `cf add-network-policy --help`.
 
 ###  Create a route
 
-When a developer creates a route using the cf CLI, <%= vars.app_runtime_abbr %> determines whether the route is an HTTP or a TCP route based on the domain. To create a HTTP route, a developer must choose an HTTP domain. To create a TCP route, a developer must choose a TCP domain.
+When a developer creates a route using the Tanzu cf CLI, <%= vars.app_runtime_abbr %> determines whether the route is an HTTP or a TCP route based on the domain. To create a HTTP route, a developer must choose an HTTP domain. To create a TCP route, a developer must choose a TCP domain.
 
-Domains in <%= vars.app_runtime_abbr %> provide a namespace from which to create routes. To list available domains for a targeted organization, use the [cf domains](https://cli.cloudfoundry.org/en-US/cf/domains.html) command. For more information about domains, see [Domains](#domains).
+Domains in <%= vars.app_runtime_abbr %> provide a namespace from which to create routes. To list available domains for a targeted organization, use the `cf domains` command. For more information about domains, see [Domains](#domains).
 
 The following sections describe how developers can create HTTP and TCP routes for different use cases.
 
 ####  Create an HTTP route with host name
 
 In <%= vars.app_runtime_abbr %>, a host name is the label that indicates a subdomain of the domain associated with the route. Given a domain
-`<%= vars.app_domain %>`, a developer can create the route `example-app.<%= vars.app_domain %>` by specifying the host name `example-app` with the
-[cf create-route](https://cli.cloudfoundry.org/en-US/cf/create-route.html) command as shown in this example:
+`<%= vars.app_domain %>`, a developer can create the route `example-app.<%= vars.app_domain %>` by specifying the host name `example-app` with the `cf create-route` command, as shown in this example:
 
-* **cf CLI v7**
-  
-  $ cf create-route <%= vars.app_domain %> --hostname example-app
-  Creating route example-app.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

-
-  

-  Important
-  The cf CLI v7 create-route command does not require the space as an argument. It uses the space you are targeting.

+
+$ cf create-route <%= vars.app_domain %> --hostname example-app
+Creating route example-app.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
+OK
+

 
-* **cf CLI v6**
-  
-  $ cf create-route example-space <%= vars.app_domain %> --hostname example-app
-  Creating route example-app.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

+

+The Tanzu cf CLI create-route command does not require the space as an argument. It uses the space you are targeting.

 
 This command instructs <%= vars.app_runtime_abbr %> to only route requests to apps mapped to this route for these URLs:
 
@@ -143,20 +131,13 @@ This approach creates a route with the same address as the domain itself and is
 Domains](#private-domains) .
 
 A developer can create a route from the domain `<%= vars.private_app_domain %>` with no host name with the
-[cf create-route](https://cli.cloudfoundry.org/en-US/cf/create-route.html) command:
+`cf create-route` command:
 
-* **cf CLI v7**
-  
-  $ cf create-route <%= vars.private_app_domain %>
-  Creating route <%= vars.private_app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

-* **cf CLI v6**
-  
-  $ cf create-route example-space <%= vars.private_app_domain %>
-  Creating route <%= vars.private_app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

+
+$ cf create-route <%= vars.private_app_domain %>
+Creating route <%= vars.private_app_domain %> for org example-org / space example-space as username@example.com...
+OK
+

 
 If DNS is configured correctly, this command instructs <%= vars.app_runtime_abbr %> to route requests to apps mapped to this route from these URLs:
 
@@ -171,18 +152,11 @@ If there are no other routes for the domain, requests to any subdomain, such as
 A developer can also create routes for subdomains with no host names. The following command creates a route from the subdomain
 `foo.<%= vars.private_app_domain %>`:
 
-* **cf CLI v7**
-  
-  $ cf create-route foo.<%= vars.private_app_domain %>
-  Creating route foo.<%= vars.private_app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

-* **cf CLI v6**
-  
-  $ cf create-route example-space foo.<%= vars.private_app_domain %>
-  Creating route foo.<%= vars.private_app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

+
+$ cf create-route foo.<%= vars.private_app_domain %>
+Creating route foo.<%= vars.private_app_domain %> for org example-org / space example-space as username@example.com...
+OK
+

 
 If DNS is configured for this subdomain, this command instructs <%= vars.app_runtime_abbr %> to route requests to apps mapped to this route from these URLs:
 
@@ -198,18 +172,11 @@ An app mapped to a wildcard route acts as a fallback app for route requests if t
 
 A developer can create a wildcard route from the domain `foo.<%= vars.app_domain %>` by running:
 
-* **cf CLI v7**
-  
-  $ cf create-route foo.<%= vars.app_domain %> --hostname '*'
-  Creating route *.foo.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

-* **cf CLI v6**
-  
-  $ cf create-route example-space foo.<%= vars.app_domain %> --hostname '*'
-  Creating route *.foo.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

+
+$ cf create-route foo.<%= vars.app_domain %> --hostname '*'
+Creating route *.foo.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
+OK
+

 
 If a client sends a request to `http://app.foo.<%= vars.app_domain %>` by accident, attempting to reach `example-app.foo.<%= vars.app_domain %>`,
 <%= vars.app_runtime_abbr %> routes the request to the app mapped to the route `*.foo.<%= vars.app_domain %>`.
@@ -220,43 +187,21 @@ Developers can use paths to route requests for the same host name and domain to
 
 A developer can create three routes using the same host name and domain in the space `example-space` by running:
 
-* **cf CLI v7**
-  
-  $ cf create-route <%= vars.app_domain %> --hostname store --path products
-  Creating route store.<%= vars.app_domain %>/products for org example-org / space example-space as username@example.com...
-  OK
-  

-  
-  $ cf create-route <%= vars.app_domain %> --hostname store --path orders
-  Creating route store.<%= vars.app_domain %>/orders for org example-org / space example-space as username@example.com...
-  OK
-  

-  
-  $ cf create-route <%= vars.app_domain %> --hostname store
-  Creating route store.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

-
-* **cf CLI v6**
-  

-  Important
-  To create a route without a path using cf CLI v6, you must run the commands in this order: Create the route without a path, and then create any routes with a path. If you do not need a route without a path, then this sequence is not required.

-
-  
-  $ cf create-route example-space <%= vars.app_domain %> --hostname store
-  Creating route store.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
-  OK
-  

-  
-  $ cf create-route example-space <%= vars.app_domain %> --hostname store --path products
-  Creating route store.<%= vars.app_domain %>/products for org example-org / space example-space as username@example.com...
-  OK
-  

-  
-  $ cf create-route example-space <%= vars.app_domain %> --hostname store --path orders
-  Creating route store.<%= vars.app_domain %>/orders for org example-org / space example-space as username@example.com...
-  OK
-  

+
+$ cf create-route <%= vars.app_domain %> --hostname store --path products
+Creating route store.<%= vars.app_domain %>/products for org example-org / space example-space as username@example.com...
+OK
+

+
+$ cf create-route <%= vars.app_domain %> --hostname store --path orders
+Creating route store.<%= vars.app_domain %>/orders for org example-org / space example-space as username@example.com...
+OK
+

+
+$ cf create-route <%= vars.app_domain %> --hostname store
+Creating route store.<%= vars.app_domain %> for org example-org / space example-space as username@example.com...
+OK
+

 
 The developer can then map the new routes to different apps by following the procedure in [Map a route to your app](#map-route).
 
@@ -271,7 +216,6 @@ If the developer maps the first route with path `products` to the `products` app
 <%= vars.app_runtime_abbr %> attempts to match routes with a path, and then attempts to match host and domain.
 
 

-Important

- Important - To avoid security exposure, ensure that you migrated your apps and custom buildpacks to use the cflinuxfs4 stack based on Ubuntu 22.04 LTS (Jammy Jellyfish). The cflinuxfs3 stack is based on Ubuntu 18.04 (Bionic Beaver), which reaches end of standard support in April 2023.

+ To avoid security exposure, ensure that you migrated your apps and custom buildpacks to use the cflinuxfs4 stack based on Ubuntu 22.04 LTS (Jammy Jellyfish). The cflinuxfs3 stack is based on Ubuntu 18.04 (Bionic Beaver), which reaches end of standard support in April 2023.

diff --git a/push-sub-commands.html.md.erb b/push-sub-commands.html.md.erb index 3fe87273..887bac9e 100644 --- a/push-sub-commands.html.md.erb +++ b/push-sub-commands.html.md.erb @@ -4,7 +4,7 @@ owner: CAPI --- -The Cloud Foundry Command Line Interface (cf CLI) includes commands that provide detailed control over app pushes. When you use these commands, you can follow only some steps of the `cf push` procedure or you can perform specific actions between the steps that are normally part of running `cf push`. +The Tanzu cf CLI includes commands that provide detailed control over app pushes. When you use these commands, you can follow only some steps of the `cf push` procedure or you can perform specific actions between the steps that are normally part of running `cf push`. Here are some example use cases for the sub-step commands: @@ -13,6 +13,7 @@ Here are some example use cases for the sub-step commands: * Calling external services to report audit data during push * Scanning a droplet before deploy * Integrating with a change request system +* Running droplets built on a different Cloud Foundry deployment To support these custom push workflows, Cloud Foundry divides apps into smaller building blocks. @@ -20,71 +21,68 @@ The following table describes the building blocks as resources and lists the com For information about using these commands, see [Example workflows](#example-workflows). -

-Important -The cf CLI v6 commands described in this topic are experimental and unsupported, but are supported in cf CLI v7. The latest supported cf CLI release is cf CLI v8. To upgrade to cf CLI v7, see Upgrading to cf CLI v7. To upgrade to cf CLI v8, see Upgrading to cf CLI v8.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ResourceDescriptionCommand
AppThe top-level resource that represents an app and its configuration.
- For more information, see Apps in the CAPI documentation.		 -
    -
  • cf CLI v6:
    cf v3-create-app
    • -
  • cf CLI v7:
    cf create-app
    • -
-
PackageThe source code that makes up an app.
- For more information, see Packages in the CAPI documentation.		 -
    -
  • cf CLI v6:
    cf v3-create-package
    • -
  • cf CLI v7:
    cf create-package
    • -
-
BuildStaging the app. Creating a build combines a Package with a Buildpack and builds it into an executable resource.
- For more information, see Builds in the CAPI documentation.		 -
    -
  • cf CLI v6:
    cf v3-stage
    • -
  • cf CLI v7:
    cf stage-package
    • -
-
DropletAn executable resource that results from a Build.
- For more information, see Droplet in the CAPI documentation.		 -
    -
  • cf CLI v6:
    cf v3-set-droplet
    • -
  • cf CLI v7:
    cf set-droplet
    • -
-
ManifestA file used when pushing your app to apply bulk configuration to an app and its underlying processes.
- For more information, see Space Manifest in the CAPI documentation.		 -
    -
  • cf CLI v6:
    cf v3-apply-manifest
    • -
  • cf CLI v7:
    cf create-app-manifest, cf apply-manifest
    • -
-
ResourceDescriptionCommands
AppThe top-level resource that represents an app and its configuration.
+ For more information, see Apps in the CAPI documentation.		 +
    +
  • cf app
    • +
  • cf apps
    • +
  • cf create-app
    • +
+
PackageThe source code that makes up an app.
+ For more information, see Packages in the CAPI documentation.		 +
    +
  • cf create-package
    • +
  • cf packages
    • +
+
BuildStaging the app. Creating a build combines a Package with a Buildpack and builds it into an executable resource, called a Droplet.
+ For more information, see Builds in the CAPI documentation.		 +
    +
  • cf stage-package
    • +
+
DropletAn executable resource that results from a Build.
+ For more information, see Droplet in the CAPI documentation.		 +
    +
  • cf download-droplet
    • +
  • cf droplets
    • +
  • cf set-droplet
    • +
+
ManifestA file used when pushing your app to apply bulk configuration to an app and its underlying processes.
+ For more information, see Space Manifest in the CAPI documentation.		 +
    +
  • cf apply-manifest
    • +
  • cf create-app-manifest
    • +
+
@@ -96,35 +94,21 @@ The following sections describe example workflows for working with the `cf push` This example workflow describes how to push an app using sub-step commands instead of `cf push`. -1. Create your app with cf CLI: - * If you are using cf CLI v7, run: - - ``` - cf create-app APP-NAME - ``` - Where `APP-NAME` is the name you give your app. - * If you are using cf CLI v6, run: +1. Create your app with Tanzu cf CLI: - ``` - cf v3-create-app APP-NAME - ``` - Where `APP-NAME` is the name you give your app. + ``` + cf create-app APP-NAME + ``` + Where `APP-NAME` is the name you give your app. 1. From your app directory, create a package for your app. - * If you are using cf CLI v7, run: - ``` - cf create-package APP-NAME - ``` - Where `APP-NAME` is the name of your app. - * If you are using cf CLI v6, run: + ``` + cf create-package APP-NAME + ``` + Where `APP-NAME` is the name of your app. - ``` - cf v3-create-package APP-NAME - ``` - Where `APP-NAME` is the name of your app. - -1. Locate and copy the `package guid` from the output of an earlier step. See the following example output: +1. Locate and copy the `package guid` from the output of an earlier step or by using the `cf packages` command. See the following example output: 
     Uploading and creating bits package for app APP-NAME in org test / space test as admin...
@@ -132,31 +116,18 @@ This example workflow describes how to push an app using sub-step commands inste
      OK
-2. Stage the package you created: - * If you are using cf CLI v7, run: - - ``` - cf stage-package APP-NAME --package-guid PACKAGE-GUID - ``` +1. Stage the package you created: - Where: - - * If you are using cf CLI v6, run: + ``` + cf stage-package APP-NAME --package-guid PACKAGE-GUID + ``` + Where: + - ``` - cf v3-stage APP-NAME --package-guid PACKAGE-GUID - ``` - - Where: - - -3. Locate and copy the `droplet guid` from the output of an earlier step. See the following example output: +3. Locate and copy the `droplet guid` from the output of an earlier step or by using the `cf droplets` command. See the following example output: 
     Staging package for APP-NAME in org test / space test as admin...
@@ -168,60 +139,33 @@ This example workflow describes how to push an app using sub-step commands inste
4. Assign the droplet to your app: - * If you are using cf CLI v7, run: - - ``` - cf set-droplet APP-NAME -d DROPLET-GUID - ``` - Where: - - * If you are using cf CLI v6, run: - - ``` - cf v3-set-droplet APP-NAME -d DROPLET-GUID - ``` - - Where: - + ``` + cf set-droplet APP-NAME DROPLET-GUID + ``` + Where: + 5. Start your app: - * If you are using cf CLI v7, run: - - ``` - cf start APP-NAME - ``` - Where `APP-NAME` is the name of your app. - * If you are using cf CLI v6, run: - ``` - cf v3-start APP-NAME - ``` - Where `APP-NAME` is the name of your app. + ``` + cf start APP-NAME + ``` + Where `APP-NAME` is the name of your app. ### Roll back to a previous droplet This example workflow describes how to roll back to a previous droplet used by your app. You might want to use this, for example, if you update your app and it has a bug that causes it to fail. 1. List the droplets for your app: - * If you are using cf CLI v7, run: - ``` - cf droplets APP-NAME - ``` - Where `APP-NAME` is the name of your app. - * If you are using cf CLI v6, run: - - ``` - cf v3-droplets APP-NAME - ``` - Where `APP-NAME` is the name of your app. + ``` + cf droplets APP-NAME + ``` + Where `APP-NAME` is the name of your app. 1. In the output, locate and copy the second-to-last GUID. @@ -235,61 +179,56 @@ This example workflow describes how to roll back to a previous droplet used by y 0677ad93-9f77-4aaa-9a6b-44da022dcd58 staged Mon 25 Sep 16:44:55 PDT 2018 -2. Stop your app: - * If you are using cf CLI v7, run: - - ``` - cf stop APP-NAME - ``` - - Where `APP-NAME` is the name of your app. - * If you are using cf CLI v6, run: +1. Stop your app: - ``` - cf v3-stop APP-NAME - ``` + ``` + cf stop APP-NAME + ``` - Where `APP-NAME` is the name of your app. + If you wish to avoid incurring downtime when changing your droplet, + consider using [Rolling deployments](./deploy-apps/rolling-deploy.html) + instead of stopping and starting your app. -3. Set the app to use the previous droplet: - * If you are using cf CLI v7, run: +1. Set the app to use the previous droplet: - ``` - cf set-droplet APP-NAME -d PREVIOUS-DROPLET-GUID - ``` + ``` + cf set-droplet APP-NAME PREVIOUS-DROPLET-GUID + ``` + Where: + - Where: - +1. Start your app: - * If you are using cf CLI v6, run: + ``` + cf start APP-NAME + ``` + Where `APP-NAME` is the name of your app. - ``` - cf v3-set-droplet APP-NAME -d PREVIOUS-DROPLET-GUID - ``` +### Downloading and uploading droplets - Where: - +This example workflow describes how to download a built droplet and then push +it to an app. You might want to use this for building apps in one location and +then deploying it elsewhere. For instance, you might use this to promote +built apps from pre-production environments to production environments without +having to re-build the app. -4. Start your app: +1. Download the current droplet for your app: - * If you are using cf CLI v7, run: + ``` + cf download-droplet APP-NAME --path PATH + ``` - ``` - cf start APP-NAME - ``` + Where `APP-NAME` is the name of your app and `PATH` is the file path to download the droplet to. - Where `APP-NAME` is the name of your app. +1. Log in to the desired Cloud Foundry environment and target the organization and space where you want to run the droplet you downloaded. - * If you are using cf CLI v6, run: +1. Push a new or existing app with the downloaded droplet: - ``` - cf v3-start APP-NAME - ``` + ``` + cf push APP-NAME --droplet PATH + ``` - Where `APP-NAME` is the name of your app. + Where `APP-NAME` is the name of your app and `PATH` is the file path to the downloaded droplet. diff --git a/push.html.md.erb b/push.html.md.erb index 1a6d0037..4f3bfb9e 100644 --- a/push.html.md.erb +++ b/push.html.md.erb @@ -1,14 +1,15 @@ --- -title: How to push your app with Cloud Foundry CLI (cf push) +title: How to push your app with Tanzu cf CLI (cf push) owner: cf cli --- These topics contain the procedures for deploying apps with `cf push`: -* [Pushing your app using Cloud Foundry CLI (cf push)](./deploy-apps/deploy-app.html) +* [Pushing your app using Tanzu cf CLI (cf push)](./deploy-apps/deploy-app.html) * [Deploying with app manifests](./deploy-apps/manifest.html) + * [App manifest attribute reference](./deploy-apps/manifest-attributes.html) * [Deploying an app with Docker](./deploy-apps/push-docker.html) @@ -17,12 +18,14 @@ These topics contain the procedures for deploying apps with `cf push`: * [Starting, restarting, and restaging Apps](./deploy-apps/start-restart-restage.html) -* [Pushing your app with multiple buildpacks](../buildpacks/use-multiple-buildpacks.html) +* [Pushing your app with multiple buildpacks](../commercial-buildpacks/use-multiple-buildpacks.html) * [Pushing an app with multiple processes](./multiple-processes.html) * [Running cf push sub-step commands](push-sub-commands.html) +* [Configuring canary app deployments](./deploy-apps/rolling-deploy.html#canary) + * [Configuring rolling app deployments](./deploy-apps/rolling-deploy.html) * [Pushing apps with sidecar processes](./sidecars.html) @@ -37,7 +40,7 @@ For information about troubleshooting when running `cf push`, see [Troubleshooti The following topics provide information about how `cf push` works: -* The [Push](../cf-cli/getting-started.html#push) section of _Getting Started with the cf CLI_. +* For information about pushing apps with the Tanzu cf CLI, see [Tanzu cf CLI documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/standalone-index.html). * [The application container life cycle on Diego architecture](./deploy-apps/app-lifecycle.html) diff --git a/revisions.html.md.erb b/revisions.html.md.erb index de105c34..51bff502 100644 --- a/revisions.html.md.erb +++ b/revisions.html.md.erb @@ -3,34 +3,39 @@ title: Cloud Foundry API app revisions owner: CAPI --- -A revision represents code and configuration used by an app at a specific time. It is a Cloud Foundry API (CAPI) object that can contain references to a droplet, a custom start command, and environment variables. The most recent revision for a running app represents code and configuration running in <%= vars.platform_name %>. +A revision represents code and configuration used by an app at a specific time. It is a Cloud Foundry API (CAPI) object that can contain references to a droplet, a custom start command, and environment variables. The most recent revision for a running app represents code and configuration running in <%= vars.app_runtime_abbr %>. +App revisions do not include any tasks run on the app. For additional information about app revisions, see [Revisions](http://v3-apidocs.cloudfoundry.org/version/release-candidate/#revisions) in the Cloud Foundry API (CAPI) documentation.

-Important CAPI v3 is the recommended API version for revisions. While revisions work with CAPI v2, there are several inconsistencies. For example, revision descriptions for apps with multiple processes can be inaccurate because CAPI v2 does not support apps with multiple processes. Additionally, pushing an app for the first time with revisions in CAPI v2 creates two revisions.

-

-Caution -The app revisions API is experimental, and future releases might have breaking changes.

-## Revisions use cases +## Overview -Some use cases for revisions include: +Every <%= vars.app_runtime_abbr %> app has a name. +When you first deploy an app, <%= vars.app_runtime_abbr %> gives it the revision version number `1`. +When you re-deploy the app under the same name, for example as an update, <%= vars.app_runtime_abbr %> increments its version number and saves the old version. -* **Viewing revisions for an app:** This can help you understand how your app has changed over time. +This saved application history is used by the `revisions` and `revision` CAPI endpoints and Tanzu cf CLI commands to let you: -* **Rolling back to a previous revision:** This allows you to deploy a version of the app that you had running previously without needing to track that previous state yourself or have multiple apps running. When you create a deployment and reference a revision, the revision deploys as the current version of your app. +* **View revisions for an app:** To help you understand how your app has changed over time. -### Events that trigger revisions +* **Roll back to a previous revision:** To deploy a version of the app that you had running previously without needing to track that previous state yourself or have multiple apps running. When roll back an app, the specified revision deploys as the new current version of your app. -Revisions are generated through these events: +> **Note** The `cf revision` command takes a `--version` flag to specify a version number, but the command's output lists the same number as its `revision`. -* A new droplet is created for an app. -* An app's environment variables are changed. -* The custom start command for an app is added or changed. +### When current app revision changes + +The app's revision version number increments when: + +* A new droplet is deployed for an app. +* An app is deployed with `--strategy rolling` or `--strategy canary` as described in [Configuring app deployments](./deploy-apps/rolling-deploy.html). +* An app is deployed with a new environment variables. +* An app is deployed with a new or changed custom start command. * An app rolls back to a prior revision. + - In this case, the newly-running version is identical to the specified old version. By default, CAPI retains a maximum of 100 revisions per app. @@ -49,79 +54,116 @@ Each revision includes a description of what changed in your app at the time the ### Droplet storage considerations -By default, <%= vars.platform_name %> retains the five most recent staged droplets in its droplets bucket. This means that you can roll back to revisions as long as they are using one of those five droplets. Not all revisions include a change in droplet. +By default, <%= vars.app_runtime_abbr %> retains the five most recent staged droplets in its droplets bucket. This means that you can roll back to revisions as long as they are using one of those five droplets. Not all revisions include a change in droplet. -<% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> -Operators can configure <%= vars.platform_name %> to retain more droplets if necessary using the <%= vars.droplet_config %> -<% end %> +Operators can configure <%= vars.app_runtime_abbr %> to retain more droplets if necessary using the <%= vars.droplet_config %> ## View revisions This section describes how to use CAPI endpoints for viewing revisions. -### List revisions for an app +### List revision history for an app -To list revisions for an app: +To list both current and stopped revisions for an app: -1. Retrieve the GUID of the app by running: +* Using the `revisions` command: - ``` - cf app APP-NAME --guid - ``` - Where `APP-NAME` is the name of your app. + ``` + cf revisions APP-NAME + ``` + Where `APP-NAME` is the name of your app. -1. Run: +* Using the `curl` command: - ``` - cf curl /v3/apps/GUID/revisions - ``` - Where `GUID` is the GUID you retrieved in an earlier step. + 1. Retrieve the GUID of the app by running: -### List deployed revisions for an app + ``` + cf app APP-NAME --guid + ``` + Where `APP-NAME` is the name of your app. -Deployed revisions are revisions linked to started processes in an app. To list deployed revisions: + 1. Run: -1. Retrieve the GUID of the app by running: + ``` + cf curl /v3/apps/GUID/revisions + ``` + Where `GUID` is the GUID you retrieved in an earlier step. - ``` - cf app APP-NAME --guid - ``` - Where `APP-NAME` is the name of your app. +### Get an app's current revision(s) -1. Run: +The current revision of an app is its currently-deployed, running revision, linked to started processes. There may be multiple currently running revisions during an active canary or rolling deployment. To list an app's current revision(s): + +* Using the `revision` command: + + ``` + cf revision APP-NAME + ``` + Where `APP-NAME` is the name of your app. + +* Using the `curl` command + + 1. Retrieve the GUID of the app by running: + + ``` + cf app APP-NAME --guid + ``` + Where `APP-NAME` is the name of your app. + + 1. Run: + + ``` + cf curl /v3/apps/GUID/revisions/deployed + ``` + Where `GUID` is the GUID you retrieved in an earlier step. + + When the current app is still deploying or is in a `stopped` state, the command output states, `It is not possible to show which revision is currently deployed.` - ``` - cf curl /v3/apps/GUID/revisions/deployed - ``` - Where `GUID` is the GUID you retrieved in an earlier step. ### Retrieve a revision To retrieve a revision: -1. Run: +* Using the `revision` command: + + ``` + cf revision APP-NAME --version VERSION + ``` + Where `APP-NAME` is the name of your APP and `VERSION` is the revision version. + +* Using the `curl` command: - ``` - cf curl /v3/revisions/GUID - ``` - Where `GUID` is the GUID of the revision. + 1. Run: + + ``` + cf curl /v3/revisions/GUID + ``` + Where `GUID` is the GUID of the revision. ## Roll back to a previous revision To roll back to a previous revision: -1. Retrieve the GUID of the app by running: +* Using the `rollback` command: + + ``` + cf rollback APP-NAME --version VERSION + ``` + Where `APP-NAME` is the name of your APP and `VERSION` is the revision version you want to rollback to. + +* Using `curl` command: - ``` - cf app APP-NAME --guid - ``` - Where `APP-NAME` is the name of your app. + 1. Retrieve the GUID of the app: -1. Retrieve the GUID of the revision. See [Retrieve a revision](#get). + ``` + cf app APP-NAME --guid + ``` + Where `APP-NAME` is the name of your app. -1. Create a deployment using CAPI by running: + 1. Retrieve the GUID of the revision. See [Retrieve a revision](#get). + + 1. Create a deployment using CAPI by running: ``` cf curl v3/deployments \ @@ -148,12 +190,7 @@ To roll back to a previous revision: ## Add metadata to a revision -<% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> - To add metadata to a revision, see [Add metadata to an object](../adminguide/metadata.html). -<% else %> -To add metadata to a revision, see [Cloud Foundry documentation](https://docs.cloudfoundry.org/adminguide/metadata.html). -<% end %> ## Deactivate revisions for an app @@ -163,14 +200,14 @@ To deactivate revisions for an app: 1. Retrieve the GUID of the app by running: - ``` - cf app APP-NAME --guid - ``` - Where `APP-NAME` is the name of your app. + ``` + cf app APP-NAME --guid + ``` + Where `APP-NAME` is the name of your app. 1. Run: - ``` - cf curl /v3/apps/GUID/features/revisions -X PATCH -d '{ "enabled": false }' - ``` - Where `GUID` is the GUID you retrieved in an earlier step. + ``` + cf curl /v3/apps/GUID/features/revisions -X PATCH -d '{ "enabled": false }' + ``` + Where `GUID` is the GUID you retrieved in an earlier step. diff --git a/routing-index.html.md.erb b/routing-index.html.md.erb index e7e898d9..37e392d9 100644 --- a/routing-index.html.md.erb +++ b/routing-index.html.md.erb @@ -7,6 +7,8 @@ These topics contain information about configuring routes and domains: * [Configuring routes and domains](deploy-apps/routes-domains.html) +* [Configuring per-route options](custom-per-route-options.html) + * [Configuring <%= vars.app_runtime_abbr %> to route traffic to apps on custom ports](custom-ports.html) * [Routing HTTP/2 and gRPC traffic to apps](http2-protocol.html) diff --git a/services-index.html.md.erb b/services-index.html.md.erb index 40ce600a..7f2d4885 100644 --- a/services-index.html.md.erb +++ b/services-index.html.md.erb @@ -30,4 +30,4 @@ These topics contain information about managing service instances:
  • User-provided service instances
    • - \ No newline at end of file + diff --git a/services/_using-vol-services.html.md.erb b/services/_using-vol-services.html.md.erb index 6bfc1f30..d80e8ce9 100644 --- a/services/_using-vol-services.html.md.erb +++ b/services/_using-vol-services.html.md.erb @@ -10,7 +10,7 @@ or write to a reliable, persistent file system. Before you can use a volume service with your app, find out if any volume services are available for your app. -1. Log in to the Cloud Foundry Command Line Interface (cf CLI). Run: +1. Log in to the Tanzu cf CLI. Run: ``` cf login @@ -44,7 +44,6 @@ The following sections describe how to mount an external file system to your app To use a volume service deployed by your <%= vars.admin %>, you must first create an instance of the specific volume service that you need.

    -Note You can also bind volume services using an app manifest. However, app manifests do not support bind configuration. To bind a volume service using an app manifest, you must specify bind configuration when you create the service instance. The releases that support this are nfs-volume v1.3.1 and later and smb-volume v1.0.0 and later. For more information, see Services in Deploying with App Manifests.

    To create and bind an instance for the volume service: @@ -83,13 +82,11 @@ To create and bind an instance for the volume service: file permissions can be granted at the app level. If this is not needed, the you can eliminate the performance overhead of mapfs by managing permissions on the NFS server.
    The user specified by uid must have access to the files on the share. When uid and gid are omitted, the app file operations use the UID of the running app process. For buildpack apps, this UID is always 2000. For Docker apps, the effective UID is the same as the UID of the process inside the Docker container, except for root, which is mapped to 4294967294 outside the Docker container.

    - Caution Specifying UID and GID values affects performance because the FUSE file system mapfs is used to translate UID and GID values.

  • (Optional) OPTIONAL-MOUNT-PATH is a JSON string that indicates that the volume must be mounted to a particular path in your app rather than the default path. Choose a path with a root-level directory that already exists in the container, such as /home, /usr, or /var.

    - Important Do not specify a MOUNT-PATH in the /app directory, which is where <%= vars.app_runtime_abbr %> unpacks the droplet. For more information, see Mount a shared volume in the /app directory.

  • @@ -117,7 +114,6 @@ To create and bind an instance for the volume service:
  • (Optional) OPTIONAL-MOUNT-PATH is a JSON string that indicates the volume must be mounted to a particular path within your app rather than the default path. Choose a path with a root-level directory that already exists in the container, such as /home, /usr, or /var.

    - Important Do not specify a MOUNT-PATH within the /app directory, which is where <%= vars.app_runtime_abbr %> unpacks the droplet. For more information, see Mount a shared volume in the /app directory.

    • @@ -232,7 +228,6 @@ This section describes how to use the NFS volume service. Both services offer a single plan called `Existing`.

    -Note NFS is not available on Windows systems.

    ### Create an NFS volume service @@ -251,26 +246,18 @@ To create an NFS volume service using the `Existing` plan of the `nfs` service:
  • SERVICE-INSTANCE-NAME is a name you provide for this NFS volume service instance.
  • SERVER/SHARE is the NFS address of your server and share.

    - Important Omit the : that usually follows the server name in the address.

  • (Optional) NFS-PROTOCOL is the NFS protocol you want to use. For example, to use NFSv4, set the version to 4.1. Valid values are 3, 4.0, 4.1 or 4.2. If you do not specify a version, the protocol version used is negotiated between client and server at mount time. This usually causes the latest available version to be used.
    • - <% if vars.platform_code != "CF" %> +

    - Important - Tanzu Application Service versions shipping with nfs-volume versions v7.1.45 - v7.1.47 or v5.0.55 - 5.0.58 (as of 22 Feb., 2024: 2.11.52 - 2.11.53, 2.13.34 - 2.13.35, 4.0.15 - 4.0.17, 5.0.6 - 5.0.7) do not support specifying NFS version: 3.0. These updated the contained nfs-utils (a dependency of nfs-volume-service) to a newer version that uses stricter option parsing.
    + <%= vars.app_runtime_abbr %> versions shipping with nfs-volume versions v7.1.45 - v7.1.47 or v5.0.55 - 5.0.58 as listed in the <%= vars.segment_runtime_full %> Release notes do not support specifying NFS version: 3.0. These updated the contained nfs-utils (a dependency of nfs-volume-service) to a newer version that uses stricter option parsing.
    NFSv3 does not utilize a MINOR version, but NFSv4 introduced MINOR versions that can be specified.
    This has been mitigated by adding auto-correction logic to the nfsdriver process available with nfs-volume >= v7.1.48 and >= v5.0.59.

    - <% else %> -

    - Important - nfs-volume versions v7.1.45 - v7.1.47 ship with a recent version of nfs-utils (a dependency of nfs-volume-service). Recent versions of nfs-utils have stricter option parsing. This leads to an issue with environments that configured the `vers=3.0` mount option.
    - NFSv3 does not utilize a MINOR version, but NFSv4 introduced MINOR versions that can be specified.
    - This has been mitigated by adding auto-correction logic to the nfsdriver process available with nfs-volume >= v7.1.48.

    - <% end %> + 2. Confirm that the NFS volume service appears in your list of services. Run: @@ -300,13 +287,13 @@ To deploy and bind a sample app: cd ~/workspace ``` ```console - git clone https://github.com/cloudfoundry/persi-acceptance-tests.git + git clone https://github.com/cloudfoundry/cf-acceptance-tests.git ``` -1. Change into the `persi-acceptance-tests/assets/pora/` directory: +1. Change into the `cf-acceptance-tests/assets/pora/` directory: ```console - cd ~/workspace/persi-acceptance-tests/assets/pora + cd ~/workspace/cf-acceptance-tests/assets/pora ``` 1. Push the `pora` test app by running: @@ -338,7 +325,6 @@ To deploy and bind a sample app: while allowing <%= vars.app_runtime_abbr %> to run your app as an arbitrary user. UID and GID must be positive integer values.

    - Important In NFS v2.0.0 and later, uid and gid values of 0 are no longer permissible because of security concerns.

    @@ -390,7 +376,7 @@ This section describes using the NFS volume service. #### Configure LDAP credentials with service instance creation -If your <%= vars.platform_name %> deployment has LDAP activated, you can configure LDAP credentials for your NFS Volume Service instance. +If your <%= vars.app_runtime_abbr %> deployment has LDAP activated, you can configure LDAP credentials for your NFS Volume Service instance. To configure LDAP credentials while creating your NFS Volume Service instance: @@ -456,7 +442,7 @@ To create an SMB volume service:
  • SERVICE-INSTANCE-NAME is a name you provide for this SMB volume service instance.
  • //SERVER/SHARE is the SMB address of your server and share.
  • - (Optional) SMB-VERSION is the SMB protocol version you want to use. For example, to use SMB 2.1, set the version to 2.1. Valid values are 1.0, 2.0, 2.1, or 3.0. If you do not specify a version, the client and server negotiate a protocol version at mount time. The client and server usually select the latest available version. + (Optional) SMB-VERSION is the SMB protocol version you want to use. For example, to use SMB 2.1, set the version to 2.1. Valid values are 1.0, 2.0, 2.1, or 3.0, 3.1.1. If you do not specify a version, the client and server negotiate a protocol version at mount time. The client and server usually select the latest available version. 3.1.1 is supported as of [v3.2.0 smb-volume-release](https://github.com/cloudfoundry/smb-volume-release/releases/tag/v3.2.0).
    • @@ -478,13 +464,13 @@ To deploy and bind a sample app: cd ~/workspace ``` ```console - git clone https://github.com/cloudfoundry/persi-acceptance-tests.git + git clone https://github.com/cloudfoundry/cf-acceptance-tests.git ``` -1. Change into the `persi-acceptance-tests/assets/pora/` directory: +1. Change into the `cf-acceptance-tests/assets/pora/` directory: ```console - cd ~/workspace/persi-acceptance-tests/assets/pora + cd ~/workspace/cf-acceptance-tests/assets/pora ``` 1. Push the `pora` test app. Run: diff --git a/services/application-binding.html.md.erb b/services/application-binding.html.md.erb index 362f1556..dd8194ee 100644 --- a/services/application-binding.html.md.erb +++ b/services/application-binding.html.md.erb @@ -23,7 +23,6 @@ $ cf restart my-app

    -Important You must restart or in some cases re-push your app for changes to be applied to the VCAP_SERVICES environment variable and for the app to recognize these changes.

    ### Arbitrary parameters @@ -56,7 +55,7 @@ services: - test-mysql-01 ``` -The following excerpt from an app manifest binds a service instance called `db-test` with arbitrary parameters to the app on push. Arbitrary parameters used in this example are available in cf CLI 7.0 and later. +The following excerpt from an app manifest binds a service instance called `db-test` with arbitrary parameters to the app on push. ``` services: @@ -65,7 +64,7 @@ services: schema: customschema ``` -The following excerpt from the `cf push` command and response demonstrates that the cf CLI reads the manifest and binds the service instance to an app called `test-msg-app`. +The following excerpt from the `cf push` command and response demonstrates that the Tanzu cf CLI reads the manifest and binds the service instance to an app called `test-msg-app`. 
     $ cf push
@@ -110,7 +109,7 @@ After your service instance is created and bound to your app, you must configure
 * **Parse the JSON yourself:** See the documentation for [VCAP_SERVICES](../deploy-apps/environment-variable.html#VCAP-SERVICES). Helper libraries are available for some frameworks.
 * **Auto-configuration:** Some buildpacks create a service connection for you by creating additional environment variables, updating config files, or passing system parameters to the JVM.
 
-For details about consuming credentials specific to your development framework, see the Service Binding section in the documentation for your framework's [buildpack](../../buildpacks/index.html).
+For details about consuming credentials specific to your development framework, see the Service Binding section in the documentation for your framework's [buildpack](../../commercial-buildpacks/using-buildpacks.html).
 
 ## Update service credentials
 
@@ -142,29 +141,29 @@ To update your service credentials:
 
 To update your service credentials without experiencing app downtime:
 
-  1. Start a blue-green update of the app. For more information, see [Using blue-green deployment to reduce downtime and risk](../deploy-apps/blue-green.html). Push the "Green" version of the app with the `--no-start` parameter to prevent the app from starting right away:
+1. Start a blue-green update of the app. For more information, see [Using blue-green deployment to reduce downtime and risk](../deploy-apps/blue-green.html). Push the "Green" version of the app with the `--no-start` parameter to prevent the app from starting right away:
 
-    
    -    $ cf push YOUR-APP --no-start
-    
    
+  
    +  $ cf push YOUR-APP --no-start
+  
    
 
-  1. Bind the service instances to the newly-deployed "Green" app by running:
+1. Bind the service instances to the newly-deployed "Green" app by running:
 
-    
    -    $ cf bind-service YOUR-APP YOUR-SERVICE-INSTANCE
-    
    
+  
    +  $ cf bind-service YOUR-APP YOUR-SERVICE-INSTANCE
+  
    
 
-  1. Start the "Green" app with `cf start`:
+1. Start the "Green" app with `cf start`:
 
-    
    -    $ cf start YOUR-APP
-    
    
+  
    +  $ cf start YOUR-APP
+  
    
 
-  1. Unbind the service instances from the `Blue` app:
+1. Unbind the service instances from the `Blue` app:
 
-    
    -    $ cf unbind-service YOUR-APP YOUR-SERVICE-INSTANCE
-    
    
+  
    +  $ cf unbind-service YOUR-APP YOUR-SERVICE-INSTANCE
+  
    
 
 ## Unbind a service instance
 
@@ -177,5 +176,4 @@ OK

    -Important You must restart or in some cases re-push your app for changes to be applied to the VCAP_SERVICES environment variable and for the app to recognize these changes.

    diff --git a/services/fluentd.html.md.erb b/services/fluentd.html.md.erb index a76a5b64..3383a6b6 100644 --- a/services/fluentd.html.md.erb +++ b/services/fluentd.html.md.erb @@ -11,7 +11,7 @@ Amazon S3. This topic explains how to integrate Fluentd with Cloud Foundry apps. ## Step 1: Create a Cloud Foundry syslog drain for Fluentd -1. In Cloud Foundry, create a syslog drain user-provided service instance as +1. Create a syslog drain user-provided service instance as described in [Using third-party log management services](./log-management.html). 1. Choose one or more apps whose logs you want to drain to Fluentd @@ -58,7 +58,6 @@ To set up Fluentd for Cloud Foundry, configure the syslog input of Fluentd as fo 2. Restart the Fluentd service.

    -Important The Fluentd syslog input plug-in supports tls and tcp options. You must use the same transport that Cloud Foundry is using.

    Fluentd starts listening for syslog message on port 8080 and tagging the messages with `cf.app`, which can be used later for data routing. For more details about the full setup for the service, see [Config File](https://docs.fluentd.org/configuration/config-file). diff --git a/services/index.html.md.erb b/services/index.html.md.erb index e49f9f24..2e5a1860 100644 --- a/services/index.html.md.erb +++ b/services/index.html.md.erb @@ -13,7 +13,6 @@ Cloud Foundry offers a Marketplace of services, from which users can provision r For more information about provisioning service instances and other life cycle operations, see [Managing service instances](./managing-services.html).

    -Note For a service to be available in the Marketplace, it must be integrated with Cloud Foundry by way of APIs. <%= vars.custom_services %>

    ### User-provided service instances @@ -29,7 +28,7 @@ Cloud Foundry allows users to provision credentials needed to interface with a s Service instance credentials can be delivered to apps running on Cloud Foundry in an environment variable. For more information, see [Delivering service credentials to an app](./application-binding.html). -For information about binding to a specific app development framework, see [Buildpacks](../../buildpacks/index.html). +For information about binding to a specific app development framework, see [Using Classic Buildpacks in Cloud Foundry](../../commercial-buildpacks/using-buildpacks.html). ### Service keys @@ -38,13 +37,12 @@ Credentials managed manually are known as service keys. Use service keys when yo For more information about creating a user-provided service instance with service keys, see [User-provided service instances](./user-provided.html). For more information about service keys, see [Managing service keys](./service-keys.html).

    -Important Not all services support service keys. Some services support credentials through app binding only.

    ## Outbound IP addresses -To allow an app to communicate with a service external to <%= vars.product_short %>, you might need to configure the service to accept connections from your app based on its outbound IP address. +To allow an app to communicate with a service external to <%= vars.app_runtime_abbr %>, you might need to configure the service to accept connections from your app based on its outbound IP address. In your external service configuration, you must do one of the following: @@ -66,15 +64,14 @@ To learn how Marketplace services (and user-provided service instances) can be u ## Migrate a database schema -If your app relies on a relational database, you must apply schema changes periodically. To perform database schema migrations on Cloud Foundry-managed services, run a database migration task with the Cloud Foundry Command Line Interface (cf CLI) tool. +If your app relies on a relational database, you must apply schema changes periodically. To perform database schema migrations on Cloud Foundry-managed services, run a database migration task with the Tanzu cf CLI tool. For more information about running cf CLI tasks, see [Running tasks in your apps](../using-tasks.html).

    -Important -To run tasks with the cf CLI, you must install cf CLI v6.23.0 or later. The current supported version is cf CLI v8. For information about downloading, installing, and uninstalling the cf CLI, see the Installing the cf CLI.

    +For information about downloading, installing, and uninstalling the Tanzu cf CLI, see Tanzu cf CLI documentation.

    -To do a database schema migration with cf CLI: +To do a database schema migration with Tanzu cf CLI: 1. Push the app: 
    $ cf push APP-NAME
    @@ -82,10 +79,9 @@ To do a database schema migration with cf CLI: Where `APP-NAME` is the name of the app.

    - Note To run a task without starting the app, push the app with cf push -i 0 and then run the task. You can run the app later by scaling up its instance count.

    -1. Do a database schema migration as a task on the app: +2. Do a database schema migration as a task on the app: 
     	$ cf run-task APP-NAME --command "bin/rails db:migrate" --name TASK-NAME
 	Creating task for app APP-NAME in org jdoe-org / space development as jdoe@pivotal.io...
diff --git a/services/integrate-splunk.html.md.erb b/services/integrate-splunk.html.md.erb
index b4d0a90a..1ae8789f 100644
--- a/services/integrate-splunk.html.md.erb
+++ b/services/integrate-splunk.html.md.erb
@@ -8,9 +8,9 @@ owner: PCF Metrics
 You can follow the steps here to integrate Cloud Foundry with Splunk Enterprise for logging.
 
 
-##  Step 1. Create a Cloud Foundry syslog drain for Splunk
+##  Step 1. Create a syslog drain for Splunk
 
-In Cloud Foundry, create a syslog drain user-provided service instance as
+Create a syslog drain user-provided service instance as
 described in [Using third-party log management services](./log-management.html).
 
 Choose one or more apps whose logs you want to drain to Splunk
diff --git a/services/log-management-thirdparty-svc.html.md.erb b/services/log-management-thirdparty-svc.html.md.erb
index 9a97c353..a30d1e08 100644
--- a/services/log-management-thirdparty-svc.html.md.erb
+++ b/services/log-management-thirdparty-svc.html.md.erb
@@ -62,7 +62,7 @@ From your Papertrail account:
 
 1. After the system is recorded, the URL, with the port, is displayed. Record the URL and port for later use.
 
-    ![Message: CloudFoundry will log to "URL." Record the URL.](../images/third-party-logs/papertrail-05.png)
+    ![Message: Cloud Foundry will log to "URL." Record the URL.](../images/third-party-logs/papertrail-05.png)
 
 1. Create the log drain service in Cloud Foundry.
 
@@ -112,7 +112,7 @@ From your Splunk Storm account:
 
     ![The Authorized network inputs pane shows the ports that data is sent to for this project only.](../images/third-party-logs/splunkstorm-06.png)
 
-5. Using the cf CLI, create the log drain service in Cloud Foundry using the TCP host and port you recorded. Then you bind the service to an app and restage the app using the syntax shown here. After a short delay, the logs begin to flow.
+5. Using the Tanzu cf CLI, create the log drain service in Cloud Foundry using the TCP host and port you recorded. Then you bind the service to an app and restage the app using the syntax shown here. After a short delay, the logs begin to flow.
 
     
         $ cf cups my-logs -l syslog://HOST:PORT
@@ -164,7 +164,7 @@ In your SumoLogic account:
 
     ![Three options are available in the row: Show URL, Edit, Delete.](../images/third-party-logs/sumologic-06a.png)
 
-6. Using the cf CLI, create the log drain service in Cloud Foundry using the source URL you just recorded. Then you bind the service to an app and restage the app using the syntax shown here. After a short delay, the logs begin to flow.
+6. Using the Tanzu cf CLI, create the log drain service in Cloud Foundry using the source URL you just recorded. Then you bind the service to an app and restage the app using the syntax shown here. After a short delay, the logs begin to flow.
 
     
         $ cf cups my-logs -l HTTPS-SOURCE-URL
@@ -188,7 +188,7 @@ In your Sematext account:
 
 1. Click the [Create App / Logsene App](https://apps.sematext.com/logsene-reports/registerApplication.do) menu item. Enter a name and click **Add Application** to create the Logsene App.
 
-2. Using the cf CLI, create the log drain service using the source URL displayed. Then you bind the service to an app and restage the app using the syntax shown here. After a short delay, the logs begin to flow. The logs appear in the [Logsene UI](https://apps.sematext.com/users-web/services.do#logsene).
+2. Using the Tanzu cf CLI, create the log drain service using the source URL displayed. Then you bind the service to an app and restage the app using the syntax shown here. After a short delay, the logs begin to flow. The logs appear in the [Logsene UI](https://apps.sematext.com/users-web/services.do#logsene).
 
     
         $ cf cups logsene-log-drain -l https://logsene-cf-receiver.sematext.com/YOUR_LOGSENE_TOKEN
diff --git a/services/log-management.html.md.erb b/services/log-management.html.md.erb
index 4232e6a7..045eb8a6 100644
--- a/services/log-management.html.md.erb
+++ b/services/log-management.html.md.erb
@@ -54,7 +54,7 @@ Because http drains are slow and resource intensive, we recommend using syslog d
 
 ###  Step 2: Create and bind a user-provided service instance
 
-You can create a syslog drain service and bind apps to it using Cloud Foundry Command Line Interface (cf CLI) commands.
+You can create a syslog drain service and bind apps to it using Tanzu cf CLI commands.
 
 1. To create the service instance, run `cf create-user-provided-service` (or `cf cups`) with the `-l` flag.
 
diff --git a/services/managing-services.html.md.erb b/services/managing-services.html.md.erb
index 765c5c9c..75713ce9 100644
--- a/services/managing-services.html.md.erb
+++ b/services/managing-services.html.md.erb
@@ -1,13 +1,13 @@
 ---
-title: Managing service instances with the cf CLI
+title: Managing service instances with the Tanzu cf CLI
 owner: Core Services
 ---
 
 
 
-You can manage life cycle operations for service instances using the Cloud Foundry CLI (cf CLI). This includes creating, updating, and deleting service instances. For information about other service management operations, see [Services overview](./index.html). <%= vars.custom_services %>
+You can manage life cycle operations for service instances using the Tanzu cf CLI. This includes creating, updating, and deleting service instances. For information about other service management operations, see [Services overview](./index.html). <%= vars.custom_services %>
 
-To run the commands in this topic, you must first install the Cloud Foundry Command Line Interface (cf CLI). See the [Cloud Foundry Command Line Interface](../../cf-cli/index.html) topics for more information.
+To run the commands in this topic, you must first install the Tanzu cf CLI. See the [Using the Tanzu cf CLI](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/index.html) topics for more information.
 
 ##  List Marketplace services
 
@@ -53,12 +53,12 @@ OK
 
 User-provided service instances provide a way for developers to bind apps with services that are not available in their Cloud Foundry Marketplace. For more information, see User-provided service instances.
 
+
    The cf create-service command uses CAPI V3 and creates asynchronous jobs. To wait for the create operation to complete before continuing, use the --wait flag. For more information, see the cf create-service reference.
    
+
 When multiple brokers provide two or more services with the same name, you must specify the broker by including the -b BROKER flag in the cf create-service command.
 
 ###  Arbitrary parameters
 
-Arbitrary parameters require cf CLI v6.12.1+ or higher.
-
 Some services support providing additional configuration parameters with the provision request. Pass these parameters in a valid JSON object containing service-specific configuration parameters, provided either in-line or in a file. For a list of supported configuration parameters, see the documentation for the particular service offering.
 
 Example providing service-specific configuration parameters in-line:
@@ -80,7 +80,6 @@ OK
 
    
 
 ###  Instance tags
-_Instance tags require cf CLI v6.12.1+_
 
 Some services provide a list of tags that Cloud Foundry delivers in the [VCAP_SERVICES environment variable](../deploy-apps/environment-variable.html#VCAP-SERVICES). These tags provide developers with a more generic way for apps to parse `VCAP_SERVICES` for credentials. Developers might provide their own tags when creating a service instance by including the `-t` flag followed by a comma-separated list of tags.
 
@@ -103,6 +102,8 @@ cf services
 
 The output from running this command includes any bound apps and the state of the last requested operation for the service instance.
 
+
    To improve performance when you have many service instances, use --no-apps to skip retrieving bound app information. Use --wait to wait for any in-progress operation to complete. For more information, see the cf services reference.
    
+
 
     $ cf services
 Getting services in org my-org / space test as user@example.com...
@@ -120,13 +121,16 @@ Details include dashboard urls, if applicable, and operation start and last upda
 
     $ cf service mydb
 
-service instance:       mydb
-service:                p-mysql
+name:                   mydb
+guid:                   abcd1234-ef56-7890-abcd-ef1234567890
+type:                   managed
+broker tags:
+offering:               p-mysql
 plan:                   100mb
 description:            mysql databases on demand
-documentation url:
-dashboard:              https://p-mysql.example.com/manage/instances/abcd-ef12-3456
-service broker:         mysql-broker
+documentation:
+dashboard url:          https://p-mysql.example.com/manage/instances/abcd-ef12-3456
+broker:                 mysql-broker
 
 This service is not shared.
 
@@ -164,7 +168,7 @@ $ cf restart my-app
 
 ####  Binding with app manifest
 
-As an alternative to binding a service instance to an app after pushing an app, you can use the app manifest to bind the service instance during push. As of cf CLI v6.12.1, [Arbitrary parameters](#arbitrary-params-binding) are not supported in app manifests. Using the manifest to bind service instances to routes is also not supported.
+As an alternative to binding a service instance to an app after pushing an app, you can use the app manifest to bind the service instance during push. [Arbitrary parameters](#arbitrary-params-binding) are not supported in app manifests. Using the manifest to bind service instances to routes is also not supported.
 
 This excerpt from an app manifest binds a service instance called `test-mysql-01` to the app on push.
 
@@ -201,8 +205,6 @@ Restaging your app is not required.
 
 ###  Arbitrary parameters
 
-_Arbitrary parameters require cf CLI v6.12.1+_
-
 Some services support additional configuration parameters with the bind request. These parameters are passed in a valid JSON object containing service-specific configuration parameters, provided either in-line or in a file. For a list of supported configuration parameters, see documentation for the particular service offering.
 
 
    @@ -263,7 +265,6 @@ OK
 ## Update a service instance
 
 ### Changing a service plan
-_Changing a plan requires cf CLI v6.7+ and cf-release v192+. CLI v7 or v8 is recommended._
 
 By updating the service plan for an instance, you can change the service instance to other service plans. Though the platform and CLI now support this feature, services must implement support for it. Further, a service might support updating between some plans but not others. For example, a service might support updating a plan where only a logical change is required, but not where data migration is necessary. In either case, users can expect to see a meaningful error when plan update is not supported.
 
@@ -275,8 +276,6 @@ OK
 
 ###  Arbitrary parameters
 
-_Arbitrary parameters require cf CLI v6.12.1+_
-
 Some services support additional configuration parameters with the update request. These parameters are passed in a valid JSON object containing service-specific configuration parameters, provided either in-line or in a file. For a list of supported configuration parameters, see documentation for the particular service offering.
 
 
    @@ -292,7 +291,6 @@ Updating service instance mydb as user@example.com...
 
    
 
 ###  Instance tags
-_Instance tags require cf CLI v6.12.1+_
 
 Some services provide a list of tags that Cloud Foundry delivers in the [VCAP_SERVICES environment variable](../deploy-apps/environment-variable.html#VCAP-SERVICES). These tags provide developers with a more generic way for apps to parse `VCAP_SERVICES` for credentials. Developers can provide their own tags when creating a service instance by including a comma-separated list of tags with the `-t` flag.
 
@@ -305,11 +303,6 @@ OK
 
 ##  Upgrade a service instance
 
-
    
-Important
-Upgrading a Service instance requires at least cf CLI v6.46.0+ and CAPI release 1.83.0+.
-
    
-
 Some service brokers support upgrading service instances to the latest version of a service plan. For example, a broker might want to provide a way for users of the service to upgrade the underlying operating system that their service instances run on.
 
 To upgrade your service instances:
@@ -325,22 +318,28 @@ To upgrade your service instances:
     otherdb   p-mysql   medium                create succeeded   mysql-broker   no
     
    
 
-2. Upgrade the service instance using the `--upgrade` flag:
+2. Upgrade the service instance by running:
 
     ```console
-    cf update-service SERVICE-INSTANCE-NAME --upgrade
+    cf upgrade-service SERVICE-INSTANCE-NAME
     ```
 
     For example:
 
     
    -    $ cf update-service mydb --upgrade
-    You are about to update mydb.
+    $ cf upgrade-service mydb
+    You are about to upgrade mydb.
     Warning: This operation might run long and block further operations on the service until complete.
-    Really update service mydb? [yN]: y
+    Really upgrade service mydb? [yN]: y
     OK
     
    
 
+    To skip the confirmation prompt, use the `--force` flag:
+
+    ```console
+    cf upgrade-service mydb --force
+    ```
+
 
 ## Delete a service instance
 
diff --git a/services/metrics.html.md.erb b/services/metrics.html.md.erb
index d12ba85e..d01e8fb1 100644
--- a/services/metrics.html.md.erb
+++ b/services/metrics.html.md.erb
@@ -3,7 +3,7 @@ title: Using metrics with drain logs
 owner: PCF Metrics
 ---
 
-Here are instructions for using metrics to filter and report draining logs from Cloud Foundry. It also describes how to detect and diagnose system problems based on dropped metrics.
+Here are instructions for using metrics to filter and report draining logs. It also describes how to detect and diagnose system problems based on dropped metrics.
 
 
 ##  How app logs are collected
diff --git a/services/oms-nozzle.html.md.erb b/services/oms-nozzle.html.md.erb
index 6f2db6e3..6ce84213 100644
--- a/services/oms-nozzle.html.md.erb
+++ b/services/oms-nozzle.html.md.erb
@@ -7,7 +7,7 @@ Here are instructions for integrating your <%= vars.app_runtime_first %> apps wi
 
 Operations Management Suite (OMS) Log Analytics is a monitoring service for Microsoft Azure. The OMS Log Analytics Firehose Nozzle is a <%= vars.app_runtime_abbr %> component that forwards metrics from the Loggregator Firehose to OMS Log Analytics.
 
-This topic assumes you are using the latest version of the Cloud Foundry Command Line Interface (cf CLI) and a working <%= vars.app_runtime_abbr %> deployment on Azure.
+This topic assumes you are using the latest version of the Tanzu cf CLI and a working <%= vars.app_runtime_abbr %> deployment on Azure.
 
 
 ##  Step 1: Create an OMS workspace in Azure
@@ -31,8 +31,8 @@ To deploy the OMS Log Analytics Firehose nozzle to <%= vars.app_runtime_abbr %>:
       
  • YOUR-USERNAME is your <%= vars.app_runtime_abbr %> user name.
    • 
     
 
-1. To create a new <%= vars.app_runtime_abbr %> user and grant it access to the Loggregator Firehose using the UAA CLI (UAAC):
-    1. Target your UAA server by running:
+1. To create a new <%= vars.app_runtime_abbr %> user and grant it access to the Loggregator Firehose using the Tanzu UAA CLI (UAAC):
+    1. Target your Tanzu UAA server by running:
 
         ```
         uaac target uaa.YOUR-DOMAIN --skip-ssl-validation
@@ -138,7 +138,7 @@ To deploy the OMS Log Analytics Firehose nozzle to <%= vars.app_runtime_abbr %>:
       
       
         SKIP_SSL_VALIDATION: TRUE-OR-FALSE
-        Set this value to TRUE to allow insecure connections to the UAA and the Traffic Controller. To block insecure connections to the UAA and Traffic Controller, set this value to FALSE.
+        Set this value to TRUE to allow insecure connections to the Tanzu UAA and the Traffic Controller. To block insecure connections to the Tanzu UAA and Traffic Controller, set this value to FALSE.
       
       
         LOG_LEVEL: INFO
diff --git a/services/route-binding.html.md.erb b/services/route-binding.html.md.erb
index 2f2fc64a..95248979 100644
--- a/services/route-binding.html.md.erb
+++ b/services/route-binding.html.md.erb
@@ -19,13 +19,12 @@ To view an example demonstrating the use of a sample route service, see [Route S
 
 ##  Bind a route to a service instance
 
-You must install the Cloud Foundry Command Line Interface (cf CLI) to bind a route to a service instance. For more information, see [Installing the cf CLI](../../cf-cli/install-go-cli.html).
+You must install the Tanzu cf CLI to bind a route to a service instance. For more information, see [Tanzu cf CLI documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/standalone-index.html).
 
 
    
-Important
 Gorouter rejects WebSocket requests for routes that are bound to route services. These requests return a 503 error and a X-Cf-Routererror route_service_unsupported header.
    
 
-Run [cf bind-route-service](http://cli.cloudfoundry.org/en-US/cf/bind-route-service.html) to bind a route from an app to a service instance.
+Run `cf bind-route-service` to bind a route from an app to a service instance.
 
 The following example binds the route from `my-app.<%=vars.app_domain%>` to the service instance `my-route-service`.
 
@@ -37,7 +36,6 @@ OK
 
    
 
 
    
-Caution
 When binding a service instance to a route, Cloud Foundry might have proxy requests for the route to the service instance, or configure a network component already in the request path.
    
 
 ###  Bind with parameters
@@ -64,9 +62,9 @@ OK
 
 ##  Unbind a route from a service instance
 
-You must install the Cloud Foundry Command Line Interface (cf CLI) to bind a route to a service instance. For more information, see [Installing the cf CLI](../../cf-cli/install-go-cli.html).
+You must install the Tanzu cf CLI to bind a route to a service instance. For more information, see [Tanzu cf CLI documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-cf-cli/<%= vars.tanzu_cf_cli_version %>/t-cf-cli/standalone-index.html).
 
-Run the [cf unbind-route-service](http://cli.cloudfoundry.org/en-US/cf/unbind-route-service.html) command to unbind a route from an app to a service instance.
+Run the `cf unbind-route-service` command to unbind a route from an app to a service instance.
 
 This example removes the route from `my-app.<%=vars.app_domain%>` to the service instance `my-route-service`.
 
diff --git a/services/service-keys.html.md.erb b/services/service-keys.html.md.erb
index fd41c5bd..c0088a8d 100644
--- a/services/service-keys.html.md.erb
+++ b/services/service-keys.html.md.erb
@@ -10,7 +10,6 @@ Here are instructions for managing service instance credentials (binding credent
 Service keys generate credentials for manually configuring consumers of Marketplace services. After you configure them for your service, local clients, apps in other spaces, or entities outside your deployment can access your service with these keys.
 
 
    
-Important
 Some service brokers do not support service keys. To build a service broker that supports service keys, see Services. To use a service broker that does not support service keys, see Delivering service credentials to an app.
    
 
 ##  Create a service key
@@ -84,7 +83,7 @@ OK
 
 After obtaining these credentials, you can use a local CLI or utility to connect to the service instance, configure an app running outside the platform to connect to the service instance, or create a user-provided service instance so that apps in another space can connect to the service instance. How you configure these credentials depends on what local client, app, or entity is used to access your service instance.
 
-For more information about configuring credentials with a user-provided service instance, see [User-provided service instances](http://docs.cloudfoundry.org/devguide/services/user-provided.html).
+For more information about configuring credentials with a user-provided service instance, see [User-provided service instances](./user-provided.html).
 
 ## Delete a service key
 
diff --git a/services/sharing-instances.html.md.erb b/services/sharing-instances.html.md.erb
index 45ce8165..7402aca3 100644
--- a/services/sharing-instances.html.md.erb
+++ b/services/sharing-instances.html.md.erb
@@ -48,8 +48,7 @@ $ cf enable-feature-flag service_instance_sharing
 
 You can share a service instance from one space to another if you have the Space Developer role in both spaces.
 
-To share a service instance to another space, run the following Cloud
-Foundry Command Line Interface (cf CLI) command:
+To share a service instance to another space, run the following Tanzu cf CLI command:
 
 
     $ cf share-service SERVICE-INSTANCE -s OTHER-SPACE [-o OTHER-ORG]
@@ -66,7 +65,7 @@ you cannot share that service instance.
 
 ##  Get information about service instance sharing
 
-To get information about service instance sharing on the originating space, run the following cf CLI command from that originating space:
+To get information about service instance sharing on the originating space, run the following Tanzu cf CLI command from that originating space:
 
 ```
 cf service SERVICE-INSTANCE-NAME
@@ -146,7 +145,6 @@ In this case, no information about other spaces is exposed.
 ##  Unsharing a service instance
 
 
    
-Caution
 Unsharing a service instance deletes all bindings to apps in the spaces it was shared into. This might cause apps to fail. Before unsharing a service instance, run the cf service SERVICE-INSTANCE command to find out how many bindings exist in the spaces the service instance is shared into.
    
 
 You can unshare a service instance if you have the Space Developer role in the
@@ -155,7 +153,7 @@ space where this service instance was shared from.
 Developers cannot delete or rename a service instance until it is unshared from all
 spaces.
 
-To unshare a service instance, run the following cf CLI command:
+To unshare a service instance, run the following Tanzu cf CLI command:
 
 
     $ cf unshare-service SERVICE-INSTANCE -s OTHER-SPACE [-o OTHER-ORG] [-f]
@@ -201,7 +199,6 @@ If a service binding is not deleted, the script continues trying to unshare subs
 To use this script, you must be logged in as an administrator and have jq installed.
 
 
    
-Caution
 This script was tested on macOS Sierra 10.12.4 and Ubuntu 14.04.5. Use the script at your own risk.
    
 
 ```
diff --git a/services/user-provided.html.md.erb b/services/user-provided.html.md.erb
index 9b71471f..dde0d48d 100644
--- a/services/user-provided.html.md.erb
+++ b/services/user-provided.html.md.erb
@@ -15,7 +15,7 @@ After creation, user-provided service instances behave like service instances cr
 
 ## Create a user-provided service instance
 
-The alias for [cf create-user-provided-service](http://cli.cloudfoundry.org/en-US/cf/create-user-provided-service.html) is `cf cups`.
+The alias for `cf create-user-provided-service` is `cf cups`.
 
 ### Deliver service credentials to an app
 
@@ -27,7 +27,7 @@ User-provided service instances allow developers to configure their apps with th
 cf cups SERVICE_INSTANCE -p '{"username":"admin","password":"pa55woRD"}'
 
    
 
-To create a service instance in interactive mode, use the `-p` option with a comma-separated list of parameter names. The Cloud Foundry Command Line Interface (cf CLI) prompts you for each parameter value.
+To create a service instance in interactive mode, use the `-p` option with a comma-separated list of parameter names. The Tanzu cf CLI prompts you for each parameter value.
 
 
     $ cf cups my-user-provided-route-service -p "host, port"
@@ -46,6 +46,10 @@ After creating the user-provided service instance, to deliver the credentials to
 
 User-provided service instances allow developers to stream app logs to a syslog compatible aggregation or analytics service that isn't available in the Marketplace. For more information about the syslog protocol see [RFC 5424](http://tools.ietf.org/html/rfc5424) and [RFC 6587](http://tools.ietf.org/html/rfc6587).
 
+
    
+RFC-5424 is used to establish connections over HTTP/HTTPS. RFC-6587 is used for TCP based communication over syslog/syslog-tls drains.
+
    
+
 Create the user-provided service instance, specifying the URL of the service with the `-l` option.
 
 
    @@ -65,7 +69,6 @@ OK
 
    
 
 
    
-Important
 When creating the user-provided service, the route service URL you specify must be "https."
 
    
 
@@ -74,12 +77,11 @@ For more information, see [Managing app requests with route services](./route-bi
 
 ##  Update a user-provided service instance
 
-You can use [cf update-user-provided-service](http://cli.cloudfoundry.org/en-US/cf/update-user-provided-service.html) to update the attributes of an instance of a user-provided service. New credentials overwrite old credentials, and parameters that are not provided are deleted.
+You can use `cf update-user-provided-service` to update the attributes of an instance of a user-provided service. New credentials overwrite old credentials, and parameters that are not provided are deleted.
 
 The alias for `update-user-provided-service` is `uups`. Bound apps can access the new configuration after restart.
 You can use rolling restarts to avoid any app downtime.
 For more information, see [Restart an app](../deploy-apps/rolling-deploy.html#restart) in _Rolling App Deployments_.
 
 
    
-Caution
 If you are rotating credentials, the old credentials must be active until the restart is finished.
    
diff --git a/services/using-vol-services.html.md.erb b/services/using-vol-services.html.md.erb
index 3cf99daf..12a0b755 100644
--- a/services/using-vol-services.html.md.erb
+++ b/services/using-vol-services.html.md.erb
@@ -3,12 +3,5 @@ title: Using an external file system (volume services)
 owner: Core Services
 ---
 
-<% if vars.platform_code == "PCF" || vars.platform_code == "CF" %>
 
 <%= partial 'using-vol-services' %>
-
-<% else %>
-
-<%= vars.vol_services_not_available %>
-
-<% end %>
diff --git a/sidecars.html.md.erb b/sidecars.html.md.erb
index c47dc658..e8146b68 100644
--- a/sidecars.html.md.erb
+++ b/sidecars.html.md.erb
@@ -9,8 +9,8 @@ are called sidecar processes, or sidecars. An example of a sidecar is an Applica
 Monitoring (APM) tool.
 
 
    
-Important
-The cf CLI v6 commands described in this topic are unsupported, but are supported in cf CLI v7. The latest supported cf CLI release is cf CLI v8. To upgrade to cf CLI v7, see Upgrading to cf CLI v7. To upgrade to cf CLI v8, see Upgrading to cf CLI v8.
    
+Use Tanzu cf CLI starting with Tanzu Platform for Cloud Foundry 10.2.
+See Tanzu cf CLI documentation.
    
 
 <%= vars.capi_sidecar_req %>
 
@@ -24,7 +24,7 @@ single container on Diego. Both processes within the container undergo health ch
 You can push sidecar processes with your app by using one of two methods:
 
 * Using an app manifest. For instructions, see [Push an app with a sidecar Using an app manifest](#create).
-* With a custom buildpack. For instructions, see [Sidecar buildpacks](../buildpacks/sidecar-buildpacks.html).
+* With a custom buildpack. For instructions, see [Sidecar buildpacks](../commercial-buildpacks/sidecar-buildpacks.html).
 
 For additional information about sidecars, see [Sidecars](http://v3-apidocs.cloudfoundry.org/version/release-candidate/#sidecars) in the
 Cloud Foundry API (CAPI) documentation.
@@ -88,7 +88,7 @@ Where:
 * `START-COMMAND` is the command used to start the sidecar. For example, `./binary` or `java -jar java-file.jar`.
 
 You must also allocate memory to sidecars that you push with a custom buildpack.
-For more information, see [Sidecar buildpacks](../buildpacks/sidecar-buildpacks.html).
+For more information, see [Sidecar buildpacks](../commercial-buildpacks/sidecar-buildpacks.html).
 
 ###  Packaging binaries
 
@@ -108,7 +108,7 @@ Where:
 
 * `SIDECAR-BINARY` is your sidecar binary.
 
-For more information about packaging assets with your Java app, see [Cloud Foundry documentation](https://docs.cloudfoundry.org/buildpacks/java/java-tips.html).
+For more information about packaging assets with your Java app, see [Cloud Foundry documentation](../commercial-buildpacks/java/java-tips.html).
 
 
 ##  Push an app with a sidecar using an app manifest
@@ -130,18 +130,11 @@ Before you can push an app with a sidecar with an app manifest, you must have:
 To push an app with a sidecar:
 
 1. Create an app or use an existing app. To create an app:
-    * If you are using cf CLI v7, run:
 
-        ```
-        cf create-app APP-NAME
-        ```
-        Where `APP-NAME` is the name you give your app.
-    * If you are using cf CLI v6, run:
-
-        ```
-        cf v3-create-app APP-NAME
-        ```
-        Where `APP-NAME` is the name you give your app.
+    ```
+    cf create-app APP-NAME
+    ```
+    Where `APP-NAME` is the name you give your app.
 
 1. Create a manifest file in the root directory of your app, such as `manifest.yml`. Otherwise, use an existing manifest file for your app. For more information, see [Deploying with app manifests](./deploy-apps/manifest.html).
 
@@ -177,39 +170,24 @@ To push an app with a sidecar:
     ```
 
 1. To apply the manifest file to your app:
-    * If you are using cf CLI v7, run:
-
-        ```
-        cf apply-manifest -f PATH-TO-MANIFEST
-        ```
-        Where `PATH-TO-MANIFEST` is the path to your manifest file.
-    * If you are using cf CLI v6, run:
 
-        ```
-        cf v3-apply-manifest -f PATH-TO-MANIFEST
-        ```
-        Where `PATH-TO-MANIFEST` is the path to your manifest file.
+    ```
+    cf apply-manifest -f PATH-TO-MANIFEST
+    ```
+    Where `PATH-TO-MANIFEST` is the path to your manifest file.
 
 1. To push your app:
-    * If you are using cf CLI v7, run:
 
-        ```
-        cf push APP-NAME
-        ```
-        Where `APP-NAME` is the name of your app.
-    * If you are using cf CLI v6, run:
-
-        ```
-        cf v3-push APP-NAME
-        ```
-        Where `APP-NAME` is the name of your app.
+    ```
+    cf push APP-NAME
+    ```
+    Where `APP-NAME` is the name of your app.
 
 ##  Sidecar tutorial
 
 You can explore sidecars using the app in the [capi-sidecar-samples](https://github.com/cloudfoundry-samples/capi-sidecar-samples) repository on GitHub. The following sections describe the app, how to build and push the app, and some ways to observe the app and its processes after pushing.
 
 
    
-Important
 In this tutorial, you are pushing the Ruby sample app. You can also follow this tutorial for a Java app using the sidecar-dependent-java-app and push_java_app_with_binary_sidecar.sh in the samples repository. When pushing a Java app, follow the requirements listed in Requirements for Java apps.
    
 
 ###  About the sample app
@@ -255,48 +233,34 @@ To push the app and sidecar:
 
 
 1. To create the app:
-	* If you are using cf CLI v7, run:
-
-		```
-		cf create-app sidecar-dependent-app
-		```
-	* If you are using cf CLI v6, run:
 
-		```
-		cf v3-create-app sidecar-dependent-app
-		```
+    ```
+    cf create-app sidecar-dependent-app
+    ```
 
 1. Go to the `sidecar-dependent-app` directory.
 
 1. Open and review the `manifest.yml` file. Under `sidecars`, the sidecar is specified with a name, process type, and start command. Under `env`, an environment variable defines the port on which the app and sidecar communicate.
 
 1. To apply the manifest to the app:
-	* If you are using cf CLI v7, run:
 
-		```
-		cf apply-manifest
-		```
-	* If you are using cf CLI v6, run:
-
-		```
-		cf v3-apply-manifest
-		```
+    ```
+    cf apply-manifest
+    ```
 
 1. To push the app:
-	* If you are using cf CLI v7, run:
 
-		```
-		cf push sidecar-dependent-app
-		```
-	* If you are using cf CLI v6, run:
+    ```
+    cf push sidecar-dependent-app
+    ```
 
-		```
-		cf v3-push sidecar-dependent-app
-		```
+After you push the app, you can further explore it as described in the sections below:
 
-After you push the app, you can further explore it in [View the processes running in the container](#view-processes) and [View the web URL and app logs](#view-logs).
+- [View processes running in the app container via SSH](#view-processes-ssh)
+- [View the web URL and app logs via SSH](#view-logs)
+- [View and debug processes running in the app container via HTTP](#debug-processes-http)
 
-###  View the processes running in the container
+###  View processes running in the app container via SSH
 
 To view the app and sidecar process running in the container:
 
@@ -339,7 +303,7 @@ To view the app and sidecar process running in the container:
     ruby       13 vcap 11u  IPv4 17274965    0t0 TCP localhost:42266->localhost:8082 (ESTABLISHED)
     
    
 
-###  View the web URL and app logs
+###  View the web URL and app logs via SSH
 
 To view the web URL and logs for the app:
 
@@ -377,3 +341,124 @@ To view the web URL and logs for the app:
 	"crash_count"=>1, "crash_timestamp"=>1555544935367052708,
 	"version"=>"50892dcb-274d-4cf6-b944-3eda1e000283"}
 	
    
+
+### View and debug processes running in the app container via HTTP
+
+Sidecars can be used to collect debug information (e.g. thread dumps) from
+another process running in the same container. This is especially useful if you
+want to debug a running process using an HTTP request, for instance if you do
+not have ssh access to the application container.
+
+This is an example of a simple routable debug sidecar for java applications,
+but the same concept can be adapted to more advanced debug tooling and other
+languages or frameworks.
+
+####  Prerequisites
+
+Before you begin, you must have:
+
+* A java app with [a manifest](./deploy-apps/manifest.html) that is ready to be
+pushed. For example, the [java sample
+app](https://github.com/cloudfoundry/cf-acceptance-tests/tree/main/assets/java)
+from CF Acceptance Tests.
+
+* A route to map to the debug sidecar
+
+####  Procedure
+
+To add a debug sidecar to the java app:
+
+1. Create a sidecar that responds to HTTP requests and calls `kill -3` on the
+java process. When a java process receives the resulting SIGQUIT signal, it
+will print a thread dump to STDOUT. For an example, see the
+[java_debug_sidecar](https://github.com/Gerg/java-debug-buildpack/blob/main/java_debug_sidecar.go)
+on GitHub.
+
+1. Place the sidecar binary in the root directory of your java app
+
+1. Add the following to your app manifest:
+
+    ```
+    sidecars:
+    - name: debug-sidecar
+      process_types: [ 'web' ]
+      command: START-COMMAND
+      memory: 256MB
+    ```
+
+    Where `START-COMMAND` is the command used to start the sidecar. For the above
+    example sidecar, `./java_debug_sidecar`.
+
+1. Push the java application. For example:
+
+    ```
+    cf push APP-NAME -f manifest.yml -m 1G
+    ```
+
+    Where `APP-NAME` is the name of your app.
+
+1. Map a route to the sidecar process's port. For detailed steps, see
+[Configuring Cloud Foundry to route traffic to apps on custom ports](./custom-ports.html).
+
+    ```
+    cf curl -X PATCH /v3/routes/ROUTE-GUID/destinations -d '{
+    "destinations": [
+        {
+          "app": {
+            "guid": "APP-GUID",
+            "process": {
+              "type": "web"
+            }
+          },
+          "port": PORT,
+          "protocol": "http1"
+        }
+      ]
+    }'
+    ```
+
+    Where:
+    
      
+      
    • APP-GUID is the GUID of your app.
      • 
+      
    • ROUTE-GUID is the GUID of the route to map to the sidecar.
      • 
+      
    • PORT is a custom port on which your app is configured to
+      receive requests. This is 8081 for the above example.
      • 
+    
    
+
+1. Restart the app to complete the port mapping
+
+    ```
+    cf restart APP_NAME
+    ```
+
+    Where `APP-NAME` is the name of your app.
+
+1. Tail the app logs:
+
+    ```
+    cf logs APP_NAME
+    ```
+
+    Where `APP-NAME` is the name of your app.
+
+1. In another terminal, make a HTTP request to the sidecar, to trigger the
+thread dump. For example:
+
+    ```
+    curl https://debug-sidecar.example.com/threaddump
+    ```
+
+1. Observe the thread dump in the app logs
+
+###  Next Steps
+
+Now that you have a simple debugging sidecar working, here are some ideas for
+next steps:
+
+* Use more sophisticated debugging tools
+* Return the debug information in the HTTP response, rather than logging to STDOUT
+* Inject the debug sidecar via a [Sidecar
+buildpacks](../commercial-buildpacks/sidecar-buildpacks.html). For example:
+[java-debug-buildpack](https://github.com/Gerg/java-debug-buildpack) on GitHub.
+* Add authentication for the debug sidecar's HTTP route, for instance using an
+authentication [Route Service](../services/route-services.html).
diff --git a/streaming-logs-index.html.md.erb b/streaming-logs-index.html.md.erb
index ad930f43..3eebf904 100644
--- a/streaming-logs-index.html.md.erb
+++ b/streaming-logs-index.html.md.erb
@@ -20,4 +20,5 @@ These topics contain information about streaming app logs:
    
    
  • 
       Streaming app logs to Azure OMS Log Analytics
-   
    • 
\ No newline at end of file
+   
+
diff --git a/using-tasks.html.md.erb b/using-tasks.html.md.erb
index 363c0427..4d179045 100644
--- a/using-tasks.html.md.erb
+++ b/using-tasks.html.md.erb
@@ -38,7 +38,7 @@ The life cycle of a task is as follows:
 1. A user initiates a task in <%= vars.app_runtime_abbr %> using one of the following mechanisms:
    * The `cf run-task APP-NAME "TASK"` command. For more information, see [Running tasks in your apps](#run-tasks).
    * A Cloud Controller v3 API call. For more information, see the [Cloud Foundry API documentation](http://v3-apidocs.cloudfoundry.org/version/3.0.0/index.html#tasks).
-   * The Cloud Foundry Java Client. For more information, see [Cloud Foundry Java Client Library](../buildpacks/java/java-client.html) and the [Cloud Foundry Java Client](https://github.com/cloudfoundry/cf-java-client) repository on GitHub.
+   * The Cloud Foundry Java Client. For more information, see [Cloud Foundry Java Client Library](../commercial-buildpacks/java/java-client.html) and the [Cloud Foundry Java Client](https://github.com/cloudfoundry/cf-java-client) repository on GitHub.
 
 1. <%= vars.app_runtime_abbr %> creates a container specifically for the task.
 
@@ -49,7 +49,6 @@ The life cycle of a task is as follows:
 The container also inherits environment variables, service bindings, and security groups bound to the app.
 
 
    
-Note
 You cannot SSH into the container running a task.
    
 
 ###  Task logging and execution history
@@ -66,115 +65,25 @@ more information, see the [Cloud Foundry API documentation](http://v3-apidocs.cl
 Admins can set the default memory, disk usage and log rate quotas for tasks on a global level.
 
 Tasks use the same memory, disk usage, and log rate limit defaults as apps, unless you customize them using the `cf run-task` command. For more information
-about the `cf run-task` command, see the [Cloud Foundry CLI reference guide](https://cli.cloudfoundry.org/en-US/v8/run-task.html).
+about the `cf run-task` command, enter `cf run-task --help`.
 
-<% if vars.platform_code == 'PCF' %>
 <%= partial "/pcf/core/tasks_rec_alloc_pcf" %>
-<% else %>
-<%= partial 'tasks_rec_alloc_oss' %>
-<% end %>
 
 
 ##  Run a task on an app
 
-You can use the Cloud Foundry Command Line Interface (cf CLI) to run a task in the context of an app.
-
-
    
-Important
-  
      
-    
    • To run tasks with the cf CLI, you must install cf CLI v6.23.0 or later, or install cf CLI v7 or v8. To download, install, and uninstall the cf CLI, see Installing the Cloud Foundry Command Line Interface.
      • 
-    
    • To run a task using cf CLI v6 without starting the app, push the app with cf push -i 0 and then run the task. You can run the app later by scaling up its instance count.
      • 
-  
    
-
    
-
-###  Run a task on an app with cf CLI v6
-
-To run a task on an app with cf CLI v6:
-
-1. In a terminal window, push your app by running:
-
-    ```
-    cf push APP-NAME
-    ```
-    Where `APP-NAME` is the name of your app,
-
-1. Run your task on the deployed app by running:
-
-    ```
-    cf run-task APP-NAME "TASK" --name TASK-NAME
-    ```
-
-    Where:
-    
      
-      
    • APP-NAME is the name of your app.
      • 
-      
    • TASK is the task you want to run.
      • 
-      
    • TASK-NAME is the name you want to give the task.
      • 
-    
    
-
-    The following example command runs a database migration as a task on the `example-app` app:
-
-    
    -    cf run-task example-app "bin/rails db:migrate" --name example-task
-    
    
-
-    When the task runs successfully, you see an output similar to the following example:
-    
    -    Creating task for app example-app in org example-org / space development as admin@example.org...
-    OK
-    Task 1 has been submitted successfully for execution.
-    
    
-
-    
    
-    Note
-    To run a task again, you must run it as a new task using the previous command.
    
-
-1. To display the recent logs of the app and all its tasks, run:
-
-    ```
-    cf logs APP-NAME --recent
-    ```
-    Where `APP-NAME` is the name of your app.
-    

    
-    If a task succeeds, you see logs similar to the following example:
-    
    -    2017-01-03T15:58:06.57-0800 [APP/TASK/my-task/0]OUT Creating container
-    2017-01-03T15:58:08.45-0800 [APP/TASK/my-task/0]OUT Successfully created container
-    2017-01-03T15:58:13.32-0800 [APP/TASK/my-task/0]OUT D, [2017-01-03T23:58:13.322258 #7] DEBUG -- :    (15.9ms)  CREATE TABLE "schema_migrations" ("version" character varying PRIMARY KEY)
-    2017-01-03T15:58:13.33-0800 [APP/TASK/my-task/0]OUT D, [2017-01-03T23:58:13.337723 #7] DEBUG -- :    (11.9ms)  CREATE TABLE "ar_internal_metadata" ("key" character varying PRIMARY KEY, "value" character varying, "created_at" timestamp NOT NULL, "updated_at" timestamp NOT NULL)
-    2017-01-03T15:58:13.34-0800 [APP/TASK/my-task/0]OUT D, [2017-01-03T23:58:13.340234 #7] DEBUG -- :    (1.6ms)  SELECT pg_try_advisory_lock(3720865444824511725);
-    2017-01-03T15:58:13.35-0800 [APP/TASK/my-task/0]OUT D, [2017-01-03T23:58:13.351853 #7] DEBUG -- :   ActiveRecord::SchemaMigration Load (0.7ms)  SELECT "schema_migrations".* FROM "schema_migrations"
-    2017-01-03T15:58:13.35-0800 [APP/TASK/my-task/0]OUT I, [2017-01-03T23:58:13.357294 #7]  INFO -- : Migrating to Createtopics (20161118225627)
-    2017-01-03T15:58:13.35-0800 [APP/TASK/my-task/0]OUT D, [2017-01-03T23:58:13.359565 #7] DEBUG -- :    (0.5ms)  BEGIN
-    2017-01-03T15:58:13.35-0800 [APP/TASK/my-task/0]OUT == 20161118225627 Createtopics: migrating ===================================
-    2017-01-03T15:58:13.50-0800 [APP/TASK/my-task/0]OUT Exit status 0
-    2017-01-03T15:58:13.56-0800 [APP/TASK/my-task/0]OUT Destroying container
-    2017-01-03T15:58:15.65-0800 [APP/TASK/my-task/0]OUT Successfully destroyed container
-    
    
-    If a task fails, you see logs similar to the following example:
-    
    -    2016-12-14T11:09:26.09-0800 [APP/TASK/my-task/0]OUT Creating container
-    2016-12-14T11:09:28.43-0800 [APP/TASK/my-task/0]OUT Successfully created container
-    2016-12-14T11:09:28.85-0800 [APP/TASK/my-task/0]ERR bash: bin/rails: command not found
-    2016-12-14T11:09:28.85-0800 [APP/TASK/my-task/0]OUT Exit status 127
-    2016-12-14T11:09:28.89-0800 [APP/TASK/my-task/0]OUT Destroying container
-    2016-12-14T11:09:30.50-0800 [APP/TASK/my-task/0]OUT Successfully destroyed container
-    
    
-    If your task name is unique, you can `grep` the output of the `cf logs` command for the task name to view task-specific logs.
-
-###  Run a task on an app with cf CLI v7
-
-To run a task on an app with cf CLI v7:
+You can use the Tanzu cf CLI to run a task in the context of an app.
 
 1. Configure your v3 API manifest with a task as a process type. For more information, see the [Cloud Foundry API documentation](https://v3-apidocs.cloudfoundry.org/version/3.78.0/index.html#the-app-manifest-specification).
 
-1. In a terminal, push your app by running:
+2. In a terminal, push your app by running:
 
     ```
     cf push APP-NAME --task
     ```
     Where `APP-NAME` is the name of your app.
 
-1. Run your task on the deployed app by running:
+3. Run your task on the deployed app by running:
 
     ```
     cf run-task APP-NAME --name TASK-NAME
@@ -187,7 +96,6 @@ To run a task on an app with cf CLI v7:
     
 
     
    
-    Important
     cf run-task allows you to include the --process and --command flags. Including  the --command flag overrides the manifest property.
    
 
     The following example command runs a task on the `example-app` app:
@@ -203,7 +111,7 @@ To run a task on an app with cf CLI v7:
     Task 1 has been submitted successfully for execution.
     
    
 
-1. To display the recent logs of the app and all its tasks, run:
+4. To display the recent logs of the app and all its tasks, run:
 
     ```
     cf logs APP-NAME --recent
diff --git a/v3-commands.html.md.erb b/v3-commands.html.md.erb
deleted file mode 100644
index ae772e05..00000000
--- a/v3-commands.html.md.erb
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: Using experimental cf CLI commands
-owner: CF CLI
----
-
-
    
-Important
-This topic is no longer in use. Commands with v3- prefixes do not exist in cf CLI v7 or v8. Because these commands are experimental, they are not guaranteed to be available or compatible in subsequent cf CLI releases, and they are not guaranteed to be compatible with this version of <%= vars.app_runtime_first %>. <%= vars.company_name %> recommends upgrading to cf CLI v8. For more information, see Upgrading to cf CLI v8.