pivotal-cf / docs-pcf-refarch

Content Moved

The contents of docs-pcf-refarch for Ops Manager v2.7 and later have moved to the refarch subfolder of https://github.com/pivotal-cf/docs-ops-manager.

docs-pcf-refarch's Issues

2.7 Vsphere Reference Architecture formatting issue

On the documentation page for vsphere reference architecture: https://docs.pivotal.io/platform/2-7/plan/vsphere/vsphere_ref_arch.html#pas-routed-networking

There appears to be a missing closing <p> tag which is causing the following sections to be added to the note section instead of being broken out into individual sections:

docs-pcf-refarch/vsphere/vsphere_ref_arch.html.md.erb

Line 287 in 38d09ea

<p class="note"><b>Note:</b> Please refer to

You can see the formatting issue in the attached image:

Ref Arch Diagrams Should be updated with Tanzu branding

The following page has diagrams that still reference Pivotal Cloud Foundry and PKS

https://github.com/pivotal-cf/docs-pcf-refarch/blob/2.10/vsphere/vsphere_ref_arch.html.md.erb

https://docs.pivotal.io/platform/2-10/plan/vsphere/vsphere_ref_arch.html#pks-nsx-t

migrating datastore procedure does not discuss services instances

docs-pcf-refarch/vsphere/vsphere_migrate_datastore.html.md.erb

Line 99 in b8af6db

1. Select the **Recreate VMs deployed by the BOSH Director** option.

see community thread
https://community.pivotal.io/s/question/0D50e00006WQPvU/change-vsphere-datastore-recreate-bosh-vms-what-needs-to-be-done?language=en_US&s1oid=00DU0000000YQaz&s1nid=0DB0P000000PDKg&emkind=chatterCommentNotification&s1uid=0050P000007YjIk&emtm=1594635676051&fromEmail=1&s1ext=0

The doc should say recreate errands should be enabled for on demand tiles. if recreate errand does not exist then services instances will need to be recreated manually, Only after a successful run of "upgrade all service instances" errand, using the the procedure outlined in the community post.

c0-ops repo has been moved

All links referring to c0-ops repo on github should instead refer to the new github.com/pivotal-cf/aws-concourse repo instead.

vSphere datastore migration CPI timeout section out of date

Per the release notes , the timeout issue has been fixed since v20 of the vSphere CPI. In addition, the link to the KB article is broken, but this section should probably be removed all-together.

See vsphere/vsphere_migrate_datastore.html.md.erb

Step 3: Modify CPI Timeout Value (Optional)

The default timeout for the BOSH CPI is 60 minutes. When performing a datastore migration, BOSH must copy all of the data from the old disks to the new disks within this time limit. In general, most copy operations should fit within this time limit, but it ultimately depends on the hardware in your deployment and the size of your existing persistent disks.

To determine whether 60 minutes is sufficient for the datastore migration, estimate how long it takes to copy 100 GB of data. Then, based on the size of your persistent disks, determine whether 60 minutes is sufficient time to copy that amount of data.

If you have previously encountered out of sync errors when modifying your PCF deployment, you should increase the timeout value of the CPI before migrating the datastores.

To modify the default BOSH CPI timeout, follow the instructions in the following KB article.

• How to increase timeout on BOSH CPI command calls

For more information about resolving the error after migrating your datastore, see After the Migration.

TCP Router egress from AWS on Reference Architecture

We need to illustrate an exit point for any apps bound to the TCP Routers in the AWS reference architecture. Looks like GCP & Azure have a single entry point already. We should consider whether this needs to be a 1..n option on the AWS doc. Happy to help as needed.

Azure ref arch

https://raw.githubusercontent.com/pivotal-cf/docs-pcf-refarch/master/images/azure-multi-resgroup-multi-lb.png

Looking at the ALB, sys domain traffic goes to ALB apps and app traffic go through ALB API, labels seem backward on the image

AWS ref architecture document

possible to get the OmniGraffle file used to generate the AWS ref architecture document

CIDRs on the diagram do not match the CIDRs called out in the text

The CIDRs on the openstack-overview-arch diagram are as follows.

Infrastructure /26
ERT /22
Services /22
On-Demand Services /22

In the OpenStack Objects section, the text calls out the following.

Infrastructure /24
ERT /20
Services /20
On-Demand Services /24

It looks like there are updates to the diagrams in this pull request but I'm unable to see if these changes have already been made to the images.

Issues with Alternative GCP Network Layouts for PCF

Ref arch says that the main install docs for GCP uses the "Every PCF VM receives its own public IP address" approach however it looks like the docs uses the NATS approach:

https://docs.pivotal.io/pivotalcf/2-0/customizing/gcp-prepare-env.html

Image and description mismatch for Network Design section

Network Design Image below does not correspond with description. In particular it is missing IsoZone.

On the tenant side, each interface defined on the NSX Edge acts as the IP gateway for the network used on that port group. Pivotal recommends allocating the following address ranges for the networks, and defining the gateway at .1 for each:

Infra (infrastructure) network: 192.168.10.0/26
Deployment network: 192.168.20.0/22
CF Tiles network: 192.168.24.0/22
Dynamic Services network: 192.168.28.0/22
IsoZone## network: 192.168.32.0/22, Gateway at .1

https://github.com/pivotal-cf/docs-pcf-refarch/blob/1.10/vsphere/vsphere_ref_arch.html.md.erb#L132

Migrating Pivotal Platform to a New Datastore in vSphere Doc Issues

The Migrating Pivotal Platform to a New Datastore in vSphere doc (https://docs.pivotal.io/platform/2-8/plan/vsphere/vsphere_migrate_datastore.html) may have some issues:

• Step 2: Document Current Environment Settings says to "Note the datastore where each VM resides in vSphere" but the bosh instances --details command on 2.8 does not show the datastores. It only shows the disk CIDs. Unless you're telling customers to go manually document what datastore each PCF VM is on, you may want to clarify.

• Main Procedure section says, in step 7, to "Confirm that the BOSH Director VM has persistent disk on the new datastore" by "Locat[ing] the Ops Manager VM and verify that the VM has an expected value in the Provisioned Space column" which doesn't really confirm anything about the BOSH Director VM as it is a completely different VM from the Ops Manager VM. The way I was able to verify that the BOSH Director VM had a persistent disk on the new datastore was by browsing to the VM in vSphere and looking at the attached disks' file locations.

Link to KB article does not work

The link to the KB for increasing the CPI timeout should be:

https://community.pivotal.io/s/article/How-to-Increase-the-Timeout-on-Bosh-CPI-Command-Calls