Link to bosh-deployment on main

content/azure-managed-identity.md

@@ -22,7 +22,7 @@ Next is updating your bosh manifest and add the property _default_managed_identi
       use_managed_disks: true
 ```
 
-There is also an [azure/use-managed-identity.yml operator file](https://github.com/cloudfoundry/bosh-deployment/blob/master/azure/use-managed-identity.yml) that you can use to make these changes.
+There is also an [azure/use-managed-identity.yml operator file](https://github.com/cloudfoundry/bosh-deployment/blob/main/azure/use-managed-identity.yml) that you can use to make these changes.
 
 Once deployed and your BOSH director VM has been recreated, it should have a "User Managed" identity with the name you specified on the ``user_assigned_identity_name`` property (see example above).  
 You can check this by going to Azure Portal _=> Virtual Machines => select BOSH director VM => Identities_

content/compiled-releases.md

@@ -89,4 +89,4 @@ Now your directory "./releases" should contain both tarballs with compiled and n
 - releases/bpm-1.2.17-ubuntu-jammy-1.406.tgz
 - releases/bpm-release-1.2.17.tgz
 
-A shared Concourse Task is maintained in the [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment/blob/master/ci/tasks/shared/bosh-agent-compile.yml) repo that can be used for compiling releases on Concourse workers.
+A shared Concourse Task is maintained in the [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment/blob/main/ci/tasks/shared/bosh-agent-compile.yml) repo that can be used for compiling releases on Concourse workers.

content/director-blobstore-signed-urls.md

@@ -33,7 +33,7 @@ templates of some CPIs.
 
 An ops-file in bosh-deployment can be used to enable signed URLs and manage
 the unnecessary properties.
-See the [bosh-deployment › misc/blobstore-signed-urls.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/misc/blobstore-signed-urls.yml)
+See the [bosh-deployment › misc/blobstore-signed-urls.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/misc/blobstore-signed-urls.yml)
 ops file.
 
 ### Removing blobstore credentials from agent VM

content/director-metrics.md

@@ -5,7 +5,7 @@
 
 As of `v270.10.0` the director can now be deployed with a co-located metrics server which will report Prometheus style metrics about the director and it's deployed VMs.
 
-The metrics server can be enabled by setting the `properties.director.metrics_server.enabled` property to true. If you are using [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment), the [`experimental/enable-metrics.yml`](https://github.com/cloudfoundry/bosh-deployment/blob/master/experimental/enable-metrics.yml) operations file will enable the metrics server.
+The metrics server can be enabled by setting the `properties.director.metrics_server.enabled` property to true. If you are using [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment), the [`experimental/enable-metrics.yml`](https://github.com/cloudfoundry/bosh-deployment/blob/main/experimental/enable-metrics.yml) operations file will enable the metrics server.
 
 Currently the metrics server is secured using mutual auth TLS. In order to successfully enable the metrics server, you will need to specify the following variables:
 

content/dns.md

@@ -140,7 +140,7 @@ The following queries demonstrate the expected resolution behaviors:
 
 DNS release provides a way to reference all instances (or a subset of instances) in a link via single DNS record. Instances can be queried using their DNS addresses and optional filters to limit results (see [Constructing Queries](#constructing-queries) for more information). The notion of instance healthiness is directly tied to the state of processes running on a VM. DNS release will continuously poll for updated healthiness information (same information is visible via `bosh instances --ps` command) on all instances from groups that were resolved at least once.
 
-To enable healthiness, use `health.enabled` property and specify necessary TLS certificates. Canonical DNS runtime config with healthiness enabled can be found here: https://github.com/cloudfoundry/bosh-deployment/blob/master/runtime-configs/dns.yml.
+To enable healthiness, use `health.enabled` property and specify necessary TLS certificates. Canonical DNS runtime config with healthiness enabled can be found here: https://github.com/cloudfoundry/bosh-deployment/blob/main/runtime-configs/dns.yml.
 
 By default, a VM is considered healthy if the process manager reports all processes as healthy (e.g. `monit`). For specific jobs, release authors may install a script at `bin/dns/healthy` to provide more precise healthiness checks. The `healthy` script must exit `0` if the job is healthy, or any other exit code for unhealthy. These scripts are run at regular intervals (by default, 5s) in addition to checking the status from the process manager. If any processes are failing or any `healthy` script reports as unhealthy, the VM will be considered unhealthy.
 
@@ -329,7 +329,7 @@ Both proxied and direct define api.bosh.internal as an alias, but with different
 
 DNS release provides a way to enable response caching based on response TTLs. Enabling caching typically will alleviate some pressure from your upstream DNS servers and decrease latency of DNS resolutions.
 
-To enable caching, use `cache.enabled` property. Canonical DNS runtime config with caching enabled can be found in the [dns.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/runtime-configs/dns.yml).
+To enable caching, use `cache.enabled` property. Canonical DNS runtime config with caching enabled can be found in the [dns.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/runtime-configs/dns.yml).
 
 ### Additional Handlers
 
@@ -359,7 +359,7 @@ Enabling `local_dns.enabled` configuration will make Director broadcast DNS upda
 
 If you were relying on instance index based DNS records, you must enable [`local_dns.include_index` property](https://bosh.io/jobs/director?source=github.com/cloudfoundry/bosh#p=director.local_dns.enabled) in the Director job.
 
-Additionally, you should colocate DNS release via an addon in all your deployments. See [bosh-deployment's runtime-configs/dns.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/runtime-configs/dns.yml) as an example.
+Additionally, you should colocate DNS release via an addon in all your deployments. See [bosh-deployment's runtime-configs/dns.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/runtime-configs/dns.yml) as an example.
 
 ---
 
@@ -373,7 +373,7 @@ To disable the native BOSH functionality, you must disable the [`local_dns.enabl
 
 ## DNS Monitoring {: #monitoring }
 
-DNS release provides monitoring, which can be enabled with [`metrics.enabled` property](https://bosh.io/jobs/bosh-dns?source=github.com/cloudfoundry/bosh-dns-release#p%3dmetrics.enabled) or with this [addon config](https://github.com/cloudfoundry/bosh-deployment/blob/master/misc/dns-addon-enable-local-monitoring.yml). By default the metrics endpoint will be exposed on `http://127.0.0.1:53088/metrics`. The bind address for the metrics server could be change with [`metrics.address` property](https://bosh.io/jobs/bosh-dns?source=github.com/cloudfoundry/bosh-dns-release#p%3dmetrics.address) and the port with [`metrics.port` property](https://bosh.io/jobs/bosh-dns?source=github.com/cloudfoundry/bosh-dns-release#p%3dmetrics.port) or with this [addon config](https://github.com/cloudfoundry/bosh-deployment/blob/master/misc/dns-addon-enable-external-monitoring.yml).
+DNS release provides monitoring, which can be enabled with [`metrics.enabled` property](https://bosh.io/jobs/bosh-dns?source=github.com/cloudfoundry/bosh-dns-release#p%3dmetrics.enabled) or with this [addon config](https://github.com/cloudfoundry/bosh-deployment/blob/main/misc/dns-addon-enable-local-monitoring.yml). By default the metrics endpoint will be exposed on `http://127.0.0.1:53088/metrics`. The bind address for the metrics server could be change with [`metrics.address` property](https://bosh.io/jobs/bosh-dns?source=github.com/cloudfoundry/bosh-dns-release#p%3dmetrics.address) and the port with [`metrics.port` property](https://bosh.io/jobs/bosh-dns?source=github.com/cloudfoundry/bosh-dns-release#p%3dmetrics.port) or with this [addon config](https://github.com/cloudfoundry/bosh-deployment/blob/main/misc/dns-addon-enable-external-monitoring.yml).
 
 ---
 

content/init-azure.md

@@ -8,7 +8,7 @@ If you do not have an Azure account, [create one](https://azure.microsoft.com/en
 
 Then follow this [guide](https://github.com/cloudfoundry/bosh-azure-cpi-release/blob/main/docs/get-started/create-service-principal.md) to create your Azure service principal.
 
-Use the [Azure templates in `bosh-deployment`](https://github.com/cloudfoundry/bosh-deployment/tree/master/azure) to initialize the new environment on Microsoft Azure.
+Use the [Azure templates in `bosh-deployment`](https://github.com/cloudfoundry/bosh-deployment/tree/main/azure) to initialize the new environment on Microsoft Azure.
 
 To prepare your Azure environment find out and/or create any missing resources in Azure. If you are not familiar with Azure take a look at [Creating Azure resources](azure-resources.md) page for more details on how to create and configure necessary resources:
 

content/init-openstack.md

@@ -240,16 +240,16 @@ See [OpenStack CPI errors](openstack-cpi-errors.md) for list of common errors an
 
 #### Customize the Deployment {: #customize-deployment }
 
-- using internal DNS, i.e. if it is required to resolve the OpenStack API endpoint: [bosh-deployment/misc/dns.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/misc/dns.yml)
-- using `boot-from-volume` to have nova create the boot volume as a cinder device (necessary for live-migration of VMs): [bosh-deployment/openstack/boot-from-volume.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/boot-from-volume.yml)
-- using a custom CA for your OpenStack endpoints: [bosh-deployment/openstack/custom-ca.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/custom-ca.yml)
-- putting additional trusted certificates into the cert-store of deployed VMs: [bosh-deployment/openstack/trusted-certs.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/trusted-certs.yml)
-- using a custom ntp server for deployed VMs: [bosh-deployment/misc/ntp.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/misc/ntp.yml)
-- using keystone v2 instead of keystone v3: [bosh-deployment/openstack/keystone-v2.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/keystone-v2.yml)
-- enable soft anti affinity for each instance group: [bosh-deployment/openstack/auto-anti-affinity.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/auto-anti-affinity.yml)
-- disable human readable VM names and use UUIDs instead: [bosh-deployment/openstack/disable-readable-vm-names.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/disable-readable-vm-names.yml)
-- using nova networking instead of neutron networking: [bosh-deployment/openstack/nova-networking.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/openstack/nova-networking.yml)
-- enable native CPI disk resizing: [bosh-deployment/misc/cpi-resize-disk.yml](https://github.com/cloudfoundry/bosh-deployment/blob/master/misc/cpi-resize-disk.yml)
+- using internal DNS, i.e. if it is required to resolve the OpenStack API endpoint: [bosh-deployment/misc/dns.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/misc/dns.yml)
+- using `boot-from-volume` to have nova create the boot volume as a cinder device (necessary for live-migration of VMs): [bosh-deployment/openstack/boot-from-volume.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/boot-from-volume.yml)
+- using a custom CA for your OpenStack endpoints: [bosh-deployment/openstack/custom-ca.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/custom-ca.yml)
+- putting additional trusted certificates into the cert-store of deployed VMs: [bosh-deployment/openstack/trusted-certs.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/trusted-certs.yml)
+- using a custom ntp server for deployed VMs: [bosh-deployment/misc/ntp.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/misc/ntp.yml)
+- using keystone v2 instead of keystone v3: [bosh-deployment/openstack/keystone-v2.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/keystone-v2.yml)
+- enable soft anti affinity for each instance group: [bosh-deployment/openstack/auto-anti-affinity.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/auto-anti-affinity.yml)
+- disable human readable VM names and use UUIDs instead: [bosh-deployment/openstack/disable-readable-vm-names.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/disable-readable-vm-names.yml)
+- using nova networking instead of neutron networking: [bosh-deployment/openstack/nova-networking.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/openstack/nova-networking.yml)
+- enable native CPI disk resizing: [bosh-deployment/misc/cpi-resize-disk.yml](https://github.com/cloudfoundry/bosh-deployment/blob/main/misc/cpi-resize-disk.yml)
 
 ### Connect to the Director
 

content/jumpbox.md

@@ -6,7 +6,7 @@ It's recommended:
 - do not SSH to the Director
 - use `bosh ssh` to access VMs in your deployments and use jumpbox VM as your SSH gateway
 
-To obtain SSH access specifically to the Director VM when necessary you can opt into [`jumpbox-user.yml` ops file](https://github.com/cloudfoundry/bosh-deployment/blob/master/jumpbox-user.yml) when running [`bosh create-env` command](cli-v2.md#create-env). It will add a `jumpbox` user to the VM (by using `user_add` job from `cloudfoundry/os-conf-release`).
+To obtain SSH access specifically to the Director VM when necessary you can opt into [`jumpbox-user.yml` ops file](https://github.com/cloudfoundry/bosh-deployment/blob/main/jumpbox-user.yml) when running [`bosh create-env` command](cli-v2.md#create-env). It will add a `jumpbox` user to the VM (by using `user_add` job from `cloudfoundry/os-conf-release`).
 
 ```shell
 bosh int creds.yml --path /jumpbox_ssh/private_key > jumpbox.key

content/ntp-config.md

@@ -63,7 +63,7 @@ property on that instance group in its deployment manifest.
 
 In order to completely disable NTP client configuration on one instance group, 
 specify an empty list `env.bosh.ntp=[]` on the instance group, and also configure
-an empty ntp list in the [bosh director default configuration of the cpi-release](https://github.com/cloudfoundry/bosh-deployment/blob/master/vsphere/cpi.yml), for
+an empty ntp list in the [bosh director default configuration of the cpi-release](https://github.com/cloudfoundry/bosh-deployment/blob/main/vsphere/cpi.yml), for
 example [vsphere-cpi](https://github.com/cloudfoundry/bosh-vsphere-cpi-release/blob/34e66c47002c42e37970a02256f13be07a5d138f/jobs/vsphere_cpi/spec#L97-L101)
 
 ## Configuring NTP via CPI job properties is DEPRECATED

content/quick-start.md

@@ -27,7 +27,7 @@ Next, we'll use [bosh-deployment](https://github.com/cloudfoundry/bosh-deploymen
 git clone https://github.com/cloudfoundry/bosh-deployment.git
 ```
 
-Now, we can run the [`virtualbox/create-env.sh`](https://github.com/cloudfoundry/bosh-deployment/blob/master/virtualbox/create-env.sh) script to create our test director and configure the environment with some defaults.
+Now, we can run the [`virtualbox/create-env.sh`](https://github.com/cloudfoundry/bosh-deployment/blob/main/virtualbox/create-env.sh) script to create our test director and configure the environment with some defaults.
 
 ```shell
 ./bosh-deployment/virtualbox/create-env.sh
@@ -95,7 +95,7 @@ Run through quick steps below or follow [deploy workflow](basic-workflow.md) tha
 
 ## Clean up
 
-The test director can be deleted using the [`virtualbox/delete-env.sh`](https://github.com/cloudfoundry/bosh-deployment/blob/master/virtualbox/delete-env.sh) script.
+The test director can be deleted using the [`virtualbox/delete-env.sh`](https://github.com/cloudfoundry/bosh-deployment/blob/main/virtualbox/delete-env.sh) script.
 
 ```shell
 ./bosh-deployment/virtualbox/delete-env.sh

content/update-cloud-config.md

@@ -37,7 +37,7 @@ compilation:
   network: default
 ```
 
-(Taken from <https://github.com/cloudfoundry/bosh-deployment/blob/master/warden/cloud-config.yml>)
+(Taken from <https://github.com/cloudfoundry/bosh-deployment/blob/main/warden/cloud-config.yml>)
 
 Without going into much detail, above cloud config defines three [availability zones](terminology.md#az), one `default` [VM type](terminology.md#vm-type) and one `default` [disk types](terminology.md#disk-type) and a `default` [network](networks.md). All of these definitions will be referenced by the deployment manifest.
 

content/warden-cpi.md

@@ -127,7 +127,7 @@ properties:
 
 ## Example Cloud Config {: #cloud-config }
 
-See [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment/blob/master/warden/cloud-config.yml).
+See [bosh-deployment](https://github.com/cloudfoundry/bosh-deployment/blob/main/warden/cloud-config.yml).
 
 ---