[CN-1117] Remove all PCF/TAS references (#960)

* Remove all PCF/TAS references

* Update docs/modules/migrate/pages/migration-tool-imdg.adoc

Co-authored-by: rebekah-lawrence <[email protected]>

* Update docs/modules/migrate/pages/migration-tool-imdg.adoc

Co-authored-by: rebekah-lawrence <[email protected]>

* Update docs/modules/migrate/pages/migration-tool-imdg.adoc

Co-authored-by: rebekah-lawrence <[email protected]>

* Update docs/modules/migrate/pages/migration-tool-imdg.adoc

Co-authored-by: rebekah-lawrence <[email protected]>

---------

Co-authored-by: rebekah-lawrence <[email protected]>

check-links-playbook.yml

@@ -86,9 +86,6 @@ content:
   - url: https://github.com/hazelcast-guides/springboot-tomcat-session-replication
     branches: master
     start_path: docs
-  - url: https://github.com/hazelcast-guides/vmware-tanzu
-    branches: master
-    start_path: docs
   - url: https://github.com/hazelcast-guides/terraform-quickstarts
     branches: master
     start_path: docs

docs/modules/ROOT/nav.adoc

@@ -54,7 +54,6 @@ include::troubleshoot:partial$nav.adoc[]
 ** xref:clusters:discovering-native-clients.adoc[]
 include::deploy:partial$nav.adoc[]
 include::kubernetes:partial$nav.adoc[]
-* xref:deploy:deploying-in-vmware-tanzu.adoc[]
 
 .Configure and Manage Clusters
 include::configuration:partial$nav.adoc[]

docs/modules/ROOT/pages/faq.adoc

@@ -57,7 +57,7 @@ The following are the types of discovery:
 
 * Discovery by TCP/IP: The first member created in the cluster (leader) forms a list of
 IP addresses of other joining members and sends this list to these members so the members will know each other.
-* Discovery on clouds: Hazelcast supports discovery on cloud platforms such as Azure, Consul and PCF.
+* Discovery on clouds: Hazelcast supports discovery on cloud platforms such as Azure and Consul.
 * Multicast discovery: The members in a cluster discover each other by multicast, by default.
 It is not recommended for production since UDP is often blocked in production environments and other discovery mechanisms are more definite.
 

docs/modules/clusters/pages/discovery-mechanisms.adoc

@@ -87,6 +87,12 @@ the cluster with the appropriate cluster name, so you have less control on the c
 Note also that if _User Datagram Protocol (UDP) Multicast_ is blocked, as it is for most of the production environments,
 discovering with multicast does not work.
 
+== Hazelcast for Kubernetes
+
+You can deploy a Hazelcast cluster to Kubernetes using Helm or xref:deploy:deploying-with-operator[Hazelcast Enterprise Operator].
+See the xref:kubernetes:deploying-in-kubernetes.adoc[Deploying in Kubernetes section].
+
+
 [[eureka-cloud-discovery]]
 == Eureka Cloud Discovery
 
@@ -99,14 +105,3 @@ See the xref:plugins:cloud-discovery.adoc#hazelcast-cloud-discovery-plugins-eure
 This discovery mechanism provides a service based discovery strategy by using
 Apache Curator to communicate with your Zookeeper server.
 See the xref:plugins:cloud-discovery.adoc#hazelcast-cloud-discovery-plugins-zookeeper[Cloud Discovery Plugins: Hazelcast Zookeeper section].
-
-== Hazelcast for Kubernetes
-
-You can deploy a Hazelcast cluster to Kubernetes using Helm or xref:deploy:deploying-with-operator[Hazelcast Enterprise Operator].
-See the xref:kubernetes:deploying-in-kubernetes.adoc[Deploying in Kubernetes section].
-
-[[hazelcast-for-pcf]]
-== Hazelcast for Tanzu VMware
-
-Using a clickable Hazelcast Tile for VMWare (former Pivotal Cloud Foundry), you can
-deploy your Hazelcast cluster on PCF. See the xref:deploy:deploying-in-vmware-tanzu.adoc[Deploying in VMware Tanzu section].

docs/modules/deploy/pages/versioning-compatibility.adoc

@@ -114,9 +114,6 @@ Hazelcast Platform has been tested against the following operating systems.
 |Azure
 |✓
 
-|VMWare Tanzu (formerly known as Pivotal Cloud Foundry)
-|Tail not released yet
-
 |RedHat OpenShift
 |✓
 

docs/modules/getting-started/pages/editions.adoc

@@ -15,7 +15,6 @@ The Enterprise edition offers the following features, which are not available in
 * xref:security:overview.adoc[Security suite]
 * xref:wan:wan.adoc[]
 * xref:cp-subsystem:persistence.adoc[]
-* xref:deploy:deploying-in-vmware-tanzu.adoc[Deploying in VMware Tanzu]
 * xref:kubernetes:deploying-in-kubernetes.adoc[Deploying in Openshift container platform]
 * xref:maintain-cluster:monitoring.adoc#clustered-jmx-and-rest-via-management-center[Clustered REST]
 * xref:maintain-cluster:monitoring.adoc#clustered-jmx-and-rest-via-management-center[Clustered JMX]

docs/modules/getting-started/pages/install-enterprise.adoc

@@ -162,7 +162,6 @@ Get started with the Hazelcast Enterprise features with a series of xref:enterpr
 * xref:security:overview.adoc[Security suite]
 * xref:wan:wan.adoc[]
 * xref:cp-subsystem:persistence.adoc[]
-* xref:deploy:deploying-in-vmware-tanzu.adoc[Deploying in VMware Tanzu]
 * xref:kubernetes:deploying-in-kubernetes.adoc[Deploying in Openshift container platform]
 * xref:maintain-cluster:monitoring.adoc#clustered-jmx-and-rest-via-management-center[Clustered REST]
 * xref:maintain-cluster:monitoring.adoc#clustered-jmx-and-rest-via-management-center[Clustered JMX]

docs/modules/migrate/pages/migration-tool-imdg.adoc

@@ -76,7 +76,7 @@ The members of the 3.12.x cluster should have a minor version of at least 3.12 (
 all other (plain) members should be 5.x. The migration member can also be
 a "lite" member while the other plain members need not be.
 Making the migration member a "lite" member will also simplify further migration steps.
-The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions, for example in PCF) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation rate on the source cluster, the WAN tuning parameters, the resources given to the 5.x cluster members, the load on the 5.x cluster which isn't related to the migration process, if migration members are lite members or not and many more. A good rule of thumb is starting with the same number of migration members as the number of members which are usually involved in WAN replication (if you were already using WAN replication to replicate data between different clusters) or to simply use an equal number of migration and plain members and then decrease the number of migration members if testing the migration scenario shows that the decreased number can handle the migration load.
+The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation rate on the source cluster, the WAN tuning parameters, the resources given to the 5.x cluster members, the load on the 5.x cluster that isn't related to the migration process, if migration members are lite members or not and many more. A good rule of thumb is starting with the same number of migration members as the number of members which are usually involved in WAN replication (if you were already using WAN replication to replicate data between different clusters) or to simply use an equal number of migration and plain members and then decrease the number of migration members if testing the migration scenario shows that the decreased number can handle the migration load.
 3. Add WAN replication between the two clusters. As always, this can be done using the static
 configuration and can be added dynamically. The key point is that the 3.12.x cluster needs to
 replicate only to the migration members of the 5.x cluster. Other plain members are
@@ -87,7 +87,7 @@ See also the xref:wan:wan.adoc[WAN Replication section] for the details.
 you can use WAN sync for `IMap` or wait until enough entries have been replicated in case of `IMap` or `ICache`.
 5. After enough data has been replicated to the 5.x cluster, you can shut down the 3.12.x cluster. You can check if your map data is in sync by using merkle tree sync with the caveat that in some edge cases, the merkle tree consistency check may indicate that the clusters are out-of-sync while in reality they are actually in-sync. In other cases, once WAN sync completes successfully and if there are no errors, the map data should be synchronized.
 See <<limitations-and-known-issues, Limitations and Known Issues section>> for more information when using merkle trees for consistency checks.
-6. Finally, you can simply shut down the 5.x migration members or do a rolling restart of these members to plain members. If your 5.x cluster was comprised entirely out of migration members, you will need to do a rolling restart of the entire cluster (for example, when migrating in PCF). At this point, the 5.x cluster should have only plain members.
+6. Finally, you can shut down the 5.x migration members, or do a rolling restart of these members to plain members. If your 5.x cluster was comprised entirely out of migration members, you must do a rolling restart of the entire cluster. At this point, the 5.x cluster has only plain members.
 You can also continue using this cluster or continue onto rolling upgrade to 5.x, for instance.
 
 **Migrating from 5.x to 3.12.x (ACTIVE/PASSIVE):**
@@ -105,7 +105,7 @@ between the 5.x cluster and the 3.12.x cluster but this will be described soon.
 2. Next, set up a 3.12.x cluster. It must have at least one migration member and all other
 (plain) members should have a version of 3.12 (any patch level). The migration member
 can also be a "lite" member while other plain members need not be. Making the migration
-member a "lite" member will also simplify further migration steps. The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions, for example in PCF) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation
+member a "lite" member will also simplify further migration steps. The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation
 rate on the source cluster, the WAN tuning parameters, the resources given to the 3.12.x cluster members, the load on the 3.12.x cluster which isn't related to the migration process, if
 migration members are lite members or not and many more. A good rule of thumb is starting with the same number of migration members as the number of members which are usually involved in WAN replication (if you were already using WAN replication to replicate data between different clusters) or to simply use an equal number of migration and plain members and then decrease the number of migration members if testing the migration scenario shows that the decreased number can handle the migration load.
 3. Set up WAN replication between the two clusters. As always, this can be done using static
@@ -117,7 +117,7 @@ WAN replication towards a 5.x cluster and no special configuration is needed.
 See <<limitations-and-known-issues, Limitations and Known Issues section>> for more information when using merkle  trees for consistency checks.
 5. After enough data has been replicated to the 3.12.x cluster, you can shut down the 5.x cluster.
 6. Finally, you can simply shut down the 3.12.x migration members or do a rolling restart of
-these members to plain members. If your 3.12.x cluster was comprised entirely out of migration members, you will need to do a rolling restart of the entire cluster (for example, when migrating in PCF). At this point, the 3.12.x cluster should have only plain members.
+these members to plain members. If your 3.12.x cluster was comprised entirely out of migration members, you must do a rolling restart of the entire cluster. At this point, the 3.12.x cluster has only plain members.
 
 **Bidirectional Migrating between 3.12.x and 5.x (ACTIVE/ACTIVE):**
 
@@ -128,7 +128,7 @@ between 3.12.x and 5.x. In case you are using additional 3.12.x or 5.x clusters
 The process is simply a combination of the first two scenarios:
 
 1. The first step is to set up the 3.12.x and 5.x clusters. You can also use existing clusters.
-Each of these clusters must have at least one migration member. The migration member can also be a "lite" member while other plain members need not be. Making the migration member a "lite" member will also simplify further migration steps. Other plain members of the 3.12/4.x cluster can be of any patch version. The exact ratio of migration and plain members depends on your environment. In some cases it will not be possible to mix members of different "types" (or versions, for example in PCF) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters such as the map and cache mutation
+Each of these clusters must have at least one migration member. The migration member can also be a "lite" member while other plain members need not be. Making the migration member a "lite" member also simplifies further migration steps. Other plain members of the 3.12/4.x cluster can be of any patch version. The exact ratio of migration and plain members depends on your environment. In some cases, it will not be possible to mix members of different "types" (or versions) and in those cases you can create a cluster comprised entirely out of migration members. In other cases, the exact ratio of member types depends on parameters, such as the map and cache mutation
 rate on the source cluster, the WAN tuning parameters, the resources given to the cluster
 members, the load on the clusters which isn't related to the migration process, if migration
 members are lite members or not and many more. A good rule of thumb is starting with
@@ -152,7 +152,7 @@ trees for consistency checks.
 4. After enough data has been replicated, you can shut down either of the clusters and afterwards shut down the
 remaining migration members or do a rolling restart of these members to plain members. If any of the clusters
 that you are keeping is comprised entirely out of migration members, you will need to do a rolling restart of
-the entire cluster (for example, when migrating in PCF).
+the entire cluster.
 
 [#wan-event-forwarding]
 **WAN Event Forwarding:**