The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["4a4f7bfab570786cd33c421f5673dade4976464e"]

Our PCF doc do not describe that any customer-updated buildpack will be overriden by the buildpack version in an Elastic runtime upgrade

As cf-release contains buildpack and is somewhat frozen in minor Elastic runtime version (1.7.1 as same cf-release as 1.7.12 etc) - this introduces the risk of version rollback of buildpack

In Java buildpack this could even mean downtime - please see details scenario at https://gopivotal-com.socialcast.com/messages/32460413?ref=stream

I'm installing PCF on AWS and deploying Elastic Runtime v1.10.8 build 7 using this doc. Step 10 requires to specify Service Provider Credentials and Service Provider Password. Couldn't find info about it in documentation. Attached screenshot.
Could you please add it?
Thanks,
Daniil.

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["bf045fe0161c36700eea66bcf7ff7a9dcef77f90"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["89234e46bc5f41e755b5300a2088dbfa37c1ef72"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["31b4cf64475e013cee6451739c3b380d389798a9"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["cd6075ddcef35b22e1e7cef8c340ff04cd841055"]

The instructions for logging into the internal UAAC in the advanced troubleshooting guidance has an IP address which is confusing:

$ bosh --ca-cert /var/tempest/workspaces/default/root_ca_certificate target 192.0.2.6

IMO this should be (like the previous example in that doc):

$ bosh --ca-cert /var/tempest/workspaces/default/root_ca_certificate target DIRECTOR-IP-ADDRESS

Thanks!

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["fd23174c86c17b50f1aff26ed6cccb5f64acd4ac"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["508b2d0cf325a60cc8881b1f6bc154400a2d450f"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["921328ecb7af5354f41aa4d907231971cbfa5d71"]

Hi Ben, not sure if you purposely link to the manual restore in this paragraph, but it looks like it may be better to link to the bbr restore from here, since this page has the bbr backup:

"This topic describes the procedure for backing up your critical backend PCF components with BOSH Backup and Restore (BBR), a command-line tool for backing up and restoring BOSH deployments. To restore your backup, see the Restoring Pivotal Cloud Foundry from Backup topic."

Hi Team,

Reference link: https://docs.pivotal.io/pivotalcf/1-10/customizing/cloudform-er-config.html
While installing PCF on AWS ,as mentioned in Step2, download and import Elastic Runtime file(*.pivotal) size of approx 6GB takes very long time and mostly it gets fail while uploading.

Can you please suggest an alternative to it as this documentation process does not succeed ?

Thanks,
Sushil

It's not clear which Load Balancer Type to select when manually configuring PCF on AWS.

https://docs.pivotal.io/pivotalcf/1-9/customizing/pcf-aws-manual-config.html#pcfaws-lb

The docs for Azure Install shows an outdated screenshot. See Step 3 - https://docs.pivotal.io/pivotalcf/1-10/customizing/pcf_azure.html#getting-started

I have included what the Microsoft looks like now.

This section says that we don't support the F-Series in the North Central region. This information is stale. The source of truth for what regions support what instance types is on Azure's website. I believe we should not not have this caveat on our page mention which specific instance types are not supported in which specific regions, but simply say that some instances types may not be supported in some regions, and then link to the Azure webpage.

NOTES:

• Originally story adding the caveat: https://www.pivotaltracker.com/n/projects/923920/stories/134019579
• Original blog post from Azure announcing F-Series: https://azure.microsoft.com/en-us/blog/f-series-vm-size/

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["c6129397f4e8927e132e92ad1dc43e9eda9d8946"]

(reported by a partner)

http://docs.pivotal.io/pivotalcf/1-10/customizing/azure-er-config.html#create-dbs

Does not list the networkpolicyserver database that seems to be required by ERT 1.10.2 (and possibly earlier versions, I have not attempted those). Not creating that database results in the error:

Database verification error: Unknown database 'networkpolicyserver'

Started updating instance cloud_controller > cloud_controller/35b6d54c-4c20-4fbe-a065-d9eca6b950e1 (0) (canary). Failed: 'cloud_controller/0 (35b6d54c-4c20-4fbe-a065-d9eca6b950e1)' is not running after update. Review logs for failed jobs: policy-server (00:06:03)

Error 400007: 'cloud_controller/0 (35b6d54c-4c20-4fbe-a065-d9eca6b950e1)' is not running after update. Review logs for failed jobs: policy-server

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["d1327056d5dadc89b50816d2aad25f5e091ea2f5"]

In my experience with helping people install on GCP, the overview of the reference architecture is sometimes missed when on gcp-prepare-env.html.md.erb (perhaps because people are going straight to that page from an external link). Because that is the page that is walking through setting up the architecture, it would be helpful to have a link to the reference architecture page like there is on gcp.html.md.erb.

Thanks!

I had a few troubles with TCP Routing on GCP / PCF 1.10.0.

Health Check

Health check for TCP router is not as same as WebSocket's.

80 port is correct for TCP Router's health check.

Target Tag

pcf-cf-tcp does not exist in tcp router's tags. So firewall seems to block routing to tcp_router VM.

After changing the target tag to pcf-tcp-router, it works.

Following http://docs.pivotal.io/pivotalcf/1-9/customizing/gcp-er-config.html#filestore to install PCF my initial deploy failed because I already had a different project selected in the "default project for interoperable access" field than the project I was installing PCF into. This wasn't necessarily intentional, I just skipped over that part of the page because it wasn't mentioned in the instructions.

I suggest adding a sentence to Step 13, e.g. within point 3 after the sentence about enabling interoperable access add:

If interoperable access is already enabled, check that the default project setting matches the project you are installing PCF into as shown in the screenshot below.

or similar.

in the file - network-segmentation.html.md.erb

It was saying ops manager director need to be at the same network as vCenter, same showed in the pictures. I think as long as the network is routable, it would be fine. Never saw enterprise customers put their director to be on the same network as vCenter and it worked fine.

This may unnecessarily restrict the network requirements for PCF deployment. Thoughts?

In my experience with people new to PCF, they sometimes get to the end of gcp-er-config.html.md.erb and don't know next steps (e.g. how to find out the URL for their API for targeting).

My suggestion is to have a section saying something to the effect of "Congrats, now you've got an ERT. Now check out the Operators Guide!".

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["28820589b943e59160fcf8d5d2e94f6686eabccf"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["9b9ed88d633ed9bc80fc173c17fdc2225d9f6522"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["d6efb94be86461ed8def1db2460043aa177f813b"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["b81deeda203ffcee9979ace092a8a5c6ad0152a1"]

It looks like the arm template @ http://docs.pivotal.io/azure-deploy-parameters.json called out in step 3 of http://docs.pivotal.io/pivotalcf/1-8/customizing/azure-arm-template.html does not create the pcf-nsg network security group that is required for ops man to deploy bosh. These steps are in the manual instructions @ http://docs.pivotal.io/pivotalcf/1-8/customizing/azure-om-deploy.html step 1

Following http://docs.pivotal.io/pivotalcf/1-8/customizing/azure-prepare-env.html followed by http://docs.pivotal.io/pivotalcf/1-8/customizing/azure-arm-template.html and http://docs.pivotal.io/pivotalcf/1-8/customizing/azure-om-config.html will result in an error that the security group does not exists when saving the azure config in ops man

upgrading-pcf currently describes upgrading to v1.4.0 of Ops Manager. Can it be updated to describe the process of upgrading to 1.5.0?

I was going through the steps on Doc 1.10 and although the Azure CLI commands were technically correct...A lot of the parameters to the commands were incorrect in your samples... I was also using Azure CLI 2.0 which I think your samples are from 1.0.

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["e2a4c78c4a19c26c57bff98f81275ed11d3359af", "0c00d634fe39aa675762e6848b58575efb318812"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["ad2a7ec8406cf56a2e59eb11745bd5c7c379908e"]

Need to register your subcription with Microsoft.Storage before executing step 5 by issuing following azure cli command
azure provider register Microsoft.Storage

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["792e2f5b1b9da690838d6f99ed793d5db3c9f93b"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["20962cc82df732ab8931391064db7ff38d99fcdc"]

1.10.8 added a feature that "Allows operators to specify DNS servers that differ from those provided in their BOSH configuration." (https://docs.pivotal.io/pivotalcf/1-10/pcf-release-notes/runtime-rn.html#1.10.8)

Our documentation doesn't reflect this yet. Please update the "Step 7: Configure Application Containers" section to include a note that this is an option.

The existing docs (https://github.com/pivotal-cf/docs-pcf-install/blob/master/backup-restore/backup-pcf.html.md.erb#L220-L242) mention ssh'ing into the MySQL instance and running mysqldump. When I tried this, the mysqldump command is not found on the VM:

vcap@6c9de73f-71c3-4201-8df0-292532bfd5e7:~$ which mysqldump
vcap@6c9de73f-71c3-4201-8df0-292532bfd5e7:~$ exit

A workaround is to install mysql on the local machine and just grab the dump from there but the instructions do not mention that.

This may trip people up if they can not install mysqldump locally.

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["9f20f5fb81781202a0681b0d5431ac0e2b1afcce"]

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["250260472072d8d93aeb0c6a6466024c72008089"]

Ran into an issue installing on AWS because port 25777 was not opened. This showed up in AWS VPC Flowlogs.

https://github.com/pivotal-cf/docs-pcf-install/blob/master/backup-settings.html.md.erb

A few tweaks necessary for CC backups:

• The CC job names have changed for the latest PCF release
• There are now two jobs that might be necessary to stop ( CC worker)
• Not sure why the uuid search/replace is necessary.
• Make it clearer that the pg_dump is carried out after SSH-ing to the appropriate Postgres box.

Hi,
I am just curious to know that is there any way to use Apache NIFI as service in Pivotal Cloud Foundry.
If it is,then how can we achieve it.What are the steps that we should follow.
Please give your valuable suggestions for the above.
Thank you,
Mohan.V

See http://docs.pivotal.io/pivotalcf/1-7/installing/pcf-docs.html

At the bottom of the page, link View the source for this page in GitHub points to non-existent page - http://github.com/pivotal-cf/docs-pcf-gsg-master/tree/master/pcf-docs.html.md.erb

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["f6e5650f4ebd0876d16d5104e37a9f73cd8e5333"]

In https://github.com/pivotal-cf/docs-pcf-install/blob/master/azure-om-deploy.html.md.erb,

<pre class="terminal">
$ azure storage blob copy show opsmanager image.vhd
info:    Executing command storage blob copy show
<span>+</span> Getting storage blob information
data:    Copy ID                               Progress       Status
data:    ------------------------------------  -------------  -------
data:    069d413d-be05-4b12-82bc-c96dacee230e  0/31457280512  success
info:    storage blob copy show command OK
</pre>

When the Status is success, the Progress should be 31457280512/31457280512.

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["711c76086e4d223d07025a873dba3bf30d05f6c9"]

It seems the documentation is outdated (and misleading):
https://github.com/pivotal-cf/docs-pcf-install/blob/1.10/azure-arm-template.html.md.erb

1. opsmanager container is not needed for deployment storage accounts. (line 175-177)
2. stemcell container does not need to be a public blob container (can't use public in PLRS) (line 182)

The following commit(s) was made to master and causes conflicts when trying to merge with 1.8. Cherry pick the commit(s) from master to 1.8 and resolve the conflicts.["5d5c2318346b371baf7a04b8b48013417da512c2"]

On this page: http://docs.pivotal.io/pivotalcf/1-8/customizing/gcp-prepare-env.html

bosh needs an additional permission, namely:

• Project > Service Account Actor

Otherwise the "Installing BOSH" step of these docs fails when clicking Apply:
http://docs.pivotal.io/pivotalcf/1-8/customizing/gcp-om-config.html