+Tanzu Operations Manager Verifier failures when applying changes will prevent deployment.
+In cases where these verifiers are incorrectly failing for known reasons,
+they should be disabled using om.
+The IGNORE_WARNINGS parameter for the
+apply-changes, stage-configure-apply, and apply-director-changes tasks
+allows users to ignore all warnings from ignorable verifiers.
+In an automation context, disabling only the particular verifiers
+where failure is well-understood allows other verifiers
+to continue to provide important feedback.
+Some verifiers continue to return warnings even when disabled,
+preventing deployment without the IGNORE_WARNINGS: true param set.
+If the verifiers that are preventing deployment
+are known issues based on the environment setup,
+then it is safe to use the flag.
+VMware recommends persisting the zip file exported from export-installation +to an external file store (for example, S3) on a regular basis. +The exported installation can restore the Tanzu Operations Manager +to a working state if it is not working.
diff --git a/docs/.external_link_url.md b/docs/_external_link_url.html.md.erb similarity index 100% rename from docs/.external_link_url.md rename to docs/_external_link_url.html.md.erb diff --git a/docs/.internal_link_url.md b/docs/_internal_link_url.html.md.erb similarity index 92% rename from docs/.internal_link_url.md rename to docs/_internal_link_url.html.md.erb index 492e52a8..87ed6127 100644 --- a/docs/.internal_link_url.md +++ b/docs/_internal_link_url.html.md.erb @@ -1,4 +1,4 @@ - +[activate-certificate-authority]: {{ path }}tasks.md#activate-certificate-authority [advanced-pipeline-design]: {{ path }}pipeline-design/configuration-management-strategies.md#advanced-pipeline-design [apply-changes]: {{ path }}tasks.md#apply-changes [apply-director-changes]: {{ path }}tasks.md#apply-director-changes @@ -14,12 +14,14 @@ [configure-authentication]: {{ path }}tasks.md#configure-authentication [configure-director]: {{ path }}tasks.md#configure-director [configure-ldap-authentication]: {{ path }}tasks.md#configure-ldap-authentication +[configure-new-certificate-authority]: {{ path }}tasks.md#configure-new-certificate-authority [configure-opsman]: {{ path }}tasks.md#configure-opsman [configure-product]: {{ path }}tasks.md#configure-product [configure-saml-authentication]: {{ path }}tasks.md#configure-saml-authentication [create-vm]: {{ path }}tasks.md#create-vm [creating-resources-for-your-ops-manager]: {{ path }}how-to-guides/installing-opsman.md#creating-resources-for-your-ops-manager [credhub-interpolate]: {{ path }}tasks.md#credhub-interpolate +[delete-certificate-authority]: {{ path }}tasks.md#delete-certificate-authority [delete-vm]: {{ path }}tasks.md#delete-vm [director-configuration]: {{ path }}how-to-guides/creating-a-director-config-file.md [disable-verifiers]: {{ path }}how-to-guides/running-commands-locally.md#disable-verifiers @@ -32,6 +34,7 @@ [expiring-certificates]: {{ path }}tasks.md#expiring-certificates [export-installation]: {{ path }}tasks.md#export-installation [fly-download-image]: {{ path }}img/concourse-fly-download.png +[generate-certificate]: {{ path }}tasks.md#generate-certificate [generating-an-auth-file]: {{ path }}how-to-guides/configuring-auth.md#generating-an-auth-file [generating-env-file]: {{ path }}how-to-guides/configuring-env.md#generating-an-env-file [getting-started]: {{ path }}getting-started.md @@ -59,8 +62,10 @@ [product-configuration]: {{ path }}how-to-guides/adding-a-product.md [reference-pipeline]: {{ path }}pipelines/multiple-products.md [reference-resources]: {{ path }}pipelines/resources.md +[regenerate-certificates]: {{ path }}tasks.md#regenerate-certificates [replicate-product]: {{ path }}tasks.md#replicate-product [revert-staged-changes]: {{ path }}tasks.md#revert-staged-changes +[rotating-certificate-authority]: {{ path }}how-to-guides/rotating-certificate-authority.md [run-bosh-errand]: {{ path }}tasks.md#run-bosh-errand [running-commands-locally]: {{ path }}how-to-guides/running-commands-locally.md [secrets-handling]: {{ path }}concepts/secrets-handling.md diff --git a/docs/_ip-addresses.md.html.md.erb b/docs/_ip-addresses.md.html.md.erb new file mode 100644 index 00000000..5f35c07f --- /dev/null +++ b/docs/_ip-addresses.md.html.md.erb @@ -0,0 +1,3 @@ ++At least one IP address (public or private) must be assigned to the Tanzu Operations Manager VM. +Both can be assigned, if required.
diff --git a/docs/_missing_fields_opsman_director.html.md.erb b/docs/_missing_fields_opsman_director.html.md.erb new file mode 100644 index 00000000..23861086 --- /dev/null +++ b/docs/_missing_fields_opsman_director.html.md.erb @@ -0,0 +1,4 @@ +
+staged-director-config will not be able to grab all sensitive fields in your Tanzu Operations Manager installation
+(for example: vcenter_username and vcenter_password if using vSphere). To find these missing fields, see the
+Tanzu Operations Manager API Documentation.
| Platform Automation Toolkit | +Concourse | +Tanzu Operations Manager | +Broadcom Support Portal | +
|---|---|---|---|
| v5.1.2+ | +v6.7.9+2 |
+ v2.9+ | +v0.31.15 | +
| v5.1.0 | +v5.0.0+1 |
+ v2.9+ | +v0.31.15 | +
+ platform-automation-image-*.tgz # all IaaSes image + vsphere-platform-automation-image-*.tar.gz # vSphere only image + platform-automation-tasks-*.zip # tasks ++ +The following are NOT covered: + +- the `om` command line tool +- the `p-automator` command line tool +- the dependencies on the image intended to be used with the tasks +- non-specified parameters (for instance, any env var used by a CLI you call, + but not specified as a parameter on the task) +- properties specific to particular product or Tanzu Operations Manager versions in config files + (which are governed by the product being configured, not our tooling) +- Versions of the included binaries. + The _presence_ of those binaries is guaranteed, but the _versions_ are not. + +In general, if we make any change +that we anticipate could not be consumed without manual changes, +we consider it a breaking change, and increment the major version accordingly. + +This assumes that the required image can be made automatically available; +each version of our tasks is designed for and tested with +_only_ the version of the image that shipped with it. + +If we accidentally violate our semver, +we will publish an additional version addressing the problem. +In some cases, that may mean releasing the same software with a corrected version, +and shipping a new patch version identical to the version prior to the violation. +In others, it may mean releasing an additional patch version +which reverts an unintentional breaking change. + +This should make it safe to automatically consume our release. +It should be very safe to automatically update to patch releases. +Minor versions should be safe, +but it can be more difficult to anticipate the effect of new features, so this is slightly riskier. +Major versions should be expected to break +for at least some users when consumed automatically. +Automatic consumption of major versions should be limited +to test and staging environments +intended to endure and detect such breakage. diff --git a/docs/compatibility-and-versioning.md b/docs/compatibility-and-versioning.md deleted file mode 100644 index 22c67f9c..00000000 --- a/docs/compatibility-and-versioning.md +++ /dev/null @@ -1,168 +0,0 @@ -This topic describes Platform Automation Toolkit dependencies and semantic versioning. - -## External Dependencies -Platform Automation Toolkit is designed to work with these dependencies. - - - -
| Platform Automation Toolkit | -Concourse | -Ops Manager | -Pivnet Resource | -
|---|---|---|---|
| v5.1.0 | -v5.0.0+1 |
- v2.3+ | -v0.31.15 | -
| v5.0.0 | -v5.0.0+1 |
- v2.3+ | -v0.31.15 | -
| v4.3.0 | -v4.0.0+1 |
- v2.3+ | -v0.31.15 | -
| v4.2.0 | -v4.0.0+ |
- v2.3+ | -v0.31.15 | -
| v4.1.0 | -v4.0.0+ |
- v2.3+ | -v0.31.15 | -
| v4.0.0 | -v4.0.0+ |
- v2.3+ | -v0.31.15 | -
+When using prepare-tasks-with-secrets, all secrets must exist in either a secrets store
+or a vars file found under VARS_PATHS.
+If a vars from a config file can't be found in CredHub,
+it must be available in a YAML file found under VARS_PATHS in prepare-tasks-with-secrets.
+This will prevent these credentials from being added as environment variables to the task; this would
+result in Concourse being unable to find them in the secrets store.
+ Unlike with credhub-interpolate,
+ there is no concept of SKIP_MISSING.
+ As such, if there are credentials that will be filled in future jobs by vars files,
+ those vars files must be provided in the vars input and the VARS_PATHS param.
+If using vars files in subsequent tasks, the vars input and the VARS_PATHS param must be used to prevent
+interpolation errors in those subsequent tasks.
+If using this, you need to ensure that the Concourse worker can talk to CredHub.
+Depending on how you deployed CredHub and/or the worker,
+this may not be possible.
+Using credhub-interpolate inverts control;
+now workers need to access CredHub.
+With prepare-tasks-with-secrets and other uses of the Concourse native integration,
+the ATC retrieves secrets from CredHub and passes them to the worker.
+ Do not run upload-stemcell until after the stage-product task has completed. When the two tasks are run in the
+ opposite order, the stemcell still auto-associates with the product.
+If you are using an additional secrets manager, such as CredHub, you can add the flag
+--skip-missing to your om interpolate call to allow parametrized variables to
+still be present in your config after interpolation, to be filled in later by
+interpolating with your secrets manager. See Using a secrets store to store credentials
+for a more detailed explanation.
+
+ decryption-passphrase: some-passphrase
+ server-url: ldap://example.com
+ ldap-username: cn=admin,dc=opsmanager,dc=com
+ ldap-password: some-password
+ user-search-base: ou=users,dc=opsmanager,dc=com
+ user-search-filter: cn={0}
+ group-search-base: ou=groups,dc=opsmanager,dc=com
+ group-search-filter: member={0}
+ ldap-rbac-admin-group-name: cn=opsmgradmins,ou=groups,dc=opsmanager,dc=com
+ email-attribute: mail
+ ldap-referrals: follow
+
+ # Optional
+ # http-proxy-url: # proxy for outbound HTTP network traffic
+ # https-proxy-url: # proxy for outbound HTTPS network traffic
+ # no-proxy: # comma-separated list of hosts that do not go
+ # through the proxy
+ # precreated-client-secret: # create a UAA client on the Ops Manager VM.
+ # this will be client-secret in env.yml
+ # client ID is precreated-client
+ # server-ssl-cert: # the server certificate when using ldaps://
+ # skip-create-bosh-admin-client: # do not create a UAA client on the BOSH
+ # director. The client is required to execute
+ # BOSH commands from the BOSH CLI
+
+
diff --git a/docs/examples/_auth-saml.html.md.erb b/docs/examples/_auth-saml.html.md.erb
new file mode 100644
index 00000000..512bf481
--- /dev/null
+++ b/docs/examples/_auth-saml.html.md.erb
@@ -0,0 +1,23 @@
+
+
+ ---
+ decryption-passphrase: decryption-passphrase
+ saml-idp-metadata: https://saml.example.com:8080
+ saml-bosh-idp-metadata: https://bosh-saml.example.com:8080
+ saml-rbac-admin-group: opsman.full_control
+ saml-rbac-groups-attribute: myenterprise
+
+ # Optional
+ # http-proxy-url: # proxy for outbound HTTP network traffic
+ # https-proxy-url: # proxy for outbound HTTPS network traffic
+ # no-proxy: # comma-separated list of hosts that do not go
+ # through the proxy
+ # precreated-client-secret: # create a UAA client on the Ops Manager VM.
+ # this will be client-secret in env.yml
+ # client ID is precreated-client
+ # server-ssl-cert: # the server certificate when using ldaps://
+ # skip-create-bosh-admin-client: # do not create a UAA client on the BOSH
+ # director. The client is required to execute
+ # BOSH commands from the BOSH CLI
+
+
diff --git a/docs/examples/_auth.html.md.erb b/docs/examples/_auth.html.md.erb
new file mode 100644
index 00000000..080274e7
--- /dev/null
+++ b/docs/examples/_auth.html.md.erb
@@ -0,0 +1,17 @@
+
+
+ ---
+ username: username
+ password: password
+ decryption-passphrase: decryption-passphrase
+
+ # Optional
+ # http-proxy-url: # proxy for outbound HTTP network traffic
+ # https-proxy-url: # proxy for outbound HTTPS network traffic
+ # no-proxy: # comma-separated list of hosts that do not go
+ # through the proxy
+ # precreated-client-secret: # create a UAA client on the Ops Manager VM.
+ # this will be client-secret in env.yml
+ # client ID is pre-created-client
+
+
diff --git a/docs/examples/_director.html.md.erb b/docs/examples/_director.html.md.erb
new file mode 100644
index 00000000..1220b4f2
--- /dev/null
+++ b/docs/examples/_director.html.md.erb
@@ -0,0 +1,47 @@
+
+
+ ---
+ az-configuration:
+ - clusters:
+ - cluster: cluster-name
+ resource_pool: resource-pool-name
+ name: AZ01
+
+ properties-configuration:
+ iaas_configuration:
+ vcenter_host: vcenter.example.com
+ vcenter_username: admin
+ vcenter_password: password
+ ......
+ director_configuration:
+ blobstore_type: local
+ bosh_recreate_on_next_deploy: false
+ custom_ssh_banner: null
+ ......
+ security_configuration:
+ generate_vm_passwords: true
+ trusted_certificates:
+ syslog_configuration:
+ enabled: false
+
+ network-assignment:
+ network:
+ name: INFRASTRUCTURE
+ other_availability_zones: []
+ singleton_availability_zone:
+ name: AZ01
+
+ networks-configuration:
+ icmp_checks_enabled: false
+ networks:
+ - name: NETWORK-NAME
+ ......
+
+ resource-configuration:
+ compilation:
+ instance_type:
+ id: automatic
+ instances: automatic
+ ......
+
+
\ No newline at end of file
diff --git a/docs/examples/download-product.yml b/docs/examples/_download-product.html.md.erb
similarity index 98%
rename from docs/examples/download-product.yml
rename to docs/examples/_download-product.html.md.erb
index 419af5d7..ed87ccca 100644
--- a/docs/examples/download-product.yml
+++ b/docs/examples/_download-product.html.md.erb
@@ -28,7 +28,7 @@ pivnet-product-slug: product-slug
blobstore-bucket: bucket-name
s3-region-name: us-west-1 # if NOT using AWS s3, value is 'region'
-## Required unless `s3-auth-type: iam`
+## Required unless "s3-auth-type: iam"
s3-access-key-id: aws-or-minio-key-id
s3-secret-access-key: aws-or-minio-secret-key
diff --git a/docs/examples/download-stemcell-product.yml b/docs/examples/_download-stemcell-product.html.md.erb
similarity index 83%
rename from docs/examples/download-stemcell-product.yml
rename to docs/examples/_download-stemcell-product.html.md.erb
index 2815ca4e..da1f71f2 100644
--- a/docs/examples/download-stemcell-product.yml
+++ b/docs/examples/_download-stemcell-product.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet download-stemcell-product-config start yaml
+
+
---
pivnet-api-token: token
pivnet-file-glob: "*vsphere*" # must be quoted if starting with a *
@@ -14,4 +15,5 @@ product-version: "250.82"
# version prepended. Set if the product will
# ever be stored in a blobstore
-# code_snippet download-stemcell-product-config end
+
+
diff --git a/docs/examples/_env-uaa.html.md.erb b/docs/examples/_env-uaa.html.md.erb
new file mode 100644
index 00000000..5802fdf0
--- /dev/null
+++ b/docs/examples/_env-uaa.html.md.erb
@@ -0,0 +1,19 @@
+
+
+ ---
+ target: https://pcf.example.com
+ connect-timeout: 30 # default 5
+ request-timeout: 1800 # default 1800
+ skip-ssl-validation: false # default false
+ client-id: client_id
+ client-secret: client_secret
+ # decryption-passphrase is optional,
+ # except for use with `import-installation`.
+ # OpsMan depends on the passphrase
+ # to decrypt the imported installation.
+ # For other commands, providing this key allows
+ # decryption of the OpsMan VM after reboot,
+ # which would otherwise need to be done manually.
+ decryption-passphrase: passphrase
+
+
diff --git a/docs/examples/_env.html.md.erb b/docs/examples/_env.html.md.erb
new file mode 100644
index 00000000..8aab9ede
--- /dev/null
+++ b/docs/examples/_env.html.md.erb
@@ -0,0 +1,19 @@
+
+
+ ---
+ target: https://pcf.example.com
+ connect-timeout: 30 # default 5
+ request-timeout: 1800 # default 1800
+ skip-ssl-validation: false # default false
+ username: username
+ password: password
+ # decryption-passphrase is optional,
+ # except for use with `import-installation`.
+ # OpsMan depends on the passphrase
+ # to decrypt the imported installation.
+ # For other commands, providing this key allows
+ # decryption of the OpsMan VM after reboot,
+ # which would otherwise need to be done manually.
+ decryption-passphrase: passphrase
+
+
diff --git a/docs/examples/product.yml b/docs/examples/_product.html.md.erb
similarity index 93%
rename from docs/examples/product.yml
rename to docs/examples/_product.html.md.erb
index 9d88b365..4974dc60 100644
--- a/docs/examples/product.yml
+++ b/docs/examples/_product.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet product-configuration start yaml
+
+
---
product-properties:
.healthwatch-forwarder.bosh_taskcheck_username:
@@ -60,4 +61,5 @@ resource-config:
size_mb: automatic
instance_type:
id: automatic
-# code_snippet product-configuration end yaml
+
+
diff --git a/docs/examples/state.yml b/docs/examples/_state.html.md.erb
similarity index 100%
rename from docs/examples/state.yml
rename to docs/examples/_state.html.md.erb
diff --git a/docs/examples/telemetry.yml b/docs/examples/_telemetry.html.md.erb
similarity index 71%
rename from docs/examples/telemetry.yml
rename to docs/examples/_telemetry.html.md.erb
index ee384687..2a937398 100644
--- a/docs/examples/telemetry.yml
+++ b/docs/examples/_telemetry.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet telemetry start yaml
+
+
---
env-type: sandbox # sandbox|development|qa|pre-production|production
@@ -10,6 +11,7 @@ usage-service-client-secret:
usage-service-insecure-skip-tls-verify:
# CredHub (Optional)
-# with-credhub-info: # include Credhub certificate expiry information
+# with-credhub-info: # include CredHub certificate expiry information
-# code_snippet telemetry end
+
+
diff --git a/docs/examples/anchors/_credhub-interpolate.html.md.erb b/docs/examples/anchors/_credhub-interpolate.html.md.erb
new file mode 100644
index 00000000..c2d56d1c
--- /dev/null
+++ b/docs/examples/anchors/_credhub-interpolate.html.md.erb
@@ -0,0 +1,22 @@
+
+
+ resource-types:
+ resources:
+
+ credhub-interpolate: &credhub-interpolate
+ image: platform-automation-image
+ file: platform-automation-tasks/tasks/credhub-interpolate.yml
+ params:
+ CREDHUB_CLIENT: ((credhub-client))
+ CREDHUB_SECRET: ((credhub-secret))
+ CREDHUB_SERVER: ((credhub-server))
+ PREFIX: '/pipeline/vsphere'
+ INTERPOLATION_PATHS: "download-product-configs"
+ input_mapping:
+ files: config
+ output_mapping:
+ interpolated-files: config
+
+ jobs:
+
+
\ No newline at end of file
diff --git a/docs/examples/anchors/_subbing-credhub-interpolate.html.md.erb b/docs/examples/anchors/_subbing-credhub-interpolate.html.md.erb
new file mode 100644
index 00000000..b1f7c190
--- /dev/null
+++ b/docs/examples/anchors/_subbing-credhub-interpolate.html.md.erb
@@ -0,0 +1,6 @@
+
+
+ - task: credhub-interpolate
+ <<: *credhub-interpolate
+
+
\ No newline at end of file
diff --git a/docs/examples/anchors/credhub-interpolate.yml b/docs/examples/anchors/credhub-interpolate.yml
deleted file mode 100644
index 8cfd0bd5..00000000
--- a/docs/examples/anchors/credhub-interpolate.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-resource-types:
-resources:
-
-credhub-interpolate: &credhub-interpolate
- image: platform-automation-image
- file: platform-automation-tasks/tasks/credhub-interpolate.yml
- params:
- CREDHUB_CLIENT: ((credhub-client))
- CREDHUB_SECRET: ((credhub-secret))
- CREDHUB_SERVER: ((credhub-server))
- PREFIX: '/pipeline/vsphere'
- INTERPOLATION_PATHS: "download-product-configs"
- input_mapping:
- files: config
- output_mapping:
- interpolated-files: config
-
-jobs:
\ No newline at end of file
diff --git a/docs/examples/anchors/subbing-credhub-interpolate.yml b/docs/examples/anchors/subbing-credhub-interpolate.yml
deleted file mode 100644
index 0f578854..00000000
--- a/docs/examples/anchors/subbing-credhub-interpolate.yml
+++ /dev/null
@@ -1,2 +0,0 @@
-- task: credhub-interpolate
- <<: *credhub-interpolate
\ No newline at end of file
diff --git a/docs/examples/auth-ldap.yml b/docs/examples/auth-ldap.yml
deleted file mode 100644
index 05ec3bae..00000000
--- a/docs/examples/auth-ldap.yml
+++ /dev/null
@@ -1,27 +0,0 @@
-# code_snippet ldap-auth-configuration start yaml
-decryption-passphrase: some-passphrase
-server-url: ldap://example.com
-ldap-username: cn=admin,dc=opsmanager,dc=com
-ldap-password: some-password
-user-search-base: ou=users,dc=opsmanager,dc=com
-user-search-filter: cn={0}
-group-search-base: ou=groups,dc=opsmanager,dc=com
-group-search-filter: member={0}
-ldap-rbac-admin-group-name: cn=opsmgradmins,ou=groups,dc=opsmanager,dc=com
-email-attribute: mail
-ldap-referrals: follow
-
-# Optional
-# http-proxy-url: # proxy for outbound HTTP network traffic
-# https-proxy-url: # proxy for outbound HTTPS network traffic
-# no-proxy: # comma-separated list of hosts that do not go
- # through the proxy
-# precreated-client-secret: # create a UAA client on the Ops Manager VM.
- # this will be client-secret in env.yml
- # client ID is precreated-client
-# server-ssl-cert: # the server certificate when using ldaps://
-# skip-create-bosh-admin-client: # do not create a UAA client on the BOSH
- # director. The client is required to execute
- # BOSH commands from the BOSH CLI
-
-# code_snippet ldap-auth-configuration end
diff --git a/docs/examples/auth-saml.yml b/docs/examples/auth-saml.yml
deleted file mode 100644
index bc85e800..00000000
--- a/docs/examples/auth-saml.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-# code_snippet saml-auth-configuration start yaml
----
-decryption-passphrase: decryption-passphrase
-saml-idp-metadata: https://saml.example.com:8080
-saml-bosh-idp-metadata: https://bosh-saml.example.com:8080
-saml-rbac-admin-group: opsman.full_control
-saml-rbac-groups-attribute: myenterprise
-
-# Optional
-# http-proxy-url: # proxy for outbound HTTP network traffic
-# https-proxy-url: # proxy for outbound HTTPS network traffic
-# no-proxy: # comma-separated list of hosts that do not go
- # through the proxy
-# precreated-client-secret: # create a UAA client on the Ops Manager VM.
- # this will be client-secret in env.yml
- # client ID is precreated-client
-# server-ssl-cert: # the server certificate when using ldaps://
-# skip-create-bosh-admin-client: # do not create a UAA client on the BOSH
- # director. The client is required to execute
- # BOSH commands from the BOSH CLI
-
-# code_snippet saml-auth-configuration end
diff --git a/docs/examples/auth.yml b/docs/examples/auth.yml
deleted file mode 100644
index e5afec65..00000000
--- a/docs/examples/auth.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-# code_snippet auth-configuration start yaml
----
-username: username
-password: password
-decryption-passphrase: decryption-passphrase
-
-# Optional
-# http-proxy-url: # proxy for outbound HTTP network traffic
-# https-proxy-url: # proxy for outbound HTTPS network traffic
-# no-proxy: # comma-separated list of hosts that do not go
- # through the proxy
-# precreated-client-secret: # create a UAA client on the Ops Manager VM.
- # this will be client-secret in env.yml
- # client ID is precreated-client
-# code_snippet auth-configuration end
diff --git a/docs/examples/director.yml b/docs/examples/director.yml
deleted file mode 100644
index 7e68b721..00000000
--- a/docs/examples/director.yml
+++ /dev/null
@@ -1,45 +0,0 @@
-# code_snippet director-configuration start yaml
----
-az-configuration:
-- clusters:
- - cluster: cluster-name
- resource_pool: resource-pool-name
- name: AZ01
-
-properties-configuration:
- iaas_configuration:
- vcenter_host: vcenter.example.com
- vcenter_username: admin
- vcenter_password: password
- ......
- director_configuration:
- blobstore_type: local
- bosh_recreate_on_next_deploy: false
- custom_ssh_banner: null
- ......
- security_configuration:
- generate_vm_passwords: true
- trusted_certificates:
- syslog_configuration:
- enabled: false
-
-network-assignment:
- network:
- name: INFRASTRUCTURE
- other_availability_zones: []
- singleton_availability_zone:
- name: AZ01
-
-networks-configuration:
- icmp_checks_enabled: false
- networks:
- - name: NETWORK-NAME
- ......
-
-resource-configuration:
- compilation:
- instance_type:
- id: automatic
- instances: automatic
- ......
-# code_snippet director-configuration end
\ No newline at end of file
diff --git a/docs/examples/env-uaa.yml b/docs/examples/env-uaa.yml
deleted file mode 100644
index 9c7bcabb..00000000
--- a/docs/examples/env-uaa.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-# code_snippet env-uaa start yaml
----
-target: https://pcf.example.com
-connect-timeout: 30 # default 5
-request-timeout: 1800 # default 1800
-skip-ssl-validation: false # default false
-client-id: client_id
-client-secret: client_secret
-# decryption-passphrase is optional,
-# except for use with `import-installation`.
-# OpsMan depends on the passphrase
-# to decrypt the imported installation.
-# For other commands, providing this key allows
-# decryption of the OpsMan VM after reboot,
-# which would otherwise need to be done manually.
-decryption-passphrase: passphrase
-# code_snippet env-uaa end
diff --git a/docs/examples/env.yml b/docs/examples/env.yml
deleted file mode 100644
index f32dedb2..00000000
--- a/docs/examples/env.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-# code_snippet env start yaml
----
-target: https://pcf.example.com
-connect-timeout: 30 # default 5
-request-timeout: 1800 # default 1800
-skip-ssl-validation: false # default false
-username: username
-password: password
-# decryption-passphrase is optional,
-# except for use with `import-installation`.
-# OpsMan depends on the passphrase
-# to decrypt the imported installation.
-# For other commands, providing this key allows
-# decryption of the OpsMan VM after reboot,
-# which would otherwise need to be done manually.
-decryption-passphrase: passphrase
-# code_snippet env end
diff --git a/docs/examples/opsman-config/aws.yml b/docs/examples/opsman-config/_aws1.html.md.erb
similarity index 92%
rename from docs/examples/opsman-config/aws.yml
rename to docs/examples/opsman-config/_aws1.html.md.erb
index 4b9d7be8..e0d46565 100644
--- a/docs/examples/opsman-config/aws.yml
+++ b/docs/examples/opsman-config/_aws1.html.md.erb
@@ -1,11 +1,12 @@
-# code_snippet aws-configuration start yaml
+
+
---
opsman-configuration:
aws:
region: us-west-2
vpc_subnet_id: subnet-0292bc845215c2cbf
security_group_ids: [ sg-0354f804ba7c4bc41 ]
- key_pair_name: ops-manager-key # used to ssh to VM
+ key_pair_name: ops-manager-key # used to SSH to VM
iam_instance_profile_name: env_ops_manager
# At least one IP address (public or private) needs to be assigned to the
@@ -38,4 +39,5 @@ opsman-configuration:
# banner-settings: ...
# syslog-settings: ...
# rbac-settings: ...
-# code_snippet aws-configuration end
+
+
diff --git a/docs/examples/opsman-config/azure.yml b/docs/examples/opsman-config/_azure1.html.md.erb
similarity index 97%
rename from docs/examples/opsman-config/azure.yml
rename to docs/examples/opsman-config/_azure1.html.md.erb
index 994b186a..ca327d9e 100644
--- a/docs/examples/opsman-config/azure.yml
+++ b/docs/examples/opsman-config/_azure1.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet azure-configuration start yaml
+
+
---
opsman-configuration:
azure:
@@ -52,4 +53,5 @@ opsman-configuration:
# banner-settings: ...
# syslog-settings: ...
# rbac-settings: ...
-# code_snippet azure-configuration end
+
+
diff --git a/docs/examples/opsman-config/gcp.yml b/docs/examples/opsman-config/_gcp1.html.md.erb
similarity index 93%
rename from docs/examples/opsman-config/gcp.yml
rename to docs/examples/opsman-config/_gcp1.html.md.erb
index fb9e5747..c80c6139 100644
--- a/docs/examples/opsman-config/gcp.yml
+++ b/docs/examples/opsman-config/_gcp1.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet gcp-configuration start yaml
+
+
---
opsman-configuration:
gcp:
@@ -34,4 +35,5 @@ opsman-configuration:
# banner-settings: ...
# syslog-settings: ...
# rbac-settings: ...
-# code_snippet gcp-configuration end
+
+
diff --git a/docs/examples/opsman-config/openstack.yml b/docs/examples/opsman-config/_openstack1.html.md.erb
similarity index 91%
rename from docs/examples/opsman-config/openstack.yml
rename to docs/examples/opsman-config/_openstack1.html.md.erb
index 78891044..bcb50472 100644
--- a/docs/examples/opsman-config/openstack.yml
+++ b/docs/examples/opsman-config/_openstack1.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet openstack-configuration start yaml
+
+
---
opsman-configuration:
openstack:
@@ -29,4 +30,5 @@ opsman-configuration:
# banner-settings: ...
# syslog-settings: ...
# rbac-settings: ...
-# code_snippet openstack-configuration end
\ No newline at end of file
+
+
\ No newline at end of file
diff --git a/docs/examples/opsman-config/settings.yml b/docs/examples/opsman-config/_settings.html.md.erb
similarity index 94%
rename from docs/examples/opsman-config/settings.yml
rename to docs/examples/opsman-config/_settings.html.md.erb
index acf8ea4f..aa492b10 100644
--- a/docs/examples/opsman-config/settings.yml
+++ b/docs/examples/opsman-config/_settings.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet opsman-settings start yaml
+
+
# These are OPTIONAL settings that can exist in your opsman.yml
# When upgrading an Ops Manager, these are configurations
# that can be updated on the Settings page in the Ops Manager UI.
@@ -40,4 +41,5 @@ rbac-settings: # if your RBAC is SAML, use these settings
opsman-configuration:
aws: # azure, gcp, openstack, vsphere
...
-# code_snippet opsman-settings end yaml
\ No newline at end of file
+
+
diff --git a/docs/examples/opsman-config/vsphere.yml b/docs/examples/opsman-config/_vsphere1.html.md.erb
similarity index 94%
rename from docs/examples/opsman-config/vsphere.yml
rename to docs/examples/opsman-config/_vsphere1.html.md.erb
index be54d3be..3311b3ee 100644
--- a/docs/examples/opsman-config/vsphere.yml
+++ b/docs/examples/opsman-config/_vsphere1.html.md.erb
@@ -1,4 +1,5 @@
-# code_snippet vsphere-configuration start yaml
+
+
---
opsman-configuration:
vsphere:
@@ -42,4 +43,5 @@ opsman-configuration:
# banner-settings: ...
# syslog-settings: ...
# rbac-settings: ...
-# code_snippet vsphere-configuration end
+
+
\ No newline at end of file
diff --git a/docs/examples/state/_aws.html.md.erb b/docs/examples/state/_aws.html.md.erb
new file mode 100644
index 00000000..1173f98d
--- /dev/null
+++ b/docs/examples/state/_aws.html.md.erb
@@ -0,0 +1,7 @@
+
+
+ iaas: aws
+ # Instance ID of the AWS VM
+ vm_id: i-12345678987654321
+
+
diff --git a/docs/examples/state/_azure.html.md.erb b/docs/examples/state/_azure.html.md.erb
new file mode 100644
index 00000000..2754805a
--- /dev/null
+++ b/docs/examples/state/_azure.html.md.erb
@@ -0,0 +1,7 @@
+
+
+ iaas: azure
+ # Computer Name of the Azure VM
+ vm_id: vm_name
+
+
diff --git a/docs/examples/state/_gcp.html.md.erb b/docs/examples/state/_gcp.html.md.erb
new file mode 100644
index 00000000..212bc9a0
--- /dev/null
+++ b/docs/examples/state/_gcp.html.md.erb
@@ -0,0 +1,7 @@
+
+
+ iaas: gcp
+ # Name of the VM in GCP
+ vm_id: vm_name
+
+
diff --git a/docs/examples/state/_openstack.html.md.erb b/docs/examples/state/_openstack.html.md.erb
new file mode 100644
index 00000000..3a7d6a46
--- /dev/null
+++ b/docs/examples/state/_openstack.html.md.erb
@@ -0,0 +1,7 @@
+
+
+ iaas: openstack
+ # Instance ID from the OpenStack Overview
+ vm_id: 12345678-9876-5432-1abc-defghijklmno
+
+
diff --git a/docs/examples/state/_vsphere.html.md.erb b/docs/examples/state/_vsphere.html.md.erb
new file mode 100644
index 00000000..a43ff02b
--- /dev/null
+++ b/docs/examples/state/_vsphere.html.md.erb
@@ -0,0 +1,7 @@
+
+
+ iaas: vsphere
+ # Path to the VM in vCenter
+ vm_id: /datacenter/vm/folder/vm_name
+
+
diff --git a/docs/examples/state/aws.yml b/docs/examples/state/aws.yml
deleted file mode 100644
index 229e2f07..00000000
--- a/docs/examples/state/aws.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-iaas: aws
-# Instance ID of the AWS VM
-vm_id: i-12345678987654321
diff --git a/docs/examples/state/azure.yml b/docs/examples/state/azure.yml
deleted file mode 100644
index 56508319..00000000
--- a/docs/examples/state/azure.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-iaas: azure
-# Computer Name of the Azure VM
-vm_id: vm_name
diff --git a/docs/examples/state/gcp.yml b/docs/examples/state/gcp.yml
deleted file mode 100644
index cc030a40..00000000
--- a/docs/examples/state/gcp.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-iaas: gcp
-# Name of the VM in GCP
-vm_id: vm_name
diff --git a/docs/examples/state/openstack.yml b/docs/examples/state/openstack.yml
deleted file mode 100644
index e373eb14..00000000
--- a/docs/examples/state/openstack.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-iaas: openstack
-# Instance ID from the OpenStack Overview
-vm_id: 12345678-9876-5432-1abc-defghijklmno
diff --git a/docs/examples/state/vsphere.yml b/docs/examples/state/vsphere.yml
deleted file mode 100644
index a6d445c7..00000000
--- a/docs/examples/state/vsphere.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-iaas: vsphere
-# Path to the VM in vCenter
-vm_id: /datacenter/vm/folder/vm_name
diff --git a/docs/getting-started.html.md.erb b/docs/getting-started.html.md.erb
new file mode 100644
index 00000000..76de87cb
--- /dev/null
+++ b/docs/getting-started.html.md.erb
@@ -0,0 +1,34 @@
+# Getting started
+
+If you are using Platform Automation Toolkit for the first time, it is useful to review the [Overview](./index.html) of Platform Automation Toolkit before diving into more technical content.
+
+## How-to guides
+
+For in-depth procedures for deploying a new Tanzu Operations Manager and
+taking over management of an existing Tanzu Operations Manager
+with Platform Automation Toolkit, see the following topics:
+
+- For information about deploying Concourse with CredHub and User Account and Authentication (UAA),
+ see [Install Concourse for Platform Automation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/concourse-for-tanzu/7-0/tanzu-concourse/index.html).
+- For information about deploying Platform Automation Toolkit
+ with a new Tanzu Operations Manager, see [Installing Tanzu Operations Manager](./how-to-guides/installing-opsman.html).
+- For information about deploying Platform Automation Toolkit
+ with an existing Tanzu Operations Manager, see
+ [Upgrading an existing Tanzu Operations Manager](./how-to-guides/upgrade-existing-opsman.html).
+
+## Reference pipelines
+
+To see an example of a finished pipeline,
+review the following reference pipeline:
+
+- A [multi-product pipeline](./pipelines/multiple-products.html)
+ with [Tanzu Platform for Cloud Foundry](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-platform-for-cloud-foundry/10-0/tpcf/concepts-overview.html) and [Healthwatch](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform-services/healthwatch-for-vmware-tanzu/2-3/healthwatch/index.html).
+
+## Other references
+
+To see a list of all of the tasks, their usage,
+their inputs and outputs, and their parameters,
+see the [Task Reference](./tasks.html).
+
+To learn more about the format of the files used with the tasks,
+see the [Task inputs and outputs reference](./inputs-outputs.html).
diff --git a/docs/getting-started.md b/docs/getting-started.md
deleted file mode 100644
index e757278f..00000000
--- a/docs/getting-started.md
+++ /dev/null
@@ -1,39 +0,0 @@
-If you are using Platform Automation Toolkit for the first time,
-you have a few options.
-
-Our [Overview][overview] of Platform Automation Toolkit describes it conceptually,
-and is useful to review prior to diving into more technical content.
-
-## How-to Guides
-
-We have in-depth procedures for deploying a new Ops Manager and
-taking over management of an existing Ops Manager
-with Platform Automation Toolkit:
-
-- For more information about deploying Concourse with Credhub and UAA,
- see [Install Concourse for Platform Automation][concourse-for-pa].
-- For more information about deploying Platform Automation Toolkit
- with a new Ops Manager, see [Installing Ops Manager][install-how-to].
-- For more information about deploying Platform Automation Toolkit
- with an existing Ops Manager, see
- [Upgrading an Existing Ops Manager][upgrade-how-to].
-
-## Reference Pipelines
-
-To see an example of a finished pipeline,
-see one of the following reference pipelines:
-
-- A [multi-product pipeline][reference-pipeline]
- with [Tanzu Application Service][tas] and [Healthwatch][healthwatch].
-
-## Other References
-
-To see a list of all of the tasks, their usage,
-their inputs and outputs, and their parameters,
-see the [Task Reference][task-reference].
-
-To learn more about the format of the files used with the tasks,
-see the [Task Inputs and Outputs Reference][inputs-outputs].
-
-{% include ".internal_link_url.md" %}
-{% include ".external_link_url.md" %}
diff --git a/docs/how-to-guides/.getting-started.md b/docs/how-to-guides/.getting-started.md
deleted file mode 100644
index 56dec718..00000000
--- a/docs/how-to-guides/.getting-started.md
+++ /dev/null
@@ -1,526 +0,0 @@
-## Prerequisites
-
-Over the course of this guide,
-we're going to use Platform Automation Toolkit
-to create a [pipeline][concourse-pipeline]
-using [Concourse][concourse].
-
-Before we get started, you'll need a few things ready to go:
-
-{% if upgradeHowTo %}
-1. A running Ops Manager VM that you would like to upgrade
-{% endif %}
-1. Credentials for an IaaS that Ops Manager is compatible with
- - It doesn't actually matter what IaaS you use for Ops Manager,
- as long as your Concourse can connect to it.
- Pipelines built with Platform Automation Toolkit can be platform-agnostic.
-1. A Concourse instance
- with access to a Credhub instance
- and to the Internet
-1. GitHub account
-1. Read/write credentials and bucket name for an S3 bucket
-1. An account on [VMware Tanzu Network][tanzu-network]
-1. A MacOS workstation
- - with Docker installed
- - a text editor you like
- - a terminal emulator you like
- - a browser that works with Concourse,
- like Firefox or Chrome
- - and `git`
-
-It will be very helpful to have a basic familiarity with the following. If you don't have basic familiarity with all these things,
-that's okay.
-We'll explain some basics,
-and link to resources to learn more:
-
-- the bash terminal
-- [git][git]
-- [YAML][yaml]
-- [Concourse][concourse]
-
-
-!!! info "A note on the prerequisites"
- While this guide uses Github to provide a git remote, - and an S3 bucket as a blobstore, - Platform Automation Toolkit supports arbitrary git providers - and S3-compatible blobstores. -
If you need to use an alternate one, - that's okay. -
We picked specific examples - so we could describe some steps in detail. - Some details may be different - if you follow along with different providers. - If you're comfortable navigating those differences on your own, - go for it! -
Check out our reference for [using an S3-specific blobstore][setup-s3-and-resources] -
Similarly, in this guide, we assume the MacOS operating system. - This should all work fine on Linux, too, - but there might be differences in the paths you'll need to figure out. - -## Creating a Concourse Pipeline - -Platform Automation Toolkit's tasks and image are meant to be used in a Concourse pipeline. -So, let's make one. - -Using your bash command-line client, -create a directory to keep your pipeline files in, and `cd` into it. - -```bash -mkdir your-repo-name -cd !$ -``` - -This repo name should relate to your situation -and be specific enough to be navigable from your local workstation. - -!!! tip ""`!$`"" - `!$` is a bash shortcut. - Pronounced "bang, dollar-sign," - it means "use the last argument from the most recent command." - In this case, that's the directory we just created! - This is not a Platform Automation Toolkit thing, - this is just a bash tip dearly beloved - of at least one Platform Automator. - -{% if upgradeHowTo %} - -Before we get started with the pipeline itself, -we'll gather some variables in a file -we can use throughout our pipeline. - -Open your text editor and create `vars.yml`. -Here's what it should look like to start, we can add things to this as we go: - -```yaml -platform-automation-bucket: your-bucket-name -credhub-server: https://your-credhub.example.com -opsman-url: https://pcf.foundation.example.com -``` - -!!! info "Using a DNS" - This example assumes that you're using DNS and hostnames. - You can use IP addresses for all these resources instead, - but you still need to provide the information as a URL, - for example: `https://120.121.123.124` - -{% endif %} - -Now, create a file called `pipeline.yml`. - -!!! info "Naming" - We'll use `pipeline.yml` in our examples throughout this guide. - However, you may create multiple pipelines over time. - If there's a more sensible name for the pipeline you're working on, - feel free to use that instead. - -Write this at the top, and save the file. This is [YAML][yaml] for "the start of the document". It's optional, but traditional: - -```yaml - ---- -``` - -Now you have a pipeline file! Nominally! -Well, look. -It's valid YAML, at least. - -### Getting `fly` - -Let's try to set it as a pipeline with [`fly`][concourse-fly], -the Concourse command-line Interface (CLI). - -First, check if we've got `fly` installed at all: - -```bash -fly -v -``` - -If it gives you back a version number, great! -Skip ahead to [Setting The Pipeline](#setting-the-pipeline) - -If it says something like `-bash: fly: command not found`, -we have a little work to do: we've got to get `fly`. - -Navigate to the address for your Concourse instance in a web browser. -At this point, you don't even need to be signed in! -If there are no public pipelines, you should see something like this: - -![Get Fly][fly-download-image] - -If there _are_ public pipelines, -or if you're signed in and there are pipelines you can see, -you'll see something similar in the lower-right hand corner. - -Click the icon for your OS and save the file, -`mv` the resulting file to somewhere in your `$PATH`, -and use `chmod` to make it executable: - -!!! info "A note on command-line examples" - Some of these, you can copy-paste directly into your terminal. - Some of them won't work that way, - or even if they did, would require you to edit them to replace our example values - with your actual values. - We recommend you type all of the bash examples in by hand, - substituting values, if necessary, as you go. - Don't forget that you can often hit the `tab` key - to auto-complete the name of files that already exist; - it makes all that typing just a little easier, - and serves as a sort of command-line autocorrect. - -```bash -mv ~/Downloads/fly /usr/local/bin/fly -chmod +x !$ -``` - -Congrats! You got `fly`. - -!!! info "Okay but what did I just do?" - FAIR QUESTION. You downloaded the `fly` binary, - moved it into bash's PATH, - which is where bash looks for things to execute - when you type a command, - and then added permissions that allow it to be e`x`ecuted. - Now, the CLI is installed - - and we won't have to do all that again, - because `fly` has the ability to update itself, - which we'll get into later. - -### Setting The Pipeline - -Okay _now_ let's try to set our pipeline with `fly`, the Concourse CLI. - -`fly` keeps a list of Concourses it knows how to talk to. -Let's see if the Concourse we want is already on the list: - -```bash -fly targets -``` - -If you see the address of the Concourse you want to use in the list, -note down its name, and use it in the login command: - -```bash -fly -t control-plane login -``` - -!!! info "Control-plane?" - We're going to use the name `control-plane` - for our Concourse in this guide. - It's not a special name, - it just happens to be the name - of the Concourse we want to use in our target list. - -If you don't see the Concourse you need, you can add it with the `-c` (`--concourse-url`)flag: - -```bash -fly -t control-plane login -c https://your-concourse.example.com -``` - -You should see a login link you can click on -to complete login from your browser. - -!!! tip "Stay on target" -
The `-t` flag sets the name when used with `login` and `-c`. - In the future, you can leave out the `-c` argument. -
If you ever want to know what a short flag stands for, - you can run the command with `-h` (`--help`) at the end. - -Pipeline-setting time! -We'll use the name "foundation" for this pipeline, -but if your foundation has an actual name, use that instead. - -```bash -fly -t control-plane set-pipeline -p foundation -c pipeline.yml -``` - -It should say `no changes to apply`, -which is fair, since we gave it an empty YAML doc. - -!!! info "Version discrepancy" - If `fly` says something about a "version discrepancy," - "significant" or otherwise, just do as it says: - run `fly sync` and try again. - `fly sync` automatically updates the CLI - with the version that matches the Concourse you're targeting. - Useful! - -### Your First Job - -Let's see Concourse actually _do_ something, yeah? - -Add this to your `pipeline.yml`, starting on the line after the `---`: - -```yaml -wait: no nevermind let's get version control first -``` - -Good point. Don't actually add that to your pipeline config yet. -Or if you have, delete it, so your whole pipeline looks like this again: - -```yaml - ---- -``` - -Reverting edits to our pipeline is something we'll probably want to do again. -This is one of many reasons we want to keep our pipeline under version control. - -So let's make this directory a git repo! - -#### But First, `git init` - -!!! tip "Git Repository Layout" -
The following describes a step-by-step approach for how to get set up with git. -
For an example of the repository file structure - for single and multiple foundation systems, - please reference [Git Repository Layout][git-repo-layout]. - -`git` should come back with information about the commit you just created: - -```bash -git init -git commit --allow-empty -m "Empty initial commit" -``` - -If it gives you a config error instead, -you might need to configure `git` a bit. -Here's a [good guide][git-first-time-setup] -to initial setup. -Get that done, and try again. - -Now we can add our `pipeline.yml`, -so in the future it's easy to get back to that soothing `---` state. - -```bash -git add pipeline.yml {% if upgradeHowTo %}vars.yml{% endif %} -git commit -m "Add pipeline{% if upgradeHowTo %} and starter vars{% endif %}" -``` - -Let's just make sure we're all tidy: - -```bash -git status -``` - -`git` should come back with `nothing to commit, working tree clean`. - -Great. Now we can safely make changes. - -!!! tip "Git commits" -
`git` commits are the basic unit of code history. -
Making frequent, small, commits with good commit messages - makes it _much easier_ to figure out why things are the way they are, - and to return to the way things were in simpler, better times. - Writing short commit messages that capture the _intent_ of the change - (in an imperative style) can be tough, - but it really does make the pipeline's history much more legible, - both to future-you, - and to current-and-future teammates and collaborators. - -#### The Test Task - -Platform Automation Toolkit comes with a [`test`][test] task -meant to validate that it's been installed correctly. -Let's use it to get setup. - -Add this to your `pipeline.yml`, starting on the line after the `---`: - -```yaml -jobs: -- name: test - plan: - - task: test - image: platform-automation-image - file: platform-automation-tasks/tasks/test.yml -``` - -If we try to set this now, Concourse will take it: - -```bash -fly -t control-plane set-pipeline -p foundation -c pipeline.yml -``` - -Now we should be able to see our pipeline -in the Concourse UI. -It'll be paused, so click the "play" button to unpause it. -Then, click in to the gray box for our `test` job, -and hit the "plus" button to schedule a build. - -It should error immediately, with `unknown artifact source: platform-automation-tasks`. -We didn't give it a source for our task file. - -We've got a bit of pipeline code that Concourse accepts. -Before we start doing the next part, -this would be a good moment to make a commit: - -```bash -git add pipeline.yml -git commit -m "Add (nonfunctional) test task" -``` - -With that done, -we can try to get the inputs we need -by adding `get` steps to the plan -before the task, like so: - -```yaml hl_lines="4-13" -jobs: -- name: test - plan: - - get: platform-automation-image - resource: platform-automation - params: - globs: ["*image*.tgz"] - unpack: true - - get: platform-automation-tasks - resource: platform-automation - params: - globs: ["*tasks*.zip"] - unpack: true - - task: test - image: platform-automation-image - file: platform-automation-tasks/tasks/test.yml -``` - -!!! note "When using vSphere" - There is a smaller vSphere container image available. - To use it instead of the general purpose image, - you can use this glob to get the image: - - ```yaml - - get: platform-automation-image - resource: platform-automation - params: - globs: ["vsphere-platform-automation-image*.tar.gz"] - unpack: true - ``` - -If we try to `fly set` this, -`fly` will complain about invalid resources. - -To actually make the `image` and `file` we want to use available, -we'll need some Resources. - -#### Adding Resources - -Resources are Concourse's main approach to managing artifacts. -We need an image, and the tasks directory - -so we'll tell Concourse how to get these things by declaring Resources for them. - -In this case, we'll be downloading the image and the tasks directory from Tanzu Network. -Before we can declare the resources themselves, -we have to teach Concourse to talk to Tanzu Network. -(Many resource types are built in, but this one isn't.) - -Add the following to your pipeline file. -We'll put it above the `jobs` entry. - -```yaml -resource_types: -- name: pivnet - type: docker-image - source: - repository: pivotalcf/pivnet-resource - tag: latest-final -resources: -- name: platform-automation - type: pivnet - source: - product_slug: platform-automation - api_token: ((pivnet-refresh-token)) -``` - -The API token is a credential, -which we'll pass via the command-line when setting the pipeline, -so we don't accidentally check it in. - -Grab a refresh token from your Tanzu Network profile -(when logged in, click your username, then `Edit Profile`) -and clicking "Request New Refresh Token." -Then use that token in the following command: - -!!! tip "Keep it secret, keep it safe" - Bash commands that start with a space character - are not saved in your history. - This can be very useful for cases like this, - where you want to pass a secret, - but don't want it saved. - Commands in this guide that contain a secret - start with a space, which can be easy to miss. - -```bash -# note the space before the command - fly -t control-plane set-pipeline \ - -p foundation \ - -c pipeline.yml \ - -v pivnet-refresh-token=your-api-token -``` - -!!! warning Getting Your Tanzu Network Token Expires It - When you get your Tanzu Network token as described above, - any previous Tanzu Network tokens you may have gotten will stop working. - If you're using your Tanzu Network refresh token anywhere, - retrieve it from your existing secret storage rather than getting a new one, - or you'll end up needing to update it everywhere it's used. - -Go back to the Concourse UI and trigger another build. -This time, it should pass. - -Commit time! - -```bash -git add pipeline.yml -git commit -m "Add resources needed for test task" -``` - -We'd rather not pass our Tanzu Network token -every time we need to set the pipeline. -Fortunately, Concourse can integrate -with secret storage services. - -Let's put our API token in Credhub so Concourse can get it. - -First we'll need to login: - -!!! info "Backslashes in bash examples" - The following example has been broken across multiple lines - by using backslash characters (`\`) to escape the newlines. - We'll be doing this a lot to keep the examples readable. - When you're typing these out, - you can skip that and just put it all on one line. - -Again, note the space at the start - -{% include ".logging-into-credhub.md" %} - -Then, we can set the credential name -to the path [where Concourse will look for it][concourse-credhub-lookup-rules]: - -```bash -# note the starting space - credhub set \ - --name /concourse/your-team-name/pivnet-refresh-token \ - --type value \ - --value your-credhub-refresh-token -``` - -Now, let's set that pipeline again, -without passing a secret this time. - -```bash -fly -t control-plane set-pipeline \ - -p foundation \ - -c pipeline.yml -``` - -This should succeed, -and the diff Concourse shows you should replace the literal credential -with `((pivnet-refresh-token))`. - -Visit the UI again and re-run the test job; -this should also succeed. - -{% with path="../" %} - {% include ".internal_link_url.md" %} -{% endwith %} -{% include ".external_link_url.md" %} diff --git a/docs/how-to-guides/.logging-into-credhub.md b/docs/how-to-guides/.logging-into-credhub.md deleted file mode 100644 index c23515b3..00000000 --- a/docs/how-to-guides/.logging-into-credhub.md +++ /dev/null @@ -1,22 +0,0 @@ -```bash -# note the starting space - credhub login --server example.com \ - --client-name your-client-id \ - --client-secret your-client-secret -``` - -!!! info "Logging in to credhub" - Depending on your credential type, - you may need to pass `client-id` and `client-secret`, - as we do above, - or `username` and `password`. - We use the `client` approach because that's the credential type - that automation should usually be working with. - Nominally, a username represents a person, - and a client represents a system; - this isn't always exactly how things are in practice. - Use whichever type of credential you have in your case. - Note that if you exclude either set of flags, - Credhub will interactively prompt for `username` and `password`, - and hide the characters of your password when you type them. - This method of entry can be better in some situations. diff --git a/docs/how-to-guides/.opsman-config-tabs.md b/docs/how-to-guides/.opsman-config-tabs.md deleted file mode 100644 index e403d91f..00000000 --- a/docs/how-to-guides/.opsman-config-tabs.md +++ /dev/null @@ -1,40 +0,0 @@ -=== "AWS" - ```yaml - --- - pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "ops-manager-aws*.yml" - pivnet-product-slug: ops-manager - product-version-regex: ^2\.5\.\d+$ - ``` -=== "Azure" - ```yaml - --- - pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "ops-manager-azure*.yml" - pivnet-product-slug: ops-manager - product-version-regex: ^2\.5\.\d+$ - ``` -=== "GCP" - ```yaml - --- - pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "ops-manager-gcp*.yml" - pivnet-product-slug: ops-manager - product-version-regex: ^2\.5\.\d+$ - ``` -=== "OpenStack" - ```yaml - --- - pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "ops-manager-openstack*.raw" - pivnet-product-slug: ops-manager - product-version-regex: ^2\.5\.\d+$ - ``` -=== "vSphere" - ```yaml - --- - pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "ops-manager-vsphere*.ova" - pivnet-product-slug: ops-manager - product-version-regex: ^2\.5\.\d+$ - ``` \ No newline at end of file diff --git a/docs/how-to-guides/.download-tas-tabs.md b/docs/how-to-guides/_download-tas-tabs.html.md.erb similarity index 81% rename from docs/how-to-guides/.download-tas-tabs.md rename to docs/how-to-guides/_download-tas-tabs.html.md.erb index 9f53ebd7..5359edef 100644 --- a/docs/how-to-guides/.download-tas-tabs.md +++ b/docs/how-to-guides/_download-tas-tabs.html.md.erb @@ -1,49 +1,54 @@ -=== "AWS" - ```yaml +
AWS
+ +```yaml --- pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TAS + pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TPCF pivnet-product-slug: elastic-runtime product-version-regex: ^2\.9\..*$ stemcell-iaas: aws - ``` +``` + +Azure
-=== "Azure" - ```yaml +```yaml --- pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TAS + pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TPCF pivnet-product-slug: elastic-runtime product-version-regex: ^2\.9\..*$ stemcell-iaas: azure - ``` +``` + +GCP
-=== "GCP" - ```yaml +```yaml --- pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TAS + pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TPCF pivnet-product-slug: elastic-runtime product-version-regex: ^2\.9\..*$ stemcell-iaas: google - ``` +``` -=== "OpenStack" - ```yaml +OpepnStack
+ +```yaml --- pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TAS + pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TPCF pivnet-product-slug: elastic-runtime product-version-regex: ^2\.9\..*$ stemcell-iaas: openstack - ``` +``` + +vSphere
-=== "vSphere" - ```yaml +```yaml --- pivnet-api-token: ((pivnet_token)) - pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TAS + pivnet-file-glob: "*srt*.pivotal" # this guide installs Small Footprint TPCF pivnet-product-slug: elastic-runtime product-version-regex: ^2\.9\..*$ stemcell-iaas: vsphere - ``` +``` diff --git a/docs/how-to-guides/_getting-started.html.md.erb b/docs/how-to-guides/_getting-started.html.md.erb new file mode 100644 index 00000000..62699df3 --- /dev/null +++ b/docs/how-to-guides/_getting-started.html.md.erb @@ -0,0 +1,481 @@ +## Prerequisites + +Over the course of this guide, +you will use Platform Automation Toolkit +to create a [pipeline](https://concourse-ci.org/pipelines.html) +using [Concourse](https://concourse-ci.org/). + +You need: + +1. For upgrade only: A running Tanzu Operations Manager VM that you would like to upgrade +2. Credentials for an IaaS that Tanzu Operations Manager is compatible with + - It doesn't matter what IaaS you use for Tanzu Operations Manager, + as long as your Concourse can connect to it. + Pipelines built with Platform Automation Toolkit can be platform-agnostic. +3. A Concourse instance + with access to a CredHub instance + and to the Internet +4. A GitHub account +5. Read/write credentials and bucket name for an S3 bucket +6. An account on the [Broadcom Support portal](https://support.broadcom.com/group/ecx/downloads) +7. A MacOS workstation with: + - a text editor of your choice + - a terminal emulator of your choice + - a browser that works with Concourse, like Firefox or Chrome + - `git`installed + - Docker installed + +It will be very helpful to have a basic familiarity with the following. If you don't have basic familiarity with all these things, +you will fine some basics explained here, along with links to resources to learn more: + +- the bash terminal +- [git](https://git-scm.com/) +- [YAML](https://learnxinyminutes.com/docs/yaml/) +- [Concourse](https://concourse-ci.org/) + +
+While this guide uses GitHub to provide a git remote,
+and an S3 bucket as a blobstore,
+Platform Automation Toolkit supports arbitrary git providers
+and S3-compatible blobstores.
+
+Specific examples are described in some detail, but
+if you follow along with different providers
+some details may be different.
+Also see Setting up S3 for file storage.
+
+Similarly, in this guide, MacOS is assumed, but
+Linux should work well, too.
+Keep in mind that there might be differences in the paths that
+you will need to figure out.
+!$ is a bash shortcut.
+Pronounced "bang, dollar-sign,"
+it means "use the last argument from the most recent command."
+In this case, that's the directory you just created.
+This example assumes that that you are using DNS and host names.
+You can use IP addresses for all these resources instead,
+but you still need to provide the information as a URL,
+for example: https://120.121.123.124.
+About command-line examples: +In some cases, you can copy-paste the examples directly into your terminal. +Some of them won't work that way, +or even if they did, would require you to edit them to replace our example values +with your actual values. +Best practice is to type all of the bash examples by hand, +substituting values, if necessary, as you go. +Don't forget that you can often hit the tab key +to auto-complete the names of files that already exist; +it makes all that typing just a little easier, +and serves as a sort of command-line autocorrect.
+ +Type the following into your terminal to get `fly`. + +```bash +mv ~/Downloads/fly /usr/local/bin/fly +chmod +x !$ +``` + +This means that you downloaded the `fly` binary, +and moved it into the bash PATH, +which is where bash looks for things to execute +when you type a command. +Then you added permissions that allow it to be executed (`+x`). +Now, the CLI is installed, you won't have to do it again, +because `fly` has the ability to update itself, +(which is be described in more detail is a later section). + +### Setting the pipeline + +Now set your pipeline with `fly`, the Concourse CLI. + +`fly` keeps a list of Concourses it knows how to talk to. +To find out if the Concourse you need is already on the list, type: + +```bash +fly targets +``` + +If you see the address of the Concourse you want to use in the list, +note its name, and use it in the login command. The examples in this book use the Concourse +name `control-plane`. + +```bash +fly -t control-plane login +``` + +If you don't see the Concourse you need, you can add it with the `-c` (`--concourse-url`)flag: + +```bash +fly -t control-plane login -c https://your-concourse.example.com +``` + +You should see a login link you can click +to complete login from your browser. + +
+The -t flag sets the name when used with login and -c.
+In the future, you can leave out the -c argument.
+
+If you ever want to know what a short flag stands for,
+you can run the command with -h (--help) at the end.
+If fly says something about a "version discrepancy,"
+"significant" or otherwise, run fly sync and try again.
+fly sync automatically updates the CLI
+with the version that matches the Concourse you're targeting.
+git commits are the basic unit of code history.
+Making frequent, small, commits with good commit messages
+makes it much easier to figure out why things are the way they are,
+and to return to the way things were in simpler, better times.
+Writing short commit messages that capture the intent of the change
+really does make the pipeline history much more legible,
+both to future-you,
+and to current and future teammates and collaborators.
+ There is a smaller vSphere container image available.
+ To use it instead of the general purpose image,
+ you can use this glob to get the image:
+
+
+ - get: platform-automation-image
+ resource: platform-automation
+ params:
+ globs: ["vsphere-platform-automation-image*.tar.gz"]
+ unpack: true
+
+
+ Bash commands that start with a space character + are not saved in your history. + This can be very useful for cases like this, + where you want to pass a secret, + but you don't want it saved. + Commands in this guide that contain a secret + start with a space, which can be easy to miss.
+ +2. Get a refresh token from your Broadcom Support profile +(when logged in, click your user name, then **Edit Profile**) +and click **Request New Refresh Token**.) + Then use that token in the following command: + + ```bash + # note the space before the command + fly -t control-plane set-pipeline \ + -p foundation \ + -c pipeline.yml \ + -v pivnet-refresh-token=your-api-token + ``` + ++ When you get your Broadcom Support token as described above, + any previous Broadcom Support tokens you have stop working. + If you're using your Broadcom Support refresh token anywhere, + retrieve it from your existing secret storage rather than getting a new one, + or you'll end up needing to update it everywhere it's used.
+ +1. Go back to the Concourse UI and trigger another build. This time, it should pass. + +2. Now it's time to commit. + + ```bash + git add pipeline.yml + git commit -m "Add resources needed for test task" + ``` + +3. It's better not to pass the Broadcom Support token +every time you need to set the pipeline. +Fortunately, Concourse can integrate +with secret storage services, like CredHub. In this step, put the API token in CredHub so Concourse can get it. + +
+ Backslashes in bash examples:
+ The following example has been broken across multiple lines
+ by using backslash characters (\) to escape the newlines.
+ The backslash is used in here to keep the examples readable.
+ When you're typing these out,
+ you can skip the backslashes and put it all on one line.
+ Depending on your credential type,
+ you may need to pass client-id and client-secret,
+ as we do above, or username and password.
+ We use the client approach because that's the credential type
+ that automation should usually be working with.
+ Nominally, a username represents a person,
+ and a client represents a system;
+ this isn't always exactly how things are in practice.
+ Use whichever type of credential you have in your case.
+ Note that if you exclude either set of flags,
+ CredHub will interactively prompt for username and password,
+ and hide the characters of your password when you type them.
+ This method of entry can be better in some situations.
AWS
+ +```yaml +--- +pivnet-api-token: ((pivnet_token)) +pivnet-file-glob: "ops-manager-aws*.yml" +pivnet-product-slug: ops-manager +product-version-regex: ^2\.5\.\d+$ +``` +Azure
+ +```yaml +--- +pivnet-api-token: ((pivnet_token)) +pivnet-file-glob: "ops-manager-azure*.yml" +pivnet-product-slug: ops-manager +product-version-regex: ^2\.5\.\d+$ +``` +GCP
+ +```yaml +--- +pivnet-api-token: ((pivnet_token)) +pivnet-file-glob: "ops-manager-gcp*.yml" +pivnet-product-slug: ops-manager +product-version-regex: ^2\.5\.\d+$ +``` +OpenStack
+ +```yaml +--- +pivnet-api-token: ((pivnet_token)) +pivnet-file-glob: "ops-manager-openstack*.raw" +pivnet-product-slug: ops-manager +product-version-regex: ^2\.5\.\d+$ +``` +vSphere
+ +```yaml +--- +pivnet-api-token: ((pivnet_token)) +pivnet-file-glob: "ops-manager-vsphere*.ova" +pivnet-product-slug: ops-manager +product-version-regex: ^2\.5\.\d+$ +``` + diff --git a/docs/how-to-guides/.paths-and-pipeline-names.md b/docs/how-to-guides/_paths-and-pipeline-names.html.md.erb similarity index 52% rename from docs/how-to-guides/.paths-and-pipeline-names.md rename to docs/how-to-guides/_paths-and-pipeline-names.html.md.erb index 97b0acdd..045d1487 100644 --- a/docs/how-to-guides/.paths-and-pipeline-names.md +++ b/docs/how-to-guides/_paths-and-pipeline-names.html.md.erb @@ -1,15 +1,13 @@ -!!! info "Credhub paths and pipeline names" - - Notice that we've added an element to the cred paths; - now we're using the foundation name. - - If you look at [Concourse's lookup rules,][concourse-credhub-lookup-rules] +
+ Notice the additional element to the cred paths;
+ the foundation name.
+
+ If you look at Concourse lookup rules,
you'll see that it searches the pipeline-specific path
before the team path.
Since our pipeline is named for the foundation it's used to manage,
we can use this to scope access to our foundation-specific information
to just this pipeline.
-
+
By contrast, the Tanzu Network token may be valuable across several pipelines
- (and associated foundations),
- so we scoped that to our team.
\ No newline at end of file
+ (and associated foundations), so we scoped that to our team.
+ Testing your pipeline: + We generally want to try things out right away to see if they're working right. + However, in this case, if you have a very slow internet connection and/or multiple Concourse workers, + you might want to hold off until we've got the job doing more, + so that if it works, you don't have to wait for the download again.
+ +### Upload and stage + +1. Now that you have a product downloaded and (potentially) cached on a Concourse worker, +upload and stage the new product to Tanzu Operations Manager. + + ```yaml hl_lines="32-45" + jobs: + - name: download-upload-and-stage-tas + serial: true + plan: + - aggregate: + - get: platform-automation-image + params: + globs: ["*image*.tgz"] + unpack: true + - get: platform-automation-tasks + params: + globs: ["*tasks*.zip"] + unpack: true + - get: config + - task: prepare-tasks-with-secrets + image: platform-automation-image + file: platform-automation-tasks/tasks/prepare-tasks-with-secrets.yml + input_mapping: + tasks: platform-automation-tasks + output_mapping: + tasks: platform-automation-tasks + params: + CONFIG_PATHS: config + - task: download-tas + image: platform-automation-image + file: platform-automation-tasks/tasks/download-product.yml + input_mapping: + config: config + params: + CONFIG_FILE: download-tas.yml + output_mapping: + downloaded-product: tas-product + downloaded-stemcell: tas-stemcell + - task: upload-tas-stemcell + image: platform-automation-image + file: platform-automation-tasks/tasks/upload-stemcell.yml + input_mapping: + env: config + stemcell: tas-stemcell + params: + ENV_FILE: env.yml + - task: upload-and-stage-tas + image: platform-automation-image + file: platform-automation-tasks/tasks/upload-and-stage-product.yml + input_mapping: + product: tas-product + env: config + ``` + +1. Re-set the pipeline. + + ```bash + fly -t control-plane set-pipeline -p foundation -c pipeline.yml + ``` + +1. When this finishes successfully, make a commit and push the changes. + + ```bash + git add pipeline.yml + git commit -m 'upload tas and stemcell to Ops Manager' + git push + ``` + +## Product configuration + +Before automating the configuration and installation of the product, +add a config file. +The simplest way to do this is to choose your config options in the Tanzu Operations Manager UI, +and then pull its resulting configuration. + ++Advanced Tile Config Option: +For an alternative that generates the configuration +from the product file, using ops files to select options, +see Config template. +
+ +### Pulling Configuration from Tanzu Operations Manager + +Configure the product _manually_ according to the product's installation instructions. +Use the installation instructions in the [VMware Tanzu Platform for Cloud Foundry documentation](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-platform-for-cloud-foundry/10-0/tpcf/toc-installing-index.html). + +After the product is fully configured, apply the changes (**Apply Changes**) in the Tanzu Operations Manager UI, +and then continue this guide. + +
+If you do not click Apply Changes,
+Tanzu Operations Manager cannot generate credentials.
+You can still go through this process without an initial applying changes,
+but you will be unable to use om staged-config with --include-credentials,
+and may have an incomplete configuration at the end of this process.
+ Remove credentials from disk:
+ Once you have validated that the certificates are set correctly in CredHub,
+ remember to delete poe-cert.txt and poe-private-key.txt from your working directory.
+ This will prevent a potential security leak
+ or an accidental commit of those credentials.
+ Adding multiple products:
+ When adding multiple products, you can add the configure jobs as passed constraints
+ to the apply-changes job so that they all are applied at once.
+ Tanzu Operations Manager will handle any inter-product dependency ordering.
+ This will speed up your apply changes
+ when compared with running apply changes for each product separately.
+
+ Example:
+ passed: [configure-tas, configure-tas-windows, configure-healthwatch]
+
+When using the Tanzu Operations Manager docs and UI, +be aware that the field names in the UI do not necessarily map directly to property names.
+ +#### Optional features + +The above process will get you a default installation, +with no optional features or variables, +that is entirely deployed in a single Availability Zone (AZ). + +To provide non-required variables, +use multiple AZs, +or make non-default selections for some options, +use some of the ops files in one of the following four directories: + +| features | +Allow the enabling of selectors for a product; for example, enabling/disabling of an s3 bucket | +
| network | +Contains options for enabling 2-3 availability zones for network configuration | +
| optional | +Contains optional properties without defaults. For optional values that can be provided more than once, there's an ops file for each param count. | +
| resource | +Contains configuration that can be applied to resource configuration; for example, BOSH VM extensions | +
| features | -allow the enabling of selectors for a product. For example, enabling/disabling of an s3 bucket | -
| network | -contains options for enabling 2-3 availability zones for network configuration | -
| optional | -contains optional properties without defaults. For optional values that can be provided more than once, there's an ops file for each param count | -
| resource | -contains configuration that can be applied to resource configuration. For example, BOSH VM extensions | -
| 1 | +If custom_only is true,
+ the VM types specified in your configuration will replace the entire list of available VM types in the Tanzu Operations Manager. |
+
| 2 | +If the property is set to false or is omitted, configure_director will append the listed VM types to the list of default VM types for your IaaS. |
+
| 3 | +If a specified VM type is named the same as a predefined VM type, it will overwrite the predefined type. | +
| 4 | +If multiple specified VM types have the same name, the one specified last will be created. | +
| 5 | +Existing custom VM types do not persist across configure-director calls, and it should be expected that the entire list of custom VM types is specified in the director configuration. | +
+There are many alternatives to GitHub including +GitLab, Google Cloud Source Repositories, and so on. +Any remote Git client will work with Platform Automation Toolkit and Concourse. +See the Concourse Git resource +documentation for details.
+ +To learn more about Git and GitHub, +read this short [git handbook](https://docs.github.com/en/get-started/using-git/about-git). + +## Creating a Git repository + +To create a new, local Git repo: + +```bash +# start a new repository +git init my-platform-automation + +# navigate to the new directory it creates +cd my-platform-automation + +# create a new directory for your config +mkdir config + +# create remaining directories +mkdir env state vars + +# create config files for director and opsman +touch config/director.yml +touch config/opsman.yml + +# create env file +touch env/env.yml + +# create state file +touch state/state.yml + +# Optional: +# create vars files for parameters corresponding to configs +touch vars/director-vars.yml +touch vars/opsman-vars.yml + +# commit the file to the repository +git commit -m "add initial files" +``` + +## Creating a GitHub Repository + +Go to GitHub and create a new remote repository. + +1. Under your profile, select **Repositories**. +1. Select **New**. +1. Name your new repository and follow the prompts. +1. When prompted, do not add any default files. +1. Copy the URL of your new GitHub repository. +1. Set the local Git repo's remote to the new GitHub repo: + + ```bash + # enter the path for the new GitHub repo + git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git + + # push your changes to the default branch + git push --set-upstream origin main + ``` + +You should now see your GitHub repo populated +with the directories and empty files. + ++A GitHub repository may be referenced +as a remote repo by HTTPS or by SSH. +In general, SSH keys are more secure. +The Concourse Git resource +supports using SSH keys to pull from a repository. +For more information on using SSH keys with GitHub, +see the SSH documentation.
+ +## Recommended file structure + +You now have both a local Git repo and a remote on GitHub, +including the recommended structure +for a Platform Automation Toolkit configuration repo: + +```tree +├── my-platform-automation +│  ├── config +│  ├── env +│  ├── state +│  └── vars +``` + +| Folder name | +Contents | + +
|---|---|
| config | +
+ Holds config files for the products installed on your foundation.
+ If using CredHub and/or vars files,
+ these config files should contain your ((parametrized)) values.
+ |
+
| env | +
+ Holds env.yml,
+ the environment file used by tasks that interact with Tanzu Operations Manager.
+ |
+
| vars | +
+ Holds product-specific vars files.
+ The fields in these files are used to fill in
+ ((parameters)) during interpolation steps.
+ |
+
| state | +
+ Holds state.yml,
+ which contains the VM ID for the Tanzu Operations Manager VM.
+ |
+
+Never commit secrets to Git.
+It is a best practice not to commit secrets,
+including passwords, keys, and sensitive information,
+to Git or GitHub. Instead, use ((parameters)).
+For more information about a recommended way to do this
+using CredHub or vars files
+see Using a secrets store to store credentials.
| config | -
- Holds config files for the products installed on your foundation.
- If using Credhub and/or vars files,
- these config files should have your ((parametrized)) values present in them
- |
-
| env | -
- Holds env.yml,
- the environment file used by tasks that interact with Ops Manager.
- |
-
| vars | -
- Holds product-specific vars files.
- The fields in these files get used to fill in
- ((parameters)) during interpolation steps.
- |
-
| state | -
- Holds state.yml,
- which contains the VM ID for the Ops Manager VM.
- |
-
+If you need to install an earlier version of Tanzu Operations Manager, +select your desired version from the version selector at the top of the page.
+ +## Creating the Tanzu Operations Manager VM + +1. Now that you have a Tanzu Operations Manager image and the resources required to deploy a VM, +you can add the new task to the `install-opsman` job. + + ```yaml hl_lines="29-31" + jobs: + - name: install-ops-manager + serial: true + plan: + - get: platform-automation-image + resource: platform-automation + params: + globs: ["*image*.tgz"] + unpack: true + - get: platform-automation-tasks + resource: platform-automation + params: + globs: ["*tasks*.zip"] + unpack: true + - get: config + - task: prepare-tasks-with-secrets + file: platform-automation-tasks/tasks/prepare-tasks-with-secrets.yml + input_mapping: + tasks: platform-automation-tasks + output_mapping: + tasks: platform-automation-tasks + params: + CONFIG_PATHS: config + - task: download-product + image: platform-automation-image + file: platform-automation-tasks/tasks/download-product.yml + params: + CONFIG_FILE: download-ops-manager.yml + - task: create-vm + image: platform-automation-image + file: platform-automation-tasks/tasks/create-vm.yml + ``` + +1. If you try to `fly` this up to Concourse, it will again complain +about resources that don't exist, so it's time to make them. +Two new inputs need to be added for `create-vm`: + + * `config` + * `state` + + The optional inputs are vars used with the config, so you will add those when you do the `config`. + + 1. For the config file, write a Tanzu Operations Manager VM Configuration file to `opsman.yml`. + + The properties available vary by IaaS, for example: + + * IaaS credentials + * networking setup (IP address, subnet, security group, etc) + * SSH key + * datacenter/availability zone/region + + Continue with the next section for completing the `opsman.yml` file. + +### Terraform outputs + +If you used the `paving` repository from the [Creating resources for your Tanzu Operations Manager](./installing-opsman.html#creating-resources-for-your-tanzu-operations-manager) section, +the following steps will result in a filled out `opsman.yml`. + +Tanzu Operations Manager must be deployed with the IaaS-specific configuration. + +1. Copy and paste the relevant YAML below for your IaaS, + and save the file as `opsman.yml`. + + **AWS** + + ```yaml + --8<-- "external/paving/ci/configuration/aws/ops-manager.yml" + ``` + + **Azure** + + ```yaml + --8<-- "external/paving/ci/configuration/azure/ops-manager.yml" + ``` + + **GCP** + + ```yaml + --8<-- "external/paving/ci/configuration/gcp/ops-manager.yml" + ``` + + **vSphere+NSXT** + + ```yaml + --8<-- "external/paving/ci/configuration/nsxt/ops-manager.yml" + ``` + + Where: + + * The `((parameters))` in these examples map to outputs from the `terraform-outputs.yml`, + which can be provided via vars file for YAML interpolation in a subsequent step. + ++For a supported IaaS not listed above, +see the Operations Manager config. +
+ +### Manual configuration + +If you created your infrastructure manually +or would like additional configuration options, +these are the acceptable keys for the `opsman.yml` file for each IaaS. + +
+ Defaults for tasks:
+ We do not explicitly set the default parameters
+ for create-vm in this example.
+ Because opsman.yml is the default input to
+ OPSMAN_CONFIG_FILE, it is redundant
+ to set this param in the pipeline.
+ See the Task reference
+ available and default parameters.
+Use with pivotal-container-service tile:
+Rotating certificate authority with the pivotal-container-service
+tile installed causes warnings in the pipeline. Only certificates
+managed by Tanzu Operations Manager will be rotated in this process.
+ This will have read / write access to files in your current working directory.
+ If you need to mount other directories as well, you can add more -v arguments.
+ S3 blobstore compatibility: Many cloud storage options exist, + including Amazon S3, + Google Storage, + Minio, + and Azure Blob Storage. + However, not all object stores are "S3 compatible." + Because Amazon defines the S3 API for accessing blobstores, + and because the Amazon S3 product has emerged as the dominant blob storage solution, + not all "S3 compatible" object stores have exactly the same behavior. + In general, if a storage solution claims to be "S3 compatible," + it should work with the Concourse S3 resource integration. + But note that it may behave differently if interacting directly with the S3 API. + Use the documentation for your preferred blobstore solution + when setting up storage.
+ +1. Set up S3. With your AWS account, navigate to [the S3 console](https://aws.amazon.com/console/) +and sign up for S3. Follow the on-screen prompts. +Now you are ready for buckets. + +
+ AWS root user:
+ When you sign up for the S3 service on Amazon,
+ the account with the email and password you use
+ is the AWS account root user.
+ As a best practice, you should not use the root user
+ to access and manipulate services.
+ Instead, use AWS Identity and Access Management (IAM)
+ to create and manage users.
+ For more information about how this works,
+ see the Amazon IAM guide.
+
+ For simplicity, the rest of this guide uses the AWS root user
+ to show how a bucket can be set up and used with Platform Automation Toolkit.
+Amazon S3 provides many +permission settings for buckets. +Specific IAM users can have access and objects can have their own permissions. In addition, buckets can have their own custom policies. +See Configuring ACLs. +Refer to your organization's security policy for the +best way to set up your S3 bucket.
+ +## Object versions + +By default, an S3 bucket will be unversioned. +An unversioned bucket will not allow different versions of the same object. +In order to take advantage of using an S3 bucket with Platform Automation Toolkit, +we will want to enable versioning. Enabling versioning is not required, +but versioning does make the process easier, +and will require less potential manual steps around naming updates to the new file +whenever they are changed. + +1. Go to the [S3 console](https://aws.amazon.com/console/). +2. Select the name of the bucket you created in the previous step. +3. Click the **Properties** tab. +4. Click the **Versioning** tile. +5. Select **Enable Versioning**. + +Now that versioning is enabled, +we can store multiple versions of a file. +For example, given the following object: +``` +my-exported-installation.zip +``` +We can now have multiple versions of this object stored in our S3 bucket: +``` +my-exported-installation.zip (version 111111) +my-exported-installation.zip (version 121212) +``` + +## Storing files in S3 + +Any file that can be stored on a computer +can be stored on S3. S3 is especially good at storing large files +because it is designed to scale with large amounts of data while +still being durable and fast. + +Platform Automation Toolkit users may want to store the following files in S3: + +- `.pivotal` product files +- `.tgz` stemcell files +- `.ova` Operations Manager files +- `.zip` foundation exports + +You should probably **_not_** store the following in S3: + +- `.yaml` configuration files - Git is better suited for this +- `secrets.yaml` environment and secret files - There are a number of ways +to handle these types of files, but they should not be stored in S3. +See [Using a secrets store to store credentials](../concepts/secrets-handling.html) +for information about working with these types of files. + +## Structuring your bucket + +Buckets can have folders and any number of sub-folders. +The following sample shows one way to set up your bucket file structure: + +``` +├── foundation-1 +│  ├── products +│  │  ├── healthwatch +│ │ │ healthwatch.pivotal +│  │  ├── pas +│ │ │ pas.pivotal +│  │  └── ... +│ │ +│  ├── stemcells +│  │  ├── healthwatch-stemcell +│ │ │ ubuntu-xenial.tgz +│  │  ├── pas-stemcell +│ │ │ ubuntu-xenial.tgz +│  │  └── ... +│ │ +│ ├── foundation1-exports +│    foundation1-installation.zip + +``` + +When viewing a bucket in the AWS S3 console, +click **Create Folder**. +To create a sub-folder, select **Create Folder** again. + +When attempting to access a specific object in a folder, +include the folder structure before the object name: + +``` +foundation1/products/healthwatch/my-healthwatch-product.pivotal +``` + +## Using a bucket + +When using the [Concourse S3 Resource](https://github.com/concourse/s3-resource), +several configuration properties are available +for retrieving objects. The bucket name is required. + +For your Concourse to have access to your S3 bucket, +ensure that you have the appropriate firewall and networking settings +to allow your Concourse instance to +make requests to your bucket. +Concourse uses various "outside" resources +to perform certain jobs. +Ensure that Concourse can communicate with your S3 bucket. + + +## Reference resources pipeline + +The [resources pipeline](../pipelines/resources.html) +may be used to download dependencies from the Broadcom Support portal +and place them into a trusted S3 bucket. +The various `resources_types` use the [Concourse S3 Resource type](https://github.com/concourse/s3-resource) +and several Platform Automation Toolkit tasks to accomplish this. +The following is an S3-specific breakdown of these components +and where to find more information. + +#### The download-product task + +The [`download-product`](../tasks.html#download-product) task lets you download products from the Broadcom Support portal. +If S3 properties are set in the [download config](../inputs-outputs.html#download-product-config), +these files can be put into an S3 bucket. + +If S3 configurations are set, +this task will perform a specific filename operation +that will prepend metadata to the filename. +If you are downloading: + +* product `Example Product version 2.2.1` from the Broadcom Support portal +* with product slug `example-product` +* and version is `2.2.1` + +When downloaded directly from the Broadcom Support portal, the file might look like this: + +``` +product-2.2-build99.pivotal +``` + +Because the Broadcom Support portal file names +do not always have the necessary metadata required by Platform Automation Toolkit, +the download product task will prepend the necessary information +to the filename before it is placed in the S3 bucket: + +``` +[example-product,2.2.1-build99]product-2.2-build99.pivotal +``` + +
+Do not change the meta information prepended by download-product.
+This information is required
+if using a download-product with a blobstore (that is, AWS, GCS)
+to properly parse product versions.
+
+If placing a product file into an blobstore bucket manually,
+ensure that it has the proper file name format;
+opening bracket, the product slug, a single comma, the product's version, and finally, closing bracket.
+There should be no spaces between the two brackets.
+For example, for a product with slug of product-slug and version of 1.1.1:
+
+
+[product-slug,1.1.1]original-filename.pivotal
+
+
+VMware strongly recommends automatically exporting +the Tanzu Operations Manager installation +and persisting it to your blobstore on a regular basis. +This ensures that if you need to upgrade (or restore) +your Tanzu Operations Manager for any reason, +you'll have the latest installation info available. +A time trigger is added later in this tutorial +to help with this.
+ +1. First, switch out the test job +for one that downloads and installs Tanzu Operations Manager. +Do this by changing: + + - the `name` of the job + - the `name` of the task + - the `file` of the task + + The first task in the job should be [`download-product`](../tasks.html#download-product). + It has an additional required input; + the `config` file `download-product` uses to talk to Tanzu Network. + +1. Before writing that file and making it available as a resource, +`get` it (and reference it in the params) +as if it's there. + + It also has an additional output (the downloaded image). + It will be used in a subsequent step, + so you don't have to `put` it anywhere. + +1. Finally, while it's fine for `test` to run in parallel, +the install process shouldn't, so +you also need to add `serial: true` to the job. + + ```yaml hl_lines="2 3 15-21" + jobs: + - name: export-installation + serial: true + plan: + - get: platform-automation-image + resource: platform-automation + params: + globs: ["*image*.tgz"] + unpack: true + - get: platform-automation-tasks + resource: platform-automation + params: + globs: ["*tasks*.zip"] + unpack: true + - get: env + - task: export-installation + image: platform-automation-image + file: platform-automation-tasks/tasks/export-installation.yml + - put: installation + params: + file: installation/installation-*.zip + ``` + + + 1. If you try to `fly` this up to Concourse, + it will again throw errors about resources that don't exist, + so the next step is to make them. + The first new resource you need is the config file. + 2. Push your git repo to a remote on GitHub + to make this (and later, other) configuration available to the pipelines. + GitHub has good [instructions](https://docs.github.com/en/migrations/importing-source-code/using-the-command-line-to-import-source-code/adding-locally-hosted-code-to-github) + you can follow to create a new repository on GitHub. + You can skip over the part + about using `git init` to set up your repo, + since you did that earlier. + +1. Now set up your remote +and use `git push` to make it available. +You will use this repository to hold our single foundation specific configuration. +These instructions use the ["Single repository for each Foundation"](../pipeline-design/configuration-management-strategies.html#single-foundation-pattern) +pattern to structure the configurations. + +1. Add the repository URL to CredHub so that you can reference it +later when you declare the corresponding resource. + + ```yaml + pipeline-repo: git@github.com:username/your-repo-name + ``` + +1. Write an `env.yml` for your Tanzu Operations Manager. + + `env.yml` holds authentication and target information + for a particular Tanzu Operations Manager. + + An example `env.yml` for username/password authentication + is shown below with the required properties. + Please reference [Configuring Env](./configuring-env.html) for the entire list of properties + that can be used with `env.yml` + as well as an example of an `env.yml` + that can be used with UAA (SAML, LDAP, etc.) authentication. + + The property `decryption-passphrase` is required for `import-installation`, + and therefore required for `upgrade-opsman`. + + If your foundation uses authentication other than basic auth, + see [Inputs and Outputs](../inputs-outputs.html) + for more detail on UAA-based authentication. + + + ```yaml + target: ((opsman-url)) + username: ((opsman-username)) + password: ((opsman-password)) + decryption-passphrase: ((opsman-decryption-passphrase)) + ``` + +1. Add and commit the new `env.yml` file: + + ```bash + git add env.yml + git commit -m "Add environment file for foundation" + git push + ``` + +2. Now that the env file is in your git remote, +you can add a resource to tell Concourse how to get it as `env`. + + Since this is (probably) a private repo, + you must create a deploy key Concourse can use to access it. + Follow the [GitHub instructions](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#deploy-keys) + for creating a deploy key. + +1. Place the private key in CredHub so you can use it in your pipeline: + + ```bash + # note the starting space + credhub set \ + --name /concourse/your-team-name/plat-auto-pipes-deploy-key \ + --type ssh \ + --private the/filepath/of/the/key-id_rsa \ + --public the/filepath/of/the/key-id_rsa.pub + ``` + +2. Add this to the resources section of your pipeline file: + + ```yaml + - name: env + type: git + source: + uri: ((pipeline-repo)) + private_key: ((plat-auto-pipes-deploy-key.private_key)) + branch: main + ``` + +3. Put the credentials in CredHub: + + ```bash + # note the starting space throughout + credhub set \ + -n /concourse/your-team-name/foundation/opsman-username \ + -t value -v your-opsman-username + credhub set \ + -n /concourse/your-team-name/foundation/opsman-password \ + -t value -v your-opsman-password + credhub set \ + -n /concourse/your-team-name/foundation/opsman-decryption-passphrase \ + -t value -v your-opsman-decryption-passphrase + ``` + + <%= partial "./paths-and-pipeline-names" %> + +1. To perform interpolation in one of your input files, +you need the [`credhub-interpolate` task](../tasks.html#credhub-interpolate) +Earlier, you relied on Concourse's native integration with CredHub for interpolation. +That worked because you needed to use the variable +in the pipeline itself, not in one of your inputs. + + You can add it to your job + after retrieving your `env` input, + but before the `export-installation` task: + + ```yaml hl_lines="16-26" + jobs: + - name: export-installation + serial: true + plan: + - get: platform-automation-image + resource: platform-automation + params: + globs: ["*image*.tgz"] + unpack: true + - get: platform-automation-tasks + resource: platform-automation + params: + globs: ["*tasks*.zip"] + unpack: true + - get: env + - task: credhub-interpolate + image: platform-automation-image + file: platform-automation-tasks/tasks/credhub-interpolate.yml + params: + CREDHUB_CLIENT: ((credhub-client)) + CREDHUB_SECRET: ((credhub-secret)) + CREDHUB_SERVER: https://your-credhub.example.com + PREFIX: /concourse/your-team-name/foundation + input_mapping: + files: env + output_mapping: + interpolated-files: interpolated-env + - task: export-installation + image: platform-automation-image + file: platform-automation-tasks/tasks/export-installation.yml + input_mapping: + env: interpolated-env + - put: installation + params: + file: installation/installation-*.zip + ``` + +
+ The credhub-interpolate task for this job
+ maps the output from the task (interpolated-files)
+ to interpolated-env.
+ This can be used by the next task in the job
+ to more explicitly define the inputs/outputs of each task.
+ It is also okay to leave the output as interpolated-files
+ if it is appropriately referenced in the next task.
+ You'll be using this,
+ the ultimate form of the fly command to set your pipeline,
+ for the rest of the tutorial.
+
+ You can save yourself some typing by using your bash history
+ (if you did not prepend your command with a space).
+ You can cycle through previous commands with the up and down arrows.
+ Alternatively,
+ Ctrl-r will search your bash history.
+ Holding Ctrl-r, type fly,
+ and you will see the last fly command you ran.
+ Run it with enter, or
+ instead of running it,
+ use Ctrl-r again
+ to see the matching command before that.
+ We recommend frequent, small commits that can be fly set and,
+ ideally, go green.
+
+ This one doesn't actually do anything though, right?
+ Fair, but: setting and running the job
+ gives you feedback on your syntax and variable usage.
+ It can catch typos, resources you forgot to add or misnamed, and so on.
+ Committing when you get to a working point helps keeps the diffs small,
+ and the history tractable.
+ Also, down the line, if you've got more than one pair working on a foundation,
+ the small commits help you keep off one another's toes.
+
+ This workflow is not demonstrated here,
+ but it can even be useful to make a commit,
+ use fly to see if it works,
+ and then push it if and only if it works.
+ If it doesn't, you can use git commit --amend
+ once you've figured out why and fixed it.
+ This workflow makes it easy to keep what is set on Concourse
+ and what is pushed to your source control remote in sync.
+
+ ---
+ opsman-configuration:
+ aws:
+ region: us-west-2
+ vpc_subnet_id: subnet-0292bc845215c2cbf
+ security_group_ids: [ sg-0354f804ba7c4bc41 ]
+ key_pair_name: ops-manager-key # used to SSH to VM
+ iam_instance_profile_name: env_ops_manager
+
+ # At least one IP address (public or private) needs to be assigned to the
+ # VM. It is also permissible to assign both.
+ public_ip: 1.2.3.4 # Reserved Elastic IP
+ private_ip: 10.0.0.2
+
+ # Optional
+ # vm_name: ops-manager-vm # default - ops-manager-vm
+ # boot_disk_size: 100 # default - 200 (GB)
+ # instance_type: m5.large # default - m5.large
+ # NOTE - not all regions support m5.large
+ # assume_role: "arn:aws:iam::..." # necessary if a role is needed to authorize
+ # the OpsMan VM instance profile
+ # tags: {key: value} # key-value pair of tags assigned to the
+ # # Ops Manager VM
+ # Omit if using instance profiles
+ # And instance profile OR access_key/secret_access_key is required
+ # access_key_id: ((access-key-id))
+ # secret_access_key: ((secret-access-key))
+
+ # security_group_id: sg-123 # DEPRECATED - use security_group_ids
+ # use_instance_profile: true # DEPRECATED - will use instance profile for
+ # execution VM if access_key_id and
+ # secret_access_key are not set
+
+ # Optional Ops Manager UI Settings for upgrade-opsman
+ # ssl-certificate: ...
+ # pivotal-network-settings: ...
+ # banner-settings: ...
+ # syslog-settings: ...
+ # rbac-settings: ...
+
+
+
+ Azure
+
+
+
+ ---
+ opsman-configuration:
+ azure:
+ tenant_id: 3e52862f-a01e-4b97-98d5-f31a409df682
+ subscription_id: 90f35f10-ea9e-4e80-aac4-d6778b995532
+ client_id: 5782deb6-9195-4827-83ae-a13fda90aa0d
+ client_secret: ((opsman-client-secret))
+ location: westus
+ resource_group: res-group
+ storage_account: opsman # account name of container
+ ssh_public_key: ssh-rsa AAAAB3NzaC1yc2EAZ... # ssh key to access VM
+
+ # Note that there are several environment-specific details in this path
+ # This path can reach out to other resource groups if necessary
+ subnet_id: /subscriptions//resourceGroups//providers/Microsoft.Network/virtualNetworks//subnets/
+
+ # At least one IP address (public or private) needs to be assigned
+ # to the VM. It is also permissible to assign both.
+ private_ip: 10.0.0.3
+ public_ip: 1.2.3.4
+
+ # Optional
+ # cloud_name: AzureCloud # default - AzureCloud
+ # storage_key: ((storage-key)) # only required if your client does not
+ # have the needed storage permissions
+ # container: opsmanagerimage # storage account container name
+ # default - opsmanagerimage
+ # network_security_group: ops-manager-security-group
+ # vm_name: ops-manager-vm # default - ops-manager-vm
+ # boot_disk_size: 200 # default - 200 (GB)
+ # use_managed_disk: true # this flag is only respected by the
+ # create-vm and upgrade-opsman commands.
+ # set to false if you want to create
+ # the new opsman VM with an unmanaged
+ # disk (not recommended). default - true
+ # storage_sku: Premium_LRS # this sets the SKU of the storage account
+ # for the disk
+ # Allowed values: Standard_LRS, Premium_LRS,
+ # StandardSSD_LRS, UltraSSD_LRS
+ # vm_size: Standard_DS1_v2 # the size of the Ops Manager VM
+ # default - Standard_DS2_v2
+ # Allowed values: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/sizes-general
+ # tags: Project=ECommerce # Space-separated tags: key[=value] [key[=value] ...]. Use '' to
+ # clear existing tags.
+ # vpc_subnet: /subscriptions/... # DEPRECATED - use subnet_id
+ # use_unmanaged_disk: false # DEPRECATED - use use_managed_disk
+
+ # Optional Ops Manager UI Settings for upgrade-opsman
+ # ssl-certificate: ...
+ # pivotal-network-settings: ...
+ # banner-settings: ...
+ # syslog-settings: ...
+ # rbac-settings: ...
+
+
+
+ GCP
+
+
+
+ ---
+ opsman-configuration:
+ gcp:
+ # Either gcp_service_account_name or gcp_service_account json is required
+ # You must remove whichever you don't use
+ gcp_service_account_name: user@project-id.iam.gserviceaccount.com
+ gcp_service_account: ((gcp-service-account-key-json))
+
+ project: project-id
+ region: us-central1
+ zone: us-central1-b
+ vpc_subnet: infrastructure-subnet
+
+ # At least one IP address (public or private) needs to be assigned to the
+ # VM. It is also permissible to assign both.
+ public_ip: 1.2.3.4
+ private_ip: 10.0.0.2
+
+ ssh_public_key: ssh-rsa some-public-key... # RECOMMENDED, but not required
+ tags: ops-manager # RECOMMENDED, but not required
+
+ # Optional
+ # vm_name: ops-manager-vm # default - ops-manager-vm
+ # custom_cpu: 2 # default - 2
+ # custom_memory: 8 # default - 8
+ # boot_disk_size: 100 # default - 100
+ # scopes: ["my-scope"]
+ # hostname: custom.hostname # info: https://cloud.google.com/compute/docs/instances/custom-hostname-vm
+
+ # Optional Ops Manager UI Settings for upgrade-opsman
+ # ssl-certificate: ...
+ # pivotal-network-settings: ...
+ # banner-settings: ...
+ # syslog-settings: ...
+ # rbac-settings: ...
+
+
+
+ Openstack
+
+
+
+ ---
+ opsman-configuration:
+ openstack:
+ project_name: project
+ auth_url: http://os.example.com:5000/v2.0
+ username: ((opsman-openstack-username))
+ password: ((opsman-openstack-password))
+ net_id: 26a13112-b6c2-11e8-96f8-529269fb1459
+ security_group_name: opsman-sec-group
+ key_pair_name: opsman-keypair
+
+ # At least one IP address (public or private) needs to be assigned to the VM.
+ public_ip: 1.2.3.4 # must be an already allocated floating IP
+ private_ip: 10.0.0.3
+
+ # Optional
+ # availability_zone: zone-01
+ # project_domain_name: default
+ # user_domain_name: default
+ # vm_name: ops-manager-vm # default - ops-manager-vm
+ # flavor: m1.xlarge # default - m1.xlarge
+ # identity_api_version: 2 # default - 3
+ # insecure: true # default - false
+
+ # Optional Ops Manager UI Settings for upgrade-opsman
+ # ssl-certificate: ...
+ # pivotal-network-settings: ...
+ # banner-settings: ...
+ # syslog-settings: ...
+ # rbac-settings: ...
+
+
+
+ vSphere
+
+
+
+ ---
+ opsman-configuration:
+ vsphere:
+ vcenter:
+ ca_cert: cert # REQUIRED if insecure = 0 (secure)
+ datacenter: example-dc
+ datastore: example-ds-1
+ folder: /example-dc/vm/Folder # RECOMMENDED, but not required
+ url: vcenter.example.com
+ username: ((vcenter-username))
+ password: ((vcenter-password))
+ resource_pool: /example-dc/host/example-cluster/Resources/example-pool
+ # resource_pool can use a cluster - /example-dc/host/example-cluster
+
+ # Optional
+ # host: host # DEPRECATED - Platform Automation cannot guarantee
+ # the location of the VM, given the nature of vSphere
+ # insecure: 0 # default - 0 (secure) | 1 (insecure)
+
+ disk_type: thin # thin|thick
+ dns: 8.8.8.8
+ gateway: 192.168.10.1
+ hostname: ops-manager.example.com
+ netmask: 255.255.255.192
+ network: example-virtual-network
+ ntp: ntp.ubuntu.com
+ private_ip: 10.0.0.10
+ ssh_public_key: ssh-rsa ...... # REQUIRED Ops Manager >= 2.6
+
+ # Optional
+ # cpu: 1 # default - 1
+ # memory: 8 # default - 8 (GB)
+ # ssh_password: ((ssh-password)) # REQUIRED if ssh_public_key not defined
+ # (Ops Manager < 2.6 ONLY)
+ # vm_name: ops-manager-vm # default - ops-manager-vm
+ # disk_size: 200 # default - 160 (GB), only larger values allowed
+
+ # Optional Ops Manager UI Settings for upgrade-opsman
+ # ssl-certificate: ...
+ # pivotal-network-settings: ...
+ # banner-settings: ...
+ # syslog-settings: ...
+ # rbac-settings: ...
+
+
+
+1. Option 2: Alternatively, you can auto-generate your opsman.yml
+using a `p-automator` command to output an opsman.yml file
+in the directory it is called from.
+
+ **AWS**
+
+ ```bash
+ docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
+ p-automator export-opsman-config \
+ --state-file generated-state/state.yml \
+ --config-file opsman.yml \
+ --aws-region "$AWS_REGION" \
+ --aws-secret-access-key "$AWS_SECRET_ACCESS_KEY" \
+ --aws-access-key-id "$AWS_ACCESS_KEY_ID"
+ ```
+
+ **Azure**
+
+ ```bash
+ docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
+ p-automator export-opsman-config \
+ --state-file generated-state/state.yml \
+ --config-file opsman.yml \
+ --azure-subscription-id "$AZURE_SUBSCRIPTION_ID" \
+ --azure-tenant-id "$AZURE_TENANT_ID" \
+ --azure-client-id "$AZURE_CLIENT_ID" \
+ --azure-client-secret "$AZURE_CLIENT_SECRET" \
+ --azure-resource-group "$AZURE_RESOURCE_GROUP"
+ ```
+
+ **GCP**
+
+ ```bash
+ docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
+ p-automator export-opsman-config \
+ --state-file generated-state/state.yml \
+ --config-file opsman.yml \
+ --gcp-zone "$GCP_ZONE" \
+ --gcp-service-account-json <(echo "$GCP_SERVICE_ACCOUNT_JSON") \
+ --gcp-project-id "$GCP_PROJECT_ID"
+ ```
+
+ **vSphere**
+
+ ```bash
+ docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
+ p-automator export-opsman-config \
+ --state-file generated-state/state.yml \
+ --config-file opsman.yml \
+ --vsphere-url "$VCENTER_URL" \
+ --vsphere-username "$VCENTER_USERNAME" \
+ --vsphere-password "$VCENTER_PASSWORD"
+ ```
+
+1. Once you have your config file, commit and push it:
+
+ ```bash
+ git add opsman.yml
+ git commit -m "Add opsman config"
+ git push
+ ```
+
+2. Get the image for the new Tanzu Operations Manager version using the [`download-product`](../tasks.html#download-product) task.
+It requires a config file to specify which Tanzu Operations Manager to get,
+and to provide Tanzu Network credentials.
+Name this file `download-opsman.yml`:
+
+ ```yaml
+ ---
+ pivnet-api-token: ((pivnet-refresh-token)) # interpolated from CredHub
+ pivnet-file-glob: "ops-manager*.ova"
+ pivnet-product-slug: ops-manager
+ product-version-regex: ^2\.5\.0.*$
+ ```
+
+ ```bash
+ git add download-opsman.yml
+ git commit -m "Add download opsman config"
+ git push
+ ```
+
+1. Now put it all together using the following:
+
+ ```yaml hl_lines="16-46"
+ - name: upgrade-opsman
+ serial: true
+ plan:
+ - get: platform-automation-image
+ resource: platform-automation
+ params:
+ globs: ["*image*.tgz"]
+ unpack: true
+ - get: platform-automation-tasks
+ resource: platform-automation
+ params:
+ globs: ["*tasks*.zip"]
+ unpack: true
+ - get: env
+ - get: installation
+ - task: credhub-interpolate
+ image: platform-automation-image
+ file: platform-automation-tasks/tasks/credhub-interpolate.yml
+ params:
+ CREDHUB_CLIENT: ((credhub-client))
+ CREDHUB_SECRET: ((credhub-secret))
+ CREDHUB_SERVER: ((credhub-server))
+ PREFIX: /concourse/your-team-name/foundation
+ input_mapping:
+ files: env
+ output_mapping:
+ interpolated-files: interpolated-configs
+ - task: download-opsman-image
+ image: platform-automation-image
+ file: platform-automation-tasks/tasks/download-product.yml
+ params:
+ CONFIG_FILE: download-opsman.yml
+ input_mapping:
+ config: interpolated-configs
+ - task: upgrade-opsman
+ image: platform-automation-image
+ file: platform-automation-tasks/tasks/upgrade-opsman.yml
+ input_mapping:
+ config: interpolated-configs
+ image: downloaded-product
+ secrets: interpolated-configs
+ state: env
+ ```
+
+
+ We do not explicitly set the default parameters
+ for upgrade-opsman in this example.
+ Because opsman.yml is the default input to OPSMAN_CONFIG_FILE,
+ env.yml is the default input to ENV_FILE,
+ and state.yml is the default input to STATE_FILE,
+ it is redundant to set this param in the pipeline.
+ See the task definitions
+ for a full range of the
+ available and default parameters.
The `credhub-interpolate` task for this job - maps the output from the task (`interpolated-files`) - to `interpolated-env`. -
This can be used by the next task in the job - to more explicitly define the inputs/outputs of each task. - It is also okay to leave the output as `interpolated-files` - if it is appropriately referenced in the next task - -Notice the [input mappings][concourse-input-mapping] -of the `credhub-interpolate` and `export-installation` tasks. -This allows us to use the output of one task -as in input of another. - -An alternative to `input_mappings` is discussed in -[Configuration Management Strategies][advanced-pipeline-design]. - -We now need to put our `credhub_client` and `credhub_secret` into Credhub, -so Concourse's native integration can retrieve them -and pass them as configuration to the `credhub-interpolate` task. - -```bash -# note the starting space throughout - credhub set \ - -n /concourse/your-team-name/credhub-client \ - -t value -v your-credhub-client - credhub set \ - -n /concourse/your-team-name/credhub-secret \ - -t value -v your-credhub-secret -``` - -Now, the `credhub-interpolate` task -will interpolate our config input, -and pass it to `export-installation` as `config`. - -The other new resource we need is a blobstore, -so we can persist the exported installation. - -We'll add an [S3 resource][s3-resource] -to the `resources` section: - -```yaml -- name: installation - type: s3 - source: - access_key_id: ((s3-access-key-id)) - secret_access_key: ((s3-secret-key)) - bucket: ((platform-automation-bucket)) - regexp: installation-(.*).zip -``` - -Again, we'll need to save the credentials in Credhub: - -```bash -# note the starting space throughout - credhub set \ - -n /concourse/your-team-name/s3-access-key-id \ - -t value -v your-bucket-s3-access-key-id - credhub set \ - -n /concourse/your-team-name/s3-secret-key \ - -t value -v your-s3-secret-key -``` - -This time (and in the future), -when we set the pipeline with `fly`, -we'll need to load vars from `vars.yml`. - -```bash -# note the space before the command - fly -t control-plane set-pipeline \ - -p foundation \ - -c pipeline.yml \ - -l vars.yml -``` - -Now you can manually trigger a build, and see it pass. - -!!! tip "Bash command history" -
You'll be using this, - the ultimate form of the `fly` command to set your pipeline, - for the rest of the tutorial. -
You can save yourself some typing by using your bash history - (if you did not prepend your command with a space). - You can cycle through previous commands with the up and down arrows. - Alternatively, - Ctrl-r will search your bash history. - Just hit Ctrl-r, type `fly`, - and it'll show you the last fly command you ran. - Run it with enter. - Instead of running it, - you can hit Ctrl-r again - to see the matching command before that. - -This is also a good commit point: - -```bash -git add pipeline.yml vars.yml -git commit -m "Export foundation installation in CI" -git push -``` - -### Performing The Upgrade - -Now that we have an exported installation, -we'll create another Concourse job to do the upgrade itself. -We want the export and the upgrade in separate jobs -so they can be triggered (and re-run) independently. - -We know this new job is going to center -on the [`upgrade-opsman`][upgrade-opsman] task. -Click through to the task description, -and write a new job that has `get` steps -for our platform-automation resources -and all the inputs we already know how to get: - -```yaml -- name: upgrade-opsman - serial: true - plan: - - get: platform-automation-image - resource: platform-automation - params: - globs: ["*image*.tgz"] - unpack: true - - get: platform-automation-tasks - resource: platform-automation - params: - globs: ["*tasks*.zip"] - unpack: true - - get: env - - get: installation -``` - -We should be able to set this with `fly` and see it pass, -but it doesn't _do_ anything other than download the resources. -Still, we can make a commit here: - -```bash -git add pipeline.yml -git commit -m "Setup initial gets for upgrade job" -git push -``` - -!!! tip "Is this really a commit point though?" -
We like frequent, small commits that can be `fly` set and, - ideally, go green. -
This one doesn't actually do anything though, right? - Fair, but: setting and running the job - gives you feedback on your syntax and variable usage. - It can catch typos, resources you forgot to add or misnamed, etc. - Committing when you get to a working point helps keeps the diffs small, - and the history tractable. - Also, down the line, if you've got more than one pair working on a foundation, - the small commits help you keep off one another's toes. -
We don't demonstrate this workflow here,
- but it can even be useful to make a commit,
- use `fly` to see if it works,
- and then push it if and only if it works.
- If it doesn't, you can use `git commit --amend`
- once you've figured out why and fixed it.
- This workflow makes it easy to keep what is set on Concourse
- and what is pushed to your source control remote in sync.
-
-Looking over the list of inputs for [`upgrade-opsman`][upgrade-opsman]
-we still need three required inputs:
-
-1. `state`
-1. `config`
-1. `image`
-
-The optional inputs are vars used with the config,
-so we'll get to those when we do `config`.
-
-Let's start with the [state file][state].
-We need to record the `iaas` we're on
-and the ID of the _currently deployed_ Ops Manager VM.
-Different IaaS uniquely identify VMs differently;
-here are examples for what this file should look like,
-depending on your IaaS:
-
-=== "AWS"
- ``` yaml
- --8<-- 'docs/examples/state/aws.yml'
- ```
-
-=== "Azure"
- ``` yaml
- --8<-- 'docs/examples/state/azure.yml'
- ```
-
-=== "GCP"
- ``` yaml
- --8<-- 'docs/examples/state/gcp.yml'
- ```
-
-=== "OpenStack"
- ``` yaml
- --8<-- 'docs/examples/state/openstack.yml'
- ```
-
-=== "vSphere"
- ``` yaml
- --8<-- 'docs/examples/state/vsphere.yml'
- ```
-
-Find what you need for your IaaS,
-write it in your repo as `state.yml`,
-commit it, and push it:
-
-```bash
-git add state.yml
-git commit -m "Add state file for foundation Ops Manager"
-git push
-```
-
-We can map the `env` resource to [`upgrade-opsman`][upgrade-opsman]'s
-`state` input once we add the task.
-
-But first, we've got two more inputs to arrange for.
-
-We'll write an [Ops Manager VM Configuration file][opsman-config]
-to `opsman.yml`.
-The properties available vary by IaaS;
-regardless, you can often inspect your existing Ops Manager
-in your IaaS's console
-(or, if your Ops Manager was created with Terraform,
-look at your terraform outputs)
-to find the necessary values.
-
-=== "AWS"
- ---excerpt--- "examples/aws-configuration"
-=== "Azure"
- ---excerpt--- "examples/azure-configuration"
-=== "GCP"
- ---excerpt--- "examples/gcp-configuration"
-=== "Openstack"
- ---excerpt--- "examples/openstack-configuration"
-=== "vSphere"
- ---excerpt--- "examples/vsphere-configuration"
-
-Alternatively, you can auto-generate your opsman.yml
-using a `p-automator` command to output an opsman.yml file
-in the directory it is called from.
-
-=== "AWS"
- ```bash
- docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
- p-automator export-opsman-config \
- --state-file generated-state/state.yml \
- --config-file opsman.yml \
- --aws-region "$AWS_REGION" \
- --aws-secret-access-key "$AWS_SECRET_ACCESS_KEY" \
- --aws-access-key-id "$AWS_ACCESS_KEY_ID"
- ```
-
-=== "Azure"
- ```bash
- docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
- p-automator export-opsman-config \
- --state-file generated-state/state.yml \
- --config-file opsman.yml \
- --azure-subscription-id "$AZURE_SUBSCRIPTION_ID" \
- --azure-tenant-id "$AZURE_TENANT_ID" \
- --azure-client-id "$AZURE_CLIENT_ID" \
- --azure-client-secret "$AZURE_CLIENT_SECRET" \
- --azure-resource-group "$AZURE_RESOURCE_GROUP"
- ```
-
-=== "GCP"
- ```bash
- docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
- p-automator export-opsman-config \
- --state-file generated-state/state.yml \
- --config-file opsman.yml \
- --gcp-zone "$GCP_ZONE" \
- --gcp-service-account-json <(echo "$GCP_SERVICE_ACCOUNT_JSON") \
- --gcp-project-id "$GCP_PROJECT_ID"
- ```
-
-=== "vSphere"
- ```bash
- docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \
- p-automator export-opsman-config \
- --state-file generated-state/state.yml \
- --config-file opsman.yml \
- --vsphere-url "$VCENTER_URL" \
- --vsphere-username "$VCENTER_USERNAME" \
- --vsphere-password "$VCENTER_PASSWORD"
- ```
-
-Once you have your config file, commit and push it:
-
-```bash
-git add opsman.yml
-git commit -m "Add opsman config"
-git push
-```
-
-Finally, we need the image for the new Ops Manager version.
-
-We'll use the [`download-product`][download-product] task.
-It requires a config file to specify which Ops Manager to get,
-and to provide Tanzu Network credentials.
-Name this file `download-opsman.yml`:
-
-```yaml
----
-pivnet-api-token: ((pivnet-refresh-token)) # interpolated from Credhub
-pivnet-file-glob: "ops-manager*.ova"
-pivnet-product-slug: ops-manager
-product-version-regex: ^2\.5\.0.*$
-```
-
-You know the drill.
-
-```bash
-git add download-opsman.yml
-git commit -m "Add download opsman config"
-git push
-```
-
-Now, we can put it all together:
-
-```yaml hl_lines="16-46"
-- name: upgrade-opsman
- serial: true
- plan:
- - get: platform-automation-image
- resource: platform-automation
- params:
- globs: ["*image*.tgz"]
- unpack: true
- - get: platform-automation-tasks
- resource: platform-automation
- params:
- globs: ["*tasks*.zip"]
- unpack: true
- - get: env
- - get: installation
- - task: credhub-interpolate
- image: platform-automation-image
- file: platform-automation-tasks/tasks/credhub-interpolate.yml
- params:
- CREDHUB_CLIENT: ((credhub-client))
- CREDHUB_SECRET: ((credhub-secret))
- CREDHUB_SERVER: ((credhub-server))
- PREFIX: /concourse/your-team-name/foundation
- input_mapping:
- files: env
- output_mapping:
- interpolated-files: interpolated-configs
- - task: download-opsman-image
- image: platform-automation-image
- file: platform-automation-tasks/tasks/download-product.yml
- params:
- CONFIG_FILE: download-opsman.yml
- input_mapping:
- config: interpolated-configs
- - task: upgrade-opsman
- image: platform-automation-image
- file: platform-automation-tasks/tasks/upgrade-opsman.yml
- input_mapping:
- config: interpolated-configs
- image: downloaded-product
- secrets: interpolated-configs
- state: env
-```
-
-!!! note "Defaults for tasks"
- We do not explicitly set the default parameters
- for `upgrade-opsman` in this example.
- Because `opsman.yml` is the default input to `OPSMAN_CONFIG_FILE`,
- `env.yml` is the default input to `ENV_FILE`,
- and `state.yml` is the default input to `STATE_FILE`,
- it is redundant to set this param in the pipeline.
- Refer to the [task definitions][task-reference] for a full range of the
- available and default parameters.
-
-Set the pipeline.
-
-Before we run the job,
-we should [`ensure`][ensure] that `state.yml` is always persisted
-regardless of whether the `upgrade-opsman` job failed or passed.
-To do this, we can add the following section to the job:
-
-```yaml hl_lines="49-68"
-- name: upgrade-opsman
- serial: true
- plan:
- - get: platform-automation-image
- resource: platform-automation
- params:
- globs: ["*image*.tgz"]
- unpack: true
- - get: platform-automation-tasks
- resource: platform-automation
- params:
- globs: ["*tasks*.zip"]
- unpack: true
- - get: env
- - get: installation
- - task: credhub-interpolate
- image: platform-automation-image
- file: platform-automation-tasks/tasks/credhub-interpolate.yml
- params:
- CREDHUB_CLIENT: ((credhub-client))
- CREDHUB_SECRET: ((credhub-secret))
- CREDHUB_SERVER: ((credhub-server))
- PREFIX: /concourse/your-team-name/foundation
- input_mapping:
- files: env
- output_mapping:
- interpolated-files: interpolated-configs
- - task: download-opsman-image
- image: platform-automation-image
- file: platform-automation-tasks/tasks/download-product.yml
- params:
- CONFIG_FILE: download-opsman.yml
- input_mapping:
- config: interpolated-configs
- - task: upgrade-opsman
- image: platform-automation-image
- file: platform-automation-tasks/tasks/upgrade-opsman.yml
- input_mapping:
- config: interpolated-configs
- image: downloaded-product
- secrets: interpolated-configs
- state: env
- ensure:
- do:
- - task: make-commit
- image: platform-automation-image
- file: platform-automation-tasks/tasks/make-git-commit.yml
- input_mapping:
- repository: env
- file-source: generated-state
- output_mapping:
- repository-commit: env-commit
- params:
- FILE_SOURCE_PATH: state.yml
- FILE_DESTINATION_PATH: state.yml
- GIT_AUTHOR_EMAIL: "ci-user@example.com"
- GIT_AUTHOR_NAME: "CI User"
- COMMIT_MESSAGE: 'Update state file'
- - put: env
- params:
- repository: env-commit
- merge: true
-```
-
-Set the pipeline one final time,
-run the job, and see it pass.
-
-```bash
-git add pipeline.yml
-git commit -m "Upgrade Ops Manager in CI"
-git push
-```
-
-Your upgrade pipeline is now complete.
-You are now free to move on to the next steps of your automation journey.
-
-{% with path="../" %}
- {% include ".internal_link_url.md" %}
-{% endwith %}
-{% include ".external_link_url.md" %}
diff --git a/docs/img/upgrade-flowchart.png b/docs/img/upgrade-flowchart.png
new file mode 100644
index 00000000..99d45ac2
Binary files /dev/null and b/docs/img/upgrade-flowchart.png differ
diff --git a/docs/img/variables-interpolate-flowchart-independent.png b/docs/img/variables-interpolate-flowchart-independent.png
new file mode 100644
index 00000000..a412112b
Binary files /dev/null and b/docs/img/variables-interpolate-flowchart-independent.png differ
diff --git a/docs/img/variables-interpolate-flowchart-mixed.png b/docs/img/variables-interpolate-flowchart-mixed.png
new file mode 100644
index 00000000..28f49d59
Binary files /dev/null and b/docs/img/variables-interpolate-flowchart-mixed.png differ
diff --git a/docs/index.html.md.erb b/docs/index.html.md.erb
new file mode 100644
index 00000000..59deccd0
--- /dev/null
+++ b/docs/index.html.md.erb
@@ -0,0 +1,157 @@
+# Overview
+
+Platform Automation Toolkit provides building blocks
+to create repeatable and reusable automated pipeline(s)
+for upgrading and installing foundations.
+VMware also provides instructions for using these building blocks in various workflows.
+This introduction provides a high-level overview of Platform Automation Toolkit.
+To dive deeper, see the references section.
+
+See the [Getting Started](./getting-started.html) section for instructions
+on how to start using Platform Automation Toolkit.
+
+## About Platform Automation Toolkit
+
+* Uses the [GitHub om repo](https://github.com/pivotal-cf/om),
+ (and by extension, the Tanzu Operations Manager API)
+ to enable command-line interaction with Tanzu Operations Manager
+ ([Understanding the Tanzu Operations Manager Interface](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-operations-manager/3-0/tanzu-ops-manager/pcf-interface.html))
+
+
+
+* Includes a documented reference pipeline
+ showing one possible configuration for using tasks.
+ When automating your platform,
+ there are some manual steps you'll need to take to optimize for automation.
+ These steps will be emphasized to ensure that they are clear to you.
+
+* Comes bundled with [Concourse tasks](https://concourse-ci.org/tasks.html)
+ that demonstrate how to use tasks
+ in a containerized Continuous Integration (CI) system.
+ Platform Automation Toolkit tasks are:
+
+ * Legible: They use
+ human-readable YAML config files that can be edited and managed.
+
+ * Modular: Each task has defined inputs and outputs
+ that perform granular actions.
+
+ * Built for Automation: Tasks are idempotent,
+ so re-running them in a CI won't break builds.
+
+ * Not Comprehensive: Workflows that use Platform Automation Toolkit
+ may also contain `om` commands, custom tasks,
+ and even interactions with the Tanzu Operations Manager user interface.
+ Platform Automation Toolkit is a set of tools to use alongside other tools,
+ rather than a being a comprehensive solution on its own.
+
+* Can be used with a documented and supported deployment of Concourse CI.
+ The [Concourse for Platform Automation docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/concourse-for-tanzu/7-0/tanzu-concourse/installation-install-platform-automation.html) provide a step-by-step tutorial for how to get started.
+ This approach to deploying Concourse uses the BOSH Director deployed by Tanzu Operations Manager to deploy and maintain Concourse, CredHub, and User Account and Authentication (UAA).
+
+
+
+The [Task Reference](./tasks.html) topic discusses the example tasks.
+
+
+Platform Automation Toolkit takes a different approach than PCF Pipelines does. +For instance, Platform Automation Toolkit allows you +to perform installs and upgrades in the same pipeline. +We recommend trying out Platform Automation Toolkit +to get a sense of the features and how they differ +to understand the best transition method for your environment and needs.
+ +## Platform Automation Toolkit and Upgrading Tanzu Operations Manager + +Successful platform engineering teams know that a platform team +that's always up to date is critical for their business. +If they don’t stay up to date, +they miss out on the latest platform features and the services that VMware delivers, +which means their development teams miss out, too. +By not keeping up to date, +platforms could encounter security risks or even application failures. + +VMware offers regular updates for Tanzu Operations Manager and the products it installs, +which ensures that our customers have access to the latest security patches and new features. +For example, VMware releases security patches every six days on average. + +So how can a platform engineering team simplify the platform upgrade process? + +### Small and Continuous Upgrades + +Adopting the practice of small and constant platform updates +is one of the best ways to simplify the platform upgrade process. +This behavior can significantly reduce risk, +increase stability with faster troubleshooting, +and reduce the overall effort of upgrading. +This also creates a culture of continuous iteration +and improves feedback loops with the platform teams and the developers, +building trust across the organization. +A good place to start is to consume every patch. + +How do we do this? + +### Small and Continuous Upgrades With Platform Automation Toolkit + +With Platform Automation Toolkit, +platform teams have the tools to create an automated perpetual upgrade machine, +which can continuously take the latest updates when new software is available, +including Tanzu Platform for Cloud Foundry, VMware Tanzu PKS, Tanzu Operations Manager, stemcells, products, and services. +In addition, Platform Automation Toolkit allows you to: + +* manage multiple foundations and reduce configuration drift + by tracking changes through source control with + externalized configuration + +* create pipelines that handle installs and upgrades to streamline workflows + ++Tanzu Application Service is now called Tanzu Platform for Cloud Foundry. +The current version of Tanzu Platform for Cloud Foundry is 10.0.
+ +## Platform Automation Toolkit and Tanzu Operations Manager + +The following table compares how Tanzu Operations Manager +and Platform Automation Toolkit might run a typical sequence of Tanzu Operations Manager operations: + +| + | Tanzu Operations Manager | +Platform Automation Toolkit | +
|---|---|---|
| When to use | +First install and minor upgrades | +Config changes and patch upgrades | +
| 1. Create Tanzu Operations Manager VM | +Manually prepare IaaS and create Tanzu Operations Manager VM | +create-vm |
+
| 2. Configure who can run ops | +Manually configure internal UAA or external identity provider | +configure-authentication or configure-saml-authentication |
+
| 3. Configure BOSH | +Manually configure BOSH Director | +configure-director with settings saved from BOSH Director with same version |
+
| 4. Add products | +Click Import a Product to upload file, then + to add tile to Installation Dashboard | +upload-and-stage-product |
+
| 5. Configure products | +Manually configure products | +configure-product with settings saved from tiles with same version |
+
| 6. Deploy Products | +Click Apply Changes | +apply-changes |
+
| 7. Upgrade | +Manually export existing Tanzu Operations Manager settings, power off the VM, then create a new, updated + Tanzu Operations Manager VM | +export-installation then upgrade-opsman |
+
| - | Ops Manager | -Platform Automation Toolkit | -
|---|---|---|
| When to Use | -First install and minor upgrades | -Config changes and patch upgrades | -
| 1. Create Ops Manager VM | -Manually prepare IaaS and create Ops Manager VM | -create-vm |
-
| 2. Configure Who Can Run Ops | -Manually configure internal UAA or external identity provider | -configure-authentication or configure-saml-authentication |
-
| 3. Configure BOSH | -Manually configure BOSH Director | -configure-director with settings saved from BOSH Director with same version |
-
| 4. Add Products | -Click Import a Product to upload file, then + to add tile to Installation Dashboard | -upload-and-stage-product |
-
| 5. Configure Products | -Manually configure products | -configure-product with settings saved from tiles with same version |
-
| 6. Deploy Products | -Click Apply Changes | -apply-changes |
-
| 7. Upgrade | -Manually export existing Ops Manager settings, power off the VM, then create a new, updated - Ops Manager VM | -export-installation then upgrade-opsman |
-
+To get the slug needed for many of the procedures on this page, go to +My Dashboard +on the Broadcom Support Portal. +This site requires you to log in. +
+ +## director config + +The config director sets the BOSH tile (director) on Tanzu Operations Manager. + +The `config` input for a director task expects to have a `director.yml` file. +The configuration of the `director.yml` is IAAS specific for some properties; that is, networking. + +There are two ways to build a director config. + +1. Using an already deployed Tanzu Operations Manager, you can extract the config using [staged-director-config](./tasks.html#staged-director-config). +2. Deploying a new Tanzu Operations Manager requires more effort for a `director.yml`. + The configuration of director is variables, based on the features enabled. + This `director.yml` is a very basic example for vSphere. + + ```yaml + --- + az-configuration: + - clusters: + - cluster: cluster-name + resource_pool: resource-pool-name + name: AZ01 + + properties-configuration: + iaas_configuration: + vcenter_host: vcenter.example.com + vcenter_username: admin + vcenter_password: password + ...... + director_configuration: + blobstore_type: local + bosh_recreate_on_next_deploy: false + custom_ssh_banner: null + ...... + security_configuration: + generate_vm_passwords: true + trusted_certificates: + syslog_configuration: + enabled: false + + network-assignment: + network: + name: INFRASTRUCTURE + other_availability_zones: [] + singleton_availability_zone: + name: AZ01 + + networks-configuration: + icmp_checks_enabled: false + networks: + - name: NETWORK-NAME + ...... + + resource-configuration: + compilation: + instance_type: + id: automatic + instances: automatic + ...... + ``` + +The IAAS-specific configuration can be found in the Tanzu Operations Manager API documentation. + +What follows is a list of properties that can be set in the `director.yml` +and a link to the API documentation explaining any IAAS specific properties. + +* `az-configuration` - a list of [availability zones](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0//api/v0/staged/director/availability_zones/get/) +* `networks-configuration` - a list of [named networks](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0//api/v0/staged/director/networks/get/) +* `properties-configuration` - [BOSH Director configuration and properties](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0//api/v0/staged/director/properties/get/) + * `director_configuration` - BOSH Director properties + * `security_configuration` - BOSH Director security properties + * `syslog_configuration` - configure the syslog sinks for the BOSH Director +* `resource-configuration` - [IAAS VM flavor](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0//api/v0/staged/products/product_guid/resources/get/) for the BOSH Director +* `vmextensions-configuration` - create/update/delete [VM extensions](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0/vm-extensions/) + +### GCP Shared VPC + +Support for Shared VPC is done by configuring the `iaas_identifier` path for the [infrastructure subnet](https://techdocs.broadcom.com/us/en/vmware-tanzu/platform/tanzu-operations-manager/3-0/tanzu-ops-manager/gcp-prepare-env-manual.html#create_network), +which includes the host project ID, region of the subnet, and the subnet name. + +For example: + +`[HOST_PROJECT_ID]/[NETWORK]/[SUBNET]/[REGION]` + +## download-product-config + +The `config` input for a download product task +can be used with a `download-config.yml` file to download a tile. +Here are examples of the configuration of the `download-config.yml`: + +**Broadcom Support Portal** (formerly **Tanzu Network**) + +```yaml +--- +pivnet-api-token: token +pivnet-file-glob: "*.pivotal" # must be quoted if starting with a * +pivnet-product-slug: product-slug + +# Either product-version OR product-version-regex is required +# product-version-regex: ^1\.2\..*$ # must not be quoted +product-version: 1.2.3 + +# Optional +# pivnet-disable-ssl: true # default - false +# stemcell-iaas: aws # aws|azure|google|openstack|vsphere + # will attempt to download the latest stemcell + # associated with a product by default +# stemcell-version: 90.90 # specific stemcell version to download +# stemcell-heavy: true # will force download of heavy stemcell + # not available on all IaaSes +# blobstore-bucket: bucket # if set, product files will have their slug and + # version prepended. Set if the product will + # ever be stored in a blobstore +``` + +**S3** + +```yaml +--- +pivnet-file-glob: "*.pivotal" # must be quoted if starting with a * +pivnet-product-slug: product-slug +blobstore-bucket: bucket-name +s3-region-name: us-west-1 # if NOT using AWS s3, value is 'region' + +# Required unless `s3-auth-type: iam` +s3-access-key-id: aws-or-minio-key-id +s3-secret-access-key: aws-or-minio-secret-key + +# Optional +# blobstore-product-path: /path/to/product # default - root path of bucket +# blobstore-stemcell-path: /path/to/stemcell # default - root path of bucket +# s3-disable-ssl: true # default - false +# s3-enable-v2-signing: true # available for compatibility +# s3-auth-type: iam # default - accesskey +# s3-endpoint: s3.endpoint.com # required if NOT using AWS S3 +``` + +**GCS** + +```yaml +--- +pivnet-file-glob: "*.pivotal" # must be quoted if starting with a * +pivnet-product-slug: product-slug +blobstore-bucket: bucket-name +gcs-project-id: project-id +gcs-service-account-json: | + { + "type": "service_account", + "project_id": "project-id", + "private_key_id": "fake-key-id", + "private_key": "-----BEGIN PRIVATE KEY-----\fake-key-----END PRIVATE KEY-----\n", + "client_email": "email@project-id.iam.gserviceaccount.com", + "client_id": "123456789876543212345", + "auth_uri": "https://accounts.google.com/o/oauth2/auth", + "token_uri": "https://accounts.google.com/o/oauth2/token", + "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", + "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/project%40project-id.iam.gserviceaccount.com" + } + +# Optional +# blobstore-product-path: /path/to/product # default - root path of bucket +# blobstore-stemcell-path: /path/to/stemcell # default - root path of bucket +``` + +**Azure** + +```yaml +--- +pivnet-file-glob: "*.pivotal" # must be quoted if starting with a * +pivnet-product-slug: product-slug +blobstore-bucket: container-name +azure-storage-account: 1234567890abcdefghij +azure-storage-key: storage-access-key-from-azure-portal + +# Optional +# blobstore-product-path: /path/to/product # default - root path of bucket +# blobstore-stemcell-path: /path/to/stemcell # default - root path of bucket +``` + +## download-stemcell-product-config + +The `config` input for a download product task +can be used with a `download-config.yml` file to download a stemcell. +The configuration of the `download-config.yml` looks like this: + +<%= partial "examples/download-stemcell-product" %> + +## env + +The `env` input for a task expects to have a `env.yml` file. +This file contains properties for targeting and logging into the Tanzu Operations Manager API. + +**basic auth** + +<%= partial "../examples/env" %> + +**uaa auth** + +<%= partial "../examples/env-uaa" %> + +### Getting the `client-id` and `client-secret` + +Tanzu Operations Manager, by preference, uses Client ID and Client Secret, if these are provided. +To create a Client ID and Client Secret: + +1. Add `uaac target https://YOUR_OPSMANAGER/uaa`. +1. If you are using SAML, `uaac token sso get`. +1. If you are using basic auth, add `uaac token owner get`. +1. Specify the Client ID as `opsman` and leave Client Secret blank. +1. Generate a client ID and secret. + +```bash +uaac client add -i +Client ID: NEW_CLIENT_NAME +New client secret: DESIRED_PASSWORD +Verify new client secret: DESIRED_PASSWORD +scope (list): opsman.admin +authorized grant types (list): client_credentials +authorities (list): opsman.admin +access token validity (seconds): 43200 +refresh token validity (seconds): 43200 +redirect uri (list): +autoapprove (list): +signup redirect url (url): +``` + +## errand config + +The `ERRAND_CONFIG_FILE` input is used in the [`apply-changes`](./tasks.html#apply-changes) task. +This file contains properties for enabling and disabling errands +for a particular run of `apply-changes`. + +To retrieve the default configuration of your product's errands, +you can use [`staged-config`](./tasks.html#staged-config). + +The expected format for this errand config is: + + ```yaml + errands: + sample-product-1: + run_post_deploy: + smoke_tests: default + push-app: false + run_pre_delete: + smoke_tests: true + sample-product-2: + run_post_deploy: + smoke_tests: default + ``` + +## installation + +The file contains the information to restore a Tanzu Operations Manager VM. +The `installation` input for a opsman VM task expects to have a `installation.zip` file. + +This file can be exported from a Tanzu Operations Manager VM using the [export-installation](./tasks.html#export-installation) task. +This file can be imported to a Tanzu Operations Manager VM using the [import-installation](./tasks.html#import-installation) task. + ++This file cannot be manually created. It is a file that must be generated using the export function of Tanzu Operations Manager.
+ +## Tanzu Operations Manager config + +The config for a Tanzu Operations Manager described IAAS specific information for creating the VM; that is, VM flavor (size) and IP addresses. + +The `config` input for opsman task expects to have a `opsman.yml` file. +The configuration of the `opsman.yml` is IAAS specific. + +
+For authentication, you must either set use_instance_profile: true
+or provide a secret_key_id and secret_access_key.
+You must remove key information if you're using an instance profile.
+Using an instance profile allows you to avoid interpolation
+because this file then contains no secrets.
+For authentication either gcp_service_account or gcp_service_account_name is required.
+You must remove the one you are not using.
+Note that using gcp_service_account_name allows you to avoid interpolation,
+because this file then contains no secrets.
+This file cannot be manually created. This file must retrieved from the Broadcom Support portal.
+ +## product config + +There are two ways to build a product config. + +1. Using an already deployed product (tile), you can extract the config using [staged-config](./tasks.html#staged-config). +1. Use an example and fill in the values based on the meta information from the tile. +This `product.yml` is a very basic example for `healthwatch`. + +<%= partial "../examples/product" %> + +The following is a list of properties that can be set in the `product.yml` +and a link to the API documentation explaining the properties. + +* `product-properties` - [Tanzu Operations Manager tile properties](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0//api/v0/staged/director/properties/get/) + +* `network-properties` - a list of [Tanzu Operations Manager named networks](https://apigw-test.vmware.com/stg/v1/m12/api/TanzuOperationsManagerAPIDocumentation/3-0/opsman-api/#tag/Networks-and-AZs-assignment/paths/~1api~1v0~1staged~1products~1%7Bproduct_guid%7D~1networks_and_azs/get) + + +* `resource-config` - for the jobs of the [Tanzu Operations Manager tile](https://developer.broadcom.com/xapis/tanzu-operations-manager-api/3.0//api/v0/staged/products/product_guid/jobs/job_guid/resource_config/put/) + +## state + +This file contains the meta-information needed to manage the Tanzu Operations Manager VM. +The `state` input for a opsman VM task expects to have a `state.yml` file. + +The `state.yml` file contains two properties: + +1. `iaas` is the IAAS the Tanzu Operations Manager VM is hosted on. (`gcp`, `vsphere`, `aws`, `azure`, `openstack`) +2. `vm_id` is the VM unique identifier for the VM. For some IAAS, the VM ID is the VM name. + + Different IaaS uniquely identify VMs differently; + here are examples for what this file should look like, + depending on your IAAS: + + **AWS** + + <%= partial "../examples/state/aws" %> + + **Azure** + + <%= partial "../examples/state/azure" %> + + **GCP** + + <%= partial "../examples/state/gcp" %> + + **OpenStack** + + <%= partial "../examples/state/openstack" %> + + **vSphere** + + <%= partial "../examples/state/vsphere" %> + +## stemcell + +This `stemcell` input requires the stemcell tarball (`.tgz`) as downloaded from the Broadcom Support portal. +It must be in the original filename as that is used by Tanzu Operations Manager to parse metadata. +The filename might look something like `bosh-stemcell-621.76-vsphere-esxi-ubuntu-xenial-go_agent.tgz`. + ++This file cannot be manually created. This file must retrieved from the Broadcom Support portal.
+ +Here's an example of how to pull the vSphere stemcell +using the [download-product](./tasks.html#download-product) task. + +### stemcell.yml + +**AWS** + +```yaml +--- +pivnet-api-token: token +pivnet-file-glob: "bosh-stemcell-*-aws*.tgz" +pivnet-product-slug: stemcells-ubuntu-xenial +product-version-regex: ^170\..*$ +``` + +**Azure** + +```yaml +--- +pivnet-api-token: token +pivnet-file-glob: "bosh-stemcell-*-azure*.tgz" +pivnet-product-slug: stemcells-ubuntu-xenial +product-version-regex: ^170\..*$ +``` + +**GCP** + +```yaml +--- +pivnet-api-token: token +pivnet-file-glob: "bosh-stemcell-*-google*.tgz" +pivnet-product-slug: stemcells-ubuntu-xenial +product-version-regex: ^170\..*$ +``` + +**OpenStack** + +```yaml +--- +pivnet-api-token: token +pivnet-file-glob: "bosh-stemcell-*-openstack*.tgz" +pivnet-product-slug: stemcells-ubuntu-xenial +product-version-regex: ^170\..*$ +``` + +**vSphere** + +```yaml +--- +pivnet-api-token: token +pivnet-file-glob: "bosh-stemcell-*-vsphere*.tgz" +pivnet-product-slug: stemcells-ubuntu-xenial +product-version-regex: ^170\..*$ +``` + + +### download-product task + +```yaml +- task: download-stemcell + image: platform-automation-image + file: platform-automation-tasks/tasks/download-product.yml + params: + CONFIG_FILE: stemcell.yml +``` + +### assign-stemcell-task + +This artifact is an output of [`download-product`](./tasks.html#download-product) +located in the `assign-stemcell-config` output directory. + +This file should resemble the following: + +```yaml +product: cf +stemcell: "97.190" +``` + +## telemetry + +The `config` input for the [collect-telemetry](./tasks.html#collect-telemetry) task +can be used with a `telemetry.yml` file to collect data for VMware +so that VMware staff can learn and measure results +to help put customer experience at the forefront of their product decisions. +The configuration of the `telemetry.yml` looks like this: + +<%= partial "../examples/telemetry" %> diff --git a/docs/inputs-outputs.md b/docs/inputs-outputs.md deleted file mode 100644 index 6335b34a..00000000 --- a/docs/inputs-outputs.md +++ /dev/null @@ -1,434 +0,0 @@ -## Inputs -These are the inputs that can be provided to the tasks. -Each task can only take a specific set, indicated under the `inputs` property of the YAML. - -### director config - -The config director will set the bosh tile (director) on Ops Manager. - -The `config` input for a director task expects to have a `director.yml` file. -The configuration of the `director.yml` is IAAS specific for some properties -- i.e. networking. - -There are two ways to build a director config. - -1. Using an already deployed Ops Manager, you can extract the config using [staged-director-config]. -2. Deploying a brand new Ops Manager requires more effort for a `director.yml`. - The configuration of director is variables based on the features enabled. - For brevity, this `director.yml` is a basic example for vsphere. - ----excerpt--- "examples/director-configuration" - -The IAAS specific configuration can be found in the Ops Manager API documentation. - -Included below is a list of properties that can be set in the `director.yml` -and a link to the API documentation explaining any IAAS specific properties. - -* `az-configuration` - a list of availability zones [Ops Manager API][opsman-api-azs] -* `network-assignment` - the network the bosh director is deployed to [Ops Manager API][opsman-api-network-az-assignment] -* `networks-configuration` - a list of named networks [Ops Manager API][opsman-api-networks] -* `properties-configuration` - * `iaas_configuration` - configuration for the bosh IAAS CPI [Ops Manager API][opsman-api-director-properties] - * `director_configuration` - properties for the bosh director [Ops Manager API][opsman-api-director-properties] - * `security_configuration` - security properties for the bosh director [Ops Manager API][opsman-api-director-properties] - * `syslog_configuration` - configure the syslog sinks for the bosh director [Ops Manager API][opsman-api-director-properties] -* `resource-configuration` - IAAS VM flavor for the bosh director [Ops Manager API][opsman-api-config-resources] -* `vmextensions-configuration` - create/update/delete VM extensions [Ops Manager API][opsman-api-vm-extension] - -#### GCP Shared VPC - -Support for Shared VPC is done via configuring the `iaas_identifier` path for the [infrastructure subnet][gcp-create-network], -which includes the host project id, region of the subnet, and the subnet name. - -For example: - -`[HOST_PROJECT_ID]/[NETWORK]/[SUBNET]/[REGION]` - -### download-product-config - -The `config` input for a download product task -can be used with a `download-config.yml` file to download a tile. -The configuration of the `download-config.yml` looks like this: - -=== "Tanzu Network" - ---excerpt--- "examples/download-product-config-pivnet" -=== "S3" - ---excerpt--- "examples/download-product-config-s3" -=== "GCS" - ---excerpt--- "examples/download-product-config-gcs" -=== "Azure" - ---excerpt--- "examples/download-product-config-azure" - -### download-stemcell-product-config - -The `config` input for a download product task -can be used with a `download-config.yml` file to download a stemcell. -The configuration of the `download-config.yml` looks like this: - ----excerpt--- "examples/download-stemcell-product-config" - -### env - -The `env` input for a task expects to have a `env.yml` file. -This file contains properties for targeting and logging into the Ops Manager API. - -=== "basic auth" - ---excerpt--- "examples/env" -=== "uaa auth" - ---excerpt--- "examples/env-uaa" - -#### Getting the `client-id` and `client-secret` - -Ops Manager will by preference use Client ID and Client Secret if provided. -To create a Client ID and Client Secret - -1. `uaac target https://YOUR_OPSMANAGER/uaa` -1. `uaac token sso get` if using SAML or `uaac token owner get` if using basic auth. Specify the Client ID as `opsman` and leave Client Secret blank. -1. Generate a client ID and secret - -```bash -uaac client add -i -Client ID: NEW_CLIENT_NAME -New client secret: DESIRED_PASSWORD -Verify new client secret: DESIRED_PASSWORD -scope (list): opsman.admin -authorized grant types (list): client_credentials -authorities (list): opsman.admin -access token validity (seconds): 43200 -refresh token validity (seconds): 43200 -redirect uri (list): -autoapprove (list): -signup redirect url (url): -``` - -### errand config - -The `ERRAND_CONFIG_FILE` input for the [`apply-changes`][apply-changes] task. -This file contains properties for enabling and disabling errands -for a particular run of `apply-changes`. - -To retrieve the default configuration of your product's errands, -[`staged-config`][staged-config] can be used. - -The expected format for this errand config is as follows: - - ```yaml - errands: - sample-product-1: - run_post_deploy: - smoke_tests: default - push-app: false - run_pre_delete: - smoke_tests: true - sample-product-2: - run_post_deploy: - smoke_tests: default - ``` - -### installation - -The file contains the information to restore an Ops Manager VM. -The `installation` input for a opsman VM task expects to have a `installation.zip` file. - -This file can be exported from an Ops Manager VM using the [export-installation][export-installation]. -This file can be imported to an Ops Manager VM using the [import-installation][import-installation]. - -!!! warning - This file cannot be manually created. It is a file that must be generated via the export function of Ops Manager. - -### Ops Manager config -The config for an Ops Manager described IAAS specific information for creating the VM -- i.e. VM flavor (size), IP addresses - -The `config` input for opsman task expects to have a `opsman.yml` file. -The configuration of the `opsman.yml` is IAAS specific. - -=== "AWS" - ---excerpt--- "examples/aws-configuration" -=== "Azure" - ---excerpt--- "examples/azure-configuration" -=== "GCP" - ---excerpt--- "examples/gcp-configuration" -=== "Openstack" - ---excerpt--- "examples/openstack-configuration" -=== "vSphere" - ---excerpt--- "examples/vsphere-configuration" -=== "Additional Settings" - ---excerpt--- "examples/opsman-settings" - -Specific advice and features for the different IaaSs are documented below -#### AWS -These required properties are adapted from the instructions outlined in -[Launching an Ops Manager Director Instance on AWS][manual-aws] - -{% include '.ip-addresses.md' %} - -!!! info "Using instance_profile to Avoid Secrets" - For authentication you must either set `use_instance_profile: true` - or provide a `secret_key_id` and `secret_access_key`. - You must remove key information if you're using an instance profile. - Using an instance profile allows you to avoid interpolation, - as this file then contains no secrets. - - -#### Azure -The required properties are adapted from the instructions outlined in -[Launching an Ops Manager Director Instance on Azure][manual-azure] - -{% include '.ip-addresses.md' %} - -#### GCP -The required properties are adapted from the instructions outlined in -[Launching an Ops Manager Director Instance on GCP][manual-gcp] - -{% include '.ip-addresses.md' %} - -!!! info "Using a Service Account Name to Avoid Secrets" - For authentication either `gcp_service_account` or `gcp_service_account_name` is required. - You must remove the one you are not using - note that using `gcp_service_account_name` allows you to avoid interpolation, - as this file then contains no secrets. - -Support for Shared VPC is done via -[configuring the `vpc_subnet` path][gcp-shared-vpc] -to include the host project id, region of the subnet, and the subnet name. - -For example: - -`projects/[HOST_PROJECT_ID]/regions/[REGION]/subnetworks/[SUBNET]` - -#### Openstack - -The required properties are adapted from the instructions outlined in -[Launching an Ops Manager Director Instance on Openstack][manual-openstack] - -{% include '.ip-addresses.md' %} - -#### vSphere - -The required properties are adapted from the instructions outlined in -[Deploying BOSH and Ops Manager to vSphere][manual-vsphere] - -### opsman image - -This file is an [artifact from Tanzu Network](https://network.pivotal.io/products/ops-manager), -which contains the VM image for a specific IaaS. -For vsphere and openstack, it's a full disk image. -For AWS, GCP, and Azure, it's a YAML file listing the location -of images that are already available on the IaaS. - -These are examples to download the image artifact for each IaaS -using the [download-product][download-product] task. - -#### opsman.yml - -{% include "how-to-guides/.opsman-config-tabs.md" %} - -The `p-automator` CLI includes the ability to extract the Ops Manager VM configuration (GCP, AWS, Azure, and VSphere). -This works for Ops Managers that are already running and useful when [migrating to automation][upgrade-how-to]. - -Usage: - -1. Get the Platform Automation Toolkit image from Tanzu Network. -1. Import that image into `docker` to run the [`p-automation` locally][running-commands-locally]. -1. Create a [state file][state] that represents your current VM and IAAS. -1. Invoke the `p-automator` CLI to get the configuration. - -For example, on AWS with an access key and secret key: - -```bash -docker run -it --rm -v $PWD:/workspace -w /workspace platform-automation-image \ -p-automator export-opsman-config \ ---state-file=state.yml \ ---aws-region=us-west-1 \ ---aws-secret-access-key some-secret-key \ ---aws-access-key-id some-access-key -``` - -The outputted `opsman.yml` contains the information needed for Platform Automation Toolkit to manage the Ops Manager VM. - -#### download-product task - -```yaml -- task: download-opsman-image - image: platform-automation-image - file: platform-automation-tasks/tasks/download-product.yml - params: - CONFIG_FILE: opsman.yml -``` - -### product - -The `product` input requires a single tile file (`.pivotal`) as downloaded from Tanzu Network. - -Here's an example of how to pull the Tanzu Application Service tile -using the [download-product][download-product] task. - -#### product.yml - -```yaml ---- -pivnet-api-token: token -pivnet-file-glob: "cf-*.pivotal" -pivnet-product-slug: elastic-runtime -product-version-regex: ^2\.6\..*$ -``` - -#### download-product task - -```yaml -- task: download-stemcell - image: platform-automation-image - file: platform-automation-tasks/tasks/download-product.yml - params: - CONFIG_FILE: product.yml -``` - -!!! warning - This file cannot be manually created. It is a file that must retrieved from Tanzu Network. - -### product config - -There are two ways to build a product config. - -1. Using an already deployed product (tile), you can extract the config using [staged-config]. -1. Use an example and fill in the values based on the meta information from the tile. -For brevity, this `product.yml` is a basic example for `healthwatch`. - ----excerpt--- "examples/product-configuration" - -Included below is a list of properties that can be set in the `product.yml` -and a link to the API documentation explaining the properties. - -* `product-properties` - properties for the tile [Ops Manager API][opsman-api-config-products] -* `network-properties` - a list of named networks to deploy the VMs to [Ops Manager API][opsman-api-config-networks] -* `resource-config` - for the jobs of the tile [Ops Manager API][opsman-api-config-resources] - -### state - -This file contains that meta-information needed to manage the Ops Manager VM. -The `state` input for a opsman VM task expects to have a `state.yml` file. - -The `state.yml` file contains two properties: - -1. `iaas` is the IAAS the ops manager VM is hosted on. (`gcp`, `vsphere`, `aws`, `azure`, `openstack`) -2. `vm_id` is the VM unique identifier for the VM. For some IAAS, the VM ID is the VM name. - -Different IaaS uniquely identify VMs differently; -here are examples for what this file should look like, -depending on your IAAS: - -=== "AWS" - ``` yaml - --8<-- 'docs/examples/state/aws.yml' - ``` - -=== "Azure" - ``` yaml - --8<-- 'docs/examples/state/azure.yml' - ``` - -=== "GCP" - ``` yaml - --8<-- 'docs/examples/state/gcp.yml' - ``` - -=== "OpenStack" - ``` yaml - --8<-- 'docs/examples/state/openstack.yml' - ``` - -=== "vSphere" - ``` yaml - --8<-- 'docs/examples/state/vsphere.yml' - ``` - -### stemcell -This `stemcell` input requires the stemcell tarball (`.tgz`) as downloaded from Tanzu Network. -It must be in the original filename as that is used by Ops Manager to parse metadata. -The filename could look like `bosh-stemcell-621.76-vsphere-esxi-ubuntu-xenial-go_agent.tgz`. - -!!! warning - This file cannot be manually created. It is a file that must retrieved from Tanzu Network. - -Here's an example of how to pull the vSphere stemcell -using the [download-product][download-product] task. - -#### stemcell.yml - -=== "AWS" - ```yaml - --- - pivnet-api-token: token - pivnet-file-glob: "bosh-stemcell-*-aws*.tgz" - pivnet-product-slug: stemcells-ubuntu-xenial - product-version-regex: ^170\..*$ - ``` - -=== "Azure" - ```yaml - --- - pivnet-api-token: token - pivnet-file-glob: "bosh-stemcell-*-azure*.tgz" - pivnet-product-slug: stemcells-ubuntu-xenial - product-version-regex: ^170\..*$ - ``` - -=== "GCP" - ```yaml - --- - pivnet-api-token: token - pivnet-file-glob: "bosh-stemcell-*-google*.tgz" - pivnet-product-slug: stemcells-ubuntu-xenial - product-version-regex: ^170\..*$ - ``` - -=== "OpenStack" - ```yaml - --- - pivnet-api-token: token - pivnet-file-glob: "bosh-stemcell-*-openstack*.tgz" - pivnet-product-slug: stemcells-ubuntu-xenial - product-version-regex: ^170\..*$ - ``` - -=== "vSphere" - ```yaml - --- - pivnet-api-token: token - pivnet-file-glob: "bosh-stemcell-*-vsphere*.tgz" - pivnet-product-slug: stemcells-ubuntu-xenial - product-version-regex: ^170\..*$ - ``` - - -#### download-product task - -```yaml -- task: download-stemcell - image: platform-automation-image - file: platform-automation-tasks/tasks/download-product.yml - params: - CONFIG_FILE: stemcell.yml -``` - -#### assign-stemcell-task -This artifact is an output of [`download-product`][download-product] -located in the `assign-stemcell-config` output directory. - -This file should resemble the following: -```yaml -product: cf -stemcell: "97.190" -``` - -### telemetry - -The `config` input for the [collect-telemetry][collect-telemetry] task -can be used with a `telemetry.yml` file to collect data for VMware -so they can learn and measure results -in order to put customer experience at the forefront of their product decisions. -The configuration of the `telemetry.yml` looks like this: - ----excerpt--- "examples/telemetry" - -{% include ".internal_link_url.md" %} -{% include ".external_link_url.md" %} diff --git a/docs/pipeline-design/configuration-management-strategies.html.md.erb b/docs/pipeline-design/configuration-management-strategies.html.md.erb new file mode 100644 index 00000000..d8eda4ff --- /dev/null +++ b/docs/pipeline-design/configuration-management-strategies.html.md.erb @@ -0,0 +1,390 @@ +# Configuration management strategies + +When building pipelines, there are many strategies +for structuring your configuration in source control +and in pipeline design. +No single method can cover all situations. +This topic presents some of the possibilities and their uses +so that you can choose the best approach +for your situation. + +## Single repository for each foundation + +This is the simplest approach, +and it's the default assumed in all of the examples in these topics, +unless there is a clear reason to use a different approach. +It entails using a single Git repository for each foundation. + +Tracking foundation changes are simple, +getting started is easy, +duplicating foundations involves only cloning a repository, +and configuration files are not difficult to understand. + +This is the strategy used in +[Install Tanzu Operations Manager](../how-to-guides/installing-opsman.html) and +[Upgrading an existing Tanzu Operations Manager](../how-to-guides/upgrade-existing-opsman.html). + +This example configuration repository +uses the "Single Repository for each Foundation" pattern: + +``` +├── auth.yml +├── pas.yml +├── director.yml +├── download-opsman.yml +├── download-product-configs +│  ├── healthwatch.yml +│  ├── opsman.yml +│  ├── pas-windows.yml +│  ├── pas.yml +│  └── telemetry.yml +├── env.yml +├── healthwatch.yml +├── opsman.yml +└── pas-windows.yml +``` + +Notice that there is only one subdirectory +and that all other files are in the base directory. +This minimizes parameter mapping in the platform-automation tasks. +For example, in the [`configure-director`](../tasks.html#configure-director) +step: + +```yaml +- task: configure-director + image: platform-automation-image + file: platform-automation-tasks/tasks/configure-director.yml + input_mapping: + config: configuration + env: configuration +``` + +You map the config files +to the expected input named `env` of the `configure-director` task. +Because the `configure-director` task's default `ENV` parameter is `env.yml`, +it automatically uses the `env.yml` file in the configuration repo. +You do not need to explicitly name the `ENV` parameter for the task. +This also works for `director.yml`. + +Another option for mapping resources to inputs is discussed in +[Matching resource names and input names](#matching-resource-names-and-input-names). + +For reference, here is the `configure-director` task: + ++The inputs, outputs, params, filename, and filepath +of this task file are part of its semantically versioned API. +See www.semver.org for information about semantic versioning. +
+ +<%= partial "../tasks/configure-director" %> + +## Multiple foundations with one repository + +Multiple foundations can use a single Git configuration source, +but have different variables loaded +from a foundation-specific vars file, CredHub, and so on. + +This strategy can reduce foundation drift +and streamline the configuration promotion process between foundations. + +This is the strategy used in the [reference pipeline](../pipelines/multiple-products.html). + +### Overview + +The [reference pipeline](../pipelines/multiple-products.html) uses a public [config repo](https://github.com/pivotal/docs-platform-automation-reference-pipeline-config) +with all secrets stored in the CredHub belonging to Concourse. + +The design considerations for this strategy, as implemented, are: + +- Prioritization of ease of configuration promotion is prioritized + over minimization of configuration + file duplication between foundations. +- Global, non-public variables can be overwritten by + foundation-specific variables based on `VARS_FILES` ordering. +- Product configuration can differ between product versions, + so the entire configuration file is promoted between foundations. +- No outside tooling or additional preparation tasks + are required to use this strategy. + It makes use of only concepts and workflows + built in to Platform Automation and Concourse. +- There are no significant differences between the required setup of the foundations. + + This doesn't mean that this strategy cannot be used + with more complicated differences. + If the pipelines need to be different for one reason or another, + you might want the `pipelines` directory to be at the foundation level + and for the `pipeline.yml` to be foundation-specific. + + The [reference pipeline](../pipelines/multiple-products.html) handles the different environments via a `fly` variable. + The pipeline set script is found in the [`scripts`](https://github.com/pivotal/docs-platform-automation-reference-pipeline-config/blob/develop/scripts/update-reference-pipeline.sh) directory. + +### Structure + +A simplified view of the [config-repo](https://github.com/pivotal/docs-platform-automation-reference-pipeline-config) is represented below: + +``` +├── download-product-pivnet +│  ├── download-opsman.yml +│  └── download-pks.yml +├── foundations +│  ├── config +│  │  ├── auth.yml +│  │  └── env.yml +│  ├── development +│  │  ├── config +│  │  │  ├── director.yml +│  │  │  ├── download-opsman.yml +│  │  │  ├── download-pks.yml +│  │  │  ├── opsman.yml +│  │  │  └── pks.yml +│  │  └── vars +│  │  ├── director.yml +│  │  ├── pks.yml +│  │  └── versions.yml +│  ├── sandbox +│  │  ├── config +│  │  │  ├── director.yml +│  │  │  ├── download-opsman.yml +│  │  │  ├── download-pks.yml +│  │  │  ├── opsman.yml +│  │  │  └── pks.yml +│  │  └── vars +│  │  ├── director.yml +│  │  ├── pks.yml +│  │  └── versions.yml +│  └── vars +│  └── director.yml +├── pipelines +│  ├── download-products.yml +│  └── pipeline.yml +└── scripts + └── update-reference-pipeline.sh +``` + +Starting with with the top-level folders: + +- `download-product-pivnet` contains config files + for downloading products from the Broadcom Support portal + and uploading these products to a blobstore. +- `foundations` contains all of the configuration files + and variable files for all foundations. +- `pipelines` contains the pipeline files + for the resources pipeline and the foundation pipelines. +- `scripts` contains the BASH script for setting all of the pipelines. + +#### foundations + +The `foundations` folder contains all of the foundations plus two additional folders: + +- `config` contains any global config files, in this case, `env.yml` and `auth.yml`. + These files are used by `om` and their structure is not foundation-dependent, + so each foundation pipeline fills out the parameterized variables + from the Concourse credential manager. +- `vars` contains foundation-independent variables for any of the configuration files. + In this example, all of the foundations are on a single IAAS, + so the common vars tend to be IAAS-specific. + These files can also include any other variables determined + to be consistently the same across foundations. + +#### foundations/
+A quicker development deploy process:
+Since all of the legwork is done manually in the sandbox environment,
+there is no need to log in to the development Tanzu Operations Manager environment.
+
+If there are no configuration changes, the only file that needs to be promoted is versions.yml.
env and config,
+and have a passed constraint on only one of them,
+there is a possibility that they will not be at the same SHA for any given job in your pipeline.
+
+Example:
+
+
+ - get: config
+ - get: env
+ passed: [previous-job]
+
+
++ Platform Automation Toolkit is based on Concourse CI. + We recommend that you have some familiarity with Concourse before getting started. + If you are new to Concourse, Concourse CI Tutorials is a good place to start.
+ + + +* Persisted datastore that can be accessed by Concourse resource (for example, s3, gcs, minio) +* A valid [Env file](../how-to-guides/configuring-env.html#generating-env-file): this file will contain credentials necessary to login to Tanzu Operations Manager using the `om` CLI. +It is used by every task within Platform Automation Toolkit +* A valid [Auth file](../how-to-guides/configuring-auth.html#auth-file): this file will contain the credentials necessary to create the Tanzu Operations Manager login the first time +the VM is created. The choices for this file are: + * simple authentication + * saml authentication + +
+ There will be some crossover between the auth file and the env file due to how om is set up and how the system works. It is highly recommended to parameterize these values, and let a credential management system (such as CredHub) fill in these values for you to maintain consistency across files.
+ Ensure that products have been procured from the Broadcom Support portal using the information in + Retrieving external dependencies.
+ +## Installing VMware Tanzu Operations Manager and multiple products + +The pipeline shows how to compose the tasks +to install Tanzu Operations Manager and the Tanzu Platform for Cloud Foundry and Healthwatch products. +Its dependencies are coming from a trusted git repository, +which can be retrieved as shown in [Retrieving external dependencies](../pipelines/resources.html). + +### Full pipeline and reference configurations + +The [docs-platform-automation-reference-pipeline-config](https://github.com/pivotal/docs-platform-automation-reference-pipeline-config) git repository +contains the [full pipeline file](https://github.com/pivotal/docs-platform-automation-reference-pipeline-config/blob/develop/pipelines/pipeline.yml), +along with other pipeline and configuration examples. + +This can be useful when you want to take +a fully assembled pipeline as a starting point. +The rest of this document covers the sections of the full pipeline in more detail. + +## Pipeline components + +### S3 resources + +These can be uploaded manually or from the [reference resources pipeline](../pipelines/resources.html). + +```yaml +resources: +- name: platform-automation-tasks + type: s3 + source: + access_key_id: ((s3_access_key_id)) + secret_access_key: ((s3_secret_access_key)) + region_name: ((s3_region_name)) + bucket: ((s3_pivnet_products_bucket)) + regexp: .*tasks-(.*).zip + +- name: platform-automation-image + type: s3 + source: + access_key_id: ((s3_access_key_id)) + secret_access_key: ((s3_secret_access_key)) + region_name: ((s3_region_name)) + bucket: ((s3_pivnet_products_bucket)) + regexp: .*image-(.*).tgz + +- name: telemetry-collector-binary + type: s3 + source: + access_key_id: ((s3_access_key_id)) + secret_access_key: ((s3_secret_access_key)) + region_name: ((s3_region_name)) + bucket: ((s3_pivnet_products_bucket)) + regexp: .*telemetry-(.*).tgz +``` + +
+If you are retrieving pas-windows and pas-windows-stemcell from an S3 bucket,
+you must use the built-in S3 Concourse resource.
+This is shown in the previous example.
+The download-product task with SOURCE: s3 does not persist meta information
+about necessary stemcell for pas-windows
+because VMware does not distribute the Windows file system.
Alternatively, products may be downloaded using the download-product task with
+the param SOURCE set to s3|azure|gcs.
+In a job, specify the following task:
+ Platform Automation Toolkit is based on Concourse CI. + We recommend that you have some familiarity with Concourse before getting started. + If you are new to Concourse, see Installing Concourse with BOSH.
+ +* Persisted datastore that can be accessed by Concourse resource (for example, s3, gcs, minio) +* A set of valid [download-product-config](../pipelines/multiple-products.html#download-product-config) files: Each product has a configuration YAML of what version to download from the [Broadcom Support portal](https://support.broadcom.com/group/ecx/downloads). +* Broadcom Support portal access to [Platform Automation Toolkit](https://support.broadcom.com/group/ecx/productdownloads?subfamily=Platform%20Automation%20Toolkit) + +## Retrieval from the Broadcom Support portal (formerly Tanzu Network) + +The pipeline downloads dependencies consumed by the tasks +and places them into a trusted s3-like storage provider. +This helps other Concourse deployments without internet access +retrieve task dependencies. + +The pipeline requires configuration for the [download-product](../tasks.html#download-product) task. +See the following for examples that you can use. + +
+Note the unique regex format for blob names,
+for example: \[p-healthwatch,(.*)\]p-healthwatch-.*.pivotal.
+The Broadcom Support portal file names will not always contain the necessary metadata
+to accurately download files from a blobstore (for example, s3, gcs, azure),
+so the product slug and version are prepended when using download-product.
+For more information about how this works,
+and what to expect when using download-product,
+see the download-product task reference
+Tanzu Application Service is now called Tanzu Platform for Cloud Foundry. +The current version of Tanzu Platform for Cloud Foundry is 10.0.
+ + +## v5.2.3 + +March 26, 2025 + + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.38.18 | +| azure-cli | 2.70.0 | +| bbr-cli | [1.9.74](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.74) | +| bosh-cli | [v7.9.4](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.9.4) | +| credhub | [2.9.44](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.44) | +| gcloud-cli | 515.0.0 | +| govc-cli | 0.49.0 | +| om | [7.15.0](https://github.com/pivotal-cf/om/releases/tag/7.15.0) | +| winfs-injector | [0.26.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.26.0) | + +The full Docker image-receipt: Download + +### What's New + +- Added support for specifying a stemcell slug when downloading a product through the `om download-product` command + +## v5.2.2 + +September 18, 2024 + + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.34.21 | +| azure-cli | 2.64.0 | +| bbr-cli | [1.9.69](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.69) | +| bosh-cli | [v7.7.2](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.7.2) | +| credhub | [2.9.37](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.37) | +| gcloud-cli | 493.0.0 | +| govc-cli | 0.43.0 | +| om | [7.14.0](https://github.com/pivotal-cf/om/releases/tag/7.14.0) | +| winfs-injector | [0.26.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.26.0) | + +The full Docker image-receipt: Download + +### Bug Fixes + +- Update tasks to use user supplied env var prefix + + +## v5.2.1 +July 26, 2024 + + +## v5.1.2 + +June 15, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.27.153 | +| azure-cli | 2.49.0 | +| bbr-cli | [1.9.46](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.46) | +| bosh-cli | [v7.2.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.2.3) | +| credhub | [2.9.16](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.16) | +| gcloud-cli | 435.0.1 | +| govc-cli | 0.30.4 | +| om | 45876ef5954ddb419cd88126d77b4e8ebb2ca554-2023-05-03T17:38:11-07:00 | +| winfs-injector | [0.22.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.22.0) | + +The full Docker image-receipt: Download + +### Maintenance Release + +- Update Platform Automation Toolkit to use Ubuntu Jammy-based Paketo buildpack images + + +## v5.1.1 + +May 5, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.24.10 | +| azure-cli | 2.39.0 | +| bbr-cli | [1.9.44](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.44) | +| bosh-cli | [v7.2.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.2.3) | +| credhub | [2.9.14](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.14) | +| gcloud-cli | 429.0.0 | +| govc-cli | 0.30.4 | +| om | 45876ef5954ddb419cd88126d77b4e8ebb2ca554-2023-05-03T17:38:11-07:00 | +| winfs-injector | [0.22.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.22.0) | + +The full Docker image-receipt: Download + +### Bug Fixes + +- Update govc to v0.30.4 +- Delete all python files from vsphere-only docker image + + +## v5.1.0 + +February 27, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.24.10 | +| azure-cli | 2.39.0 | +| bbr-cli | [1.9.38](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.38) | +| bosh-cli | [v7.1.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.1.3) | +| credhub | [2.9.11](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.11) | +| gcloud-cli | 419.0.0 | +| govc-cli | 0.30.2 | +| om | 2ba733630d765e1b41e815ce1b49e825da2c192b-2023-02-24T11:33:19-07:00 | +| winfs-injector | [0.21.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.21.0) | + +The full Docker image-receipt: Download + +### What's New + +- Added new How-to Guide about [Rotating Certificate Authority][rotating-certificate-authority]. + This how-to-guide shows you how to write a pipeline for rotating the certificate authority on an existing Tanzu Operations Manager. +- The following additional tasks have been added to help with rotating certificate authorities: + * [`activate-certificate-authority`][activate-certificate-authority] + * [`configure-new-certificate-authority`][configure-new-certificate-authority] + * [`delete-certificate-authority`][delete-certificate-authority] + * [`generate-certificate`][generate-certificate] + * [`regenerate-certificates`][regenerate-certificates] + + +## v5.0.26 + +June 25, 2024 + + +## v5.0.25 + +June 15, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.27.153 | +| azure-cli | 2.49.0 | +| bbr-cli | [1.9.46](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.46) | +| bosh-cli | [v7.2.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.2.3) | +| credhub | [2.9.16](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.16) | +| gcloud-cli | 435.0.1 | +| govc-cli | 0.30.4 | +| om | 45876ef5954ddb419cd88126d77b4e8ebb2ca554-2023-05-03T17:38:11-07:00 | +| winfs-injector | [0.22.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.22.0) | + +The full Docker image-receipt: Download + +### Maintenance Release + +- Update Platform Automation Toolkit to use Ubuntu Jammy-based Paketo buildpack images + + +## v5.0.24 + +May 5, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.24.10 | +| azure-cli | 2.39.0 | +| bbr-cli | [1.9.44](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.44) | +| bosh-cli | [v7.2.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.2.3) | +| credhub | [2.9.14](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.14) | +| gcloud-cli | 429.0.0 | +| govc-cli | 0.30.4 | +| om | 45876ef5954ddb419cd88126d77b4e8ebb2ca554-2023-05-03T17:38:11-07:00 | +| winfs-injector | [0.22.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.22.0) | + +The full Docker image-receipt: Download + +### Bug Fixes + +- Update govc to v0.30.4 +- Delete all python files from vsphere-only docker image + + +## v4.4.33 + +June 25, 2024 + +## v4.4.32 + +June 15, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.27.153 | +| azure-cli | 2.49.0 | +| bbr-cli | [1.9.46](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.46) | +| bosh-cli | [v7.2.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.2.3) | +| credhub | [2.9.16](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.16) | +| gcloud-cli | 435.0.1 | +| govc-cli | 0.30.4 | +| om | 45876ef5954ddb419cd88126d77b4e8ebb2ca554-2023-05-03T17:38:11-07:00 | +| winfs-injector | [0.22.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.22.0) | + +The full Docker image-receipt: Download + +### Maintenance Release + +- Update Platform Automation Toolkit to use Ubuntu Jammy-based Paketo buildpack images + + +## v4.4.31 + +May 5, 2023 + +### CLI Versions + +| Name | version | +|---|---| +| aws-cli | 1.24.10 | +| azure-cli | 2.39.0 | +| bbr-cli | [1.9.44](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.44) | +| bosh-cli | [v7.2.3](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.2.3) | +| credhub | [2.9.14](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.14) | +| gcloud-cli | 429.0.0 | +| govc-cli | 0.30.4 | +| om | 45876ef5954ddb419cd88126d77b4e8ebb2ca554-2023-05-03T17:38:11-07:00 | +| winfs-injector | [0.22.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.22.0) | + +The full Docker image-receipt: Download + +### Bug Fixes + +- Update govc to v0.30.4 +- Delete all python files from vsphere-only docker image diff --git a/docs/release-notes.md b/docs/release-notes.md deleted file mode 100644 index 28d400bc..00000000 --- a/docs/release-notes.md +++ /dev/null @@ -1,4411 +0,0 @@ - - -{% include "./.opsman_filename_change_note.md" %} - -!!! warning "Azure Updating to 2.5" - Ops Manager will be removing the necessity to provide availability zones for azure. - If your `director.yml`(see [`staged-director-config`][staged-director-config]) - has a block like the following in the networks section: - ```yaml - availability_zone_names: - - "null" - ``` - your deployment will have the following error: - ```json - {"errors":["Availability zones cannot find availability zone with name null"]} - ``` - To fix this error, please remove the `availability_zone_names` section from your azure config, or re-run - [`staged-director-config`][staged-director-config] to update your `director.yml`. - -## v5.0.23 -January 4, 2023 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.24.10 | - | azure-cli | 2.39.0 | - | bbr-cli | [1.9.38](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.38) | - | bosh-cli | [v7.1.0](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.1.0) | - | credhub | [2.9.9](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.9) | - | gcloud-cli | 412.0.0 | - | govc-cli | 0.30.0 | - | om | 694a983454bf38737eb32bf348a6e54099c5618d-2022-10-24T10:50:20-06:00 | - | winfs-injector | [0.21.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.21.0) | - - The full Docker image-receipt: Download - -### Bug Fixes -- bump bundled iso-replicator binary to 0.13.0, compiled with Golang 1.19.4 - - -## v5.0.22 -October 24, 2022 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.24.10 | - | azure-cli | 2.39.0 | - | bbr-cli | [1.9.38](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.38) | - | bosh-cli | [v7.0.1](https://github.com/cloudfoundry/bosh-cli/releases/tag/v7.0.1) | - | credhub | [2.9.6](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.6) | - | gcloud-cli | 406.0.0 | - | govc-cli | 0.29.0 | - | om | 694a983454bf38737eb32bf348a6e54099c5618d-2022-10-24T10:50:20-06:00 | - | winfs-injector | [0.21.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.21.0) | - - The full Docker image-receipt: Download - -### Bug Fixes - Bump versions of included binaries - - -## v5.0.21 -March 21, 2022 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.22.77 | - | azure-cli | 2.34.1 | - | bbr-cli | [1.9.26](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.26) | - | bosh-cli | [v6.4.17](https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.17) | - | credhub | [2.9.3](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.3) | - | gcloud-cli | 377.0.0 | - | govc-cli | 0.27.4 | - | om | 2aeff1d15cfe3e192567098afc107d718110b33f-2022-03-07T14:07:08-05:00 | - | winfs-injector | [0.21.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.21.0) | - - The full Docker image-receipt: Download - -### Bug Fixes -- Bump versions of included binaries - - -## v5.0.20 -January 5, 2022 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.22.28 | - | azure-cli | 2.32.0 | - | bbr-cli | [1.9.21](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.21) | - | bosh-cli | [v6.4.10](https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.10) | - | credhub | [2.9.1](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.1) | - | gcloud-cli | 367.0.0 | - | govc-cli | 0.27.2 | - | om | 87f12ad07a994a2946c2a04303d98dc589e67744-2021-11-30T14:26:51-08:00 | - | winfs-injector | [0.21.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.21.0) | - - The full Docker image-receipt: Download - -### Bug Fixes -- CVE update to container image. -Resolves [USN-5199-1](https://ubuntu.com/security/notices/USN-5199-1), -an issue related to python3.6. -- CVE update to container image. -Resolves [USN-5189-1](https://ubuntu.com/security/notices/USN-5189-1), -an issue related to glib2.0. - - -## v5.0.19 -November 11, 2021 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.22.3 | - | azure-cli | 2.30.0 | - | bbr-cli | [1.9.18](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.18) | - | bosh-cli | [v6.4.7](https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.7) | - | credhub | [2.9.1](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.1) | - | gcloud-cli | 364.0.0 | - | govc-cli | 0.27.1 | - | om | a9865819e957ebd1512c9fb1af41ab4a4ff0e834-2021-11-11T06:57:05-07:00 | - | winfs-injector | [0.19.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.19.0) | - - The full Docker image-receipt: Download - -### Bug Fixes -- CVE update to container image. - Resolves [USN 5133-1](https://ubuntu.com/security/notices/USN-5133-1), - an issue related to ICU crashing - - -## v5.0.18 -September 23, 2021 - -### Bug Fixes -- Fixed an issue on the `tasks/configure-opsman.sh`, which had a line that printed `om` help messages. -- CVE update to container image. - Resolves [USN 5089-1](https://ubuntu.com/security/notices/USN-5089-1), - an issue related to expiring ca certificate. -- CVE update to container image. - Resolves [USN 5079-3](https://ubuntu.com/security/notices/USN-5079-3), - an issue related to curl. -- CVE update to container image. - Resolves [USN-5080-1](https://ubuntu.com/security/notices/USN-5080-1), - an issue related to libgcrypt. -- CVE update to container image. - Resolves [USN-5079-1](https://ubuntu.com/security/notices/USN-5079-1), - an issue related to curl. -- CVE update to container image. - Resolves [USN-5076-1](https://ubuntu.com/security/notices/USN-5076-1), - an issue related to git. -- CVE update to container image. - Resolves [USN-5051-3](https://ubuntu.com/security/notices/USN-5051-3), - an issue related to OpenSSL. -- CVE update to container image. - Resolves [USN-5051-1](https://ubuntu.com/security/notices/USN-5051-1), - an issue related to OpenSSL. -- CVE update to container image. - Resolves [USN-3809-2](https://ubuntu.com/security/notices/USN-3809-2), - an issue related to OpenSSH. - -## v5.0.17 -August 2, 2021 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.20.11 | - | azure-cli | 2.26.1 | - | bbr-cli | [1.9.11](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.11) | - | bosh-cli | [v6.4.4](https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.4) | - | credhub | [2.9.0](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.0) | - | gcloud-cli | 350.0.0 | - | govc-cli | 0.26.0 | - | om | c9895b73b2b111a24b7c4ae787a7603d7f8a2723-2021-08-01T20:26:31-06:00 | - | winfs-injector | [0.19.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.19.0) | - - The full Docker image-receipt: Download - -### Bug Fixes -- The `om` CLI has been explicitly requesting `opaque` tokens. - This was an unintentional and incidental change; - previously it used `jwt`, - the token format UAA provides by default. - The `opaque` token may have been contributing to - a hard-to-reproduce issue in a customer environment, - so we're explicitly switching back to `jwt` tokens. -- CVE update to container image. - Resolves [USN 5021-1](https://ubuntu.com/security/notices/USN-5021-1), - an issue related to libcurl. -- CVE update to container image. - Resolves [USN 4991-1](https://ubuntu.com/security/notices/USN-4991-1), - an issue related to libxml2. - - -## v5.0.16 -June 17, 2021 - -??? info "CLI Versions" - - | Name | version | - |---|---| - | aws-cli | 1.19.96 | - | azure-cli | 2.25.0 | - | bbr-cli | [1.9.7](https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/tag/v1.9.7) | - | bosh-cli | [v6.4.4](https://github.com/cloudfoundry/bosh-cli/releases/tag/v6.4.4) | - | credhub | [2.9.0](https://github.com/cloudfoundry-incubator/credhub-cli/releases/tag/2.9.0) | - | gcloud-cli | 345.0.0 | - | govc-cli | 0.26.0 | - | om | f0370bb68d212b136c1d673684c36bd57173665c-2021-06-17T08:25:19-06:00 | - | winfs-injector | [0.19.0](https://github.com/pivotal-cf/winfs-injector/releases/tag/0.19.0) | - - The full Docker image-receipt: Download - -### Features -- When creating an Ops Manager VM on Vsphere, the disk size can be set via the configuration file to sizes larger than the default of 160 (GB). - - ```yaml - --- - opsman-configuration: - vsphere: - disk_size: 200 - vm_name: ops-manager-vm - cpu: 4 - memory: 16 - disk_type: thin - dns: 8.8.8.8 - gateway: 192.168.10.1 - hostname: ops-manager.example.com - netmask: 255.255.255.192 - network: example-virtual-network - ntp: ntp.ubuntu.com - private_ip: 10.0.0.10 - ssh_public_key: ssh-rsa ...... - vcenter: - ca_cert: cert - datacenter: example-dc - datastore: example-ds-1 - folder: /example-dc/vm/Folder - url: vcenter.example.com - username: ((vcenter-username)) - password: ((vcenter-password)) - resource_pool: /example-dc/host/example-cluster/Resources/example-pool - ``` - -- When creating or updating an Ops Manager VM on Azure, you can set an optional tags argument for creating tags on the Ops Manager VM. - - ```yaml - --- - opsman-configuration: - azure: - tags: Key=Value - vm_name: ops-manager-vm - boot_disk_size: 200 - tenant_id: 3e52862f-a01e-4b97-98d5-f31a409df682 - subscription_id: 90f35f10-ea9e-4e80-aac4-d6778b995532 - client_id: 5782deb6-9195-4827-83ae-a13fda90aa0d - client_secret: ((opsman-client-secret)) - location: westus - resource_group: res-group - storage_account: opsman - ssh_public_key: ssh-rsa AAAAB3NzaC1yc2EAZ... - subnet_id: /subscriptions/+The inputs, outputs, params, filename, and filepath +of this task file are part of its semantically versioned API. +See our documentation for a detailed discussion of our semver API. +See www.semver.org for an explanation of semantic versioning. +
+ +### activate-certificate-authority + +Ensures that the newest certificate authority on Tanzu Operations Manager is active. + +**Task** + +<%= partial "tasks/activate-certificate-authority" %> + +**Implementation** + +<%= partial "tasks/activate-certificate-authority-script" %> + +**Usage** + +```yaml +- task: activate-new-ca + image: platform-automation-image + file: platform-automation-tasks/tasks/activate-certificate-authority.yml + input_mapping: + env: configuration + params: + ENV_FILE: foundations/config/env.yml +``` + +### apply-changes + +Triggers an install on the Tanzu Operations Manager described by the auth file. + +To optionally provide an errand file to manually control errands +for a particular of run of `apply-changes`. +To see an example of this config file, see [Inputs and outputs](./inputs-outputs.html). + +<%= partial "disable-verifiers" %> + +**Task** + +<%= partial "tasks/apply-changes" %> + +**Implementation** + +<%= partial "tasks/apply-changes-script" %> + +**Usage** + +```yaml +- task: apply-product-changes + attempts: 3 + image: platform-automation-image + file: platform-automation-tasks/tasks/apply-changes.yml + input_mapping: + env: configuration + params: + ENV_FILE: foundations/config/env.yml +``` + +### apply-director-changes + +`apply-changes` can also be used to trigger an install for just the BOSH Director +with the `--skip-deploy-products`/`-sdp` flag. + +<%= partial "disable-verifiers" %> + +**Task** + +<%= partial "tasks/apply-director-changes" %> + +**Implementation** + +<%= partial "tasks/apply-director-changes-script" %> + +**Usage** + +```yaml +- task: apply-product-changes + attempts: 3 + image: platform-automation-image + file: platform-automation-tasks/tasks/apply-changes.yml + input_mapping: + env: configuration + params: + ENV_FILE: foundations/config/env.yml +``` + +### assign-multi-stemcell + +`assign-multi-stemcell` assigns multiple stemcells to a provided product. +For more information about how to utilize this workflow, +see [Stemcell Handling](./concepts/stemcell-handling.html). + +**Task** + +<%= partial "tasks/assign-multi-stemcell" %> + +**Implementation** + +<%= partial "tasks/assign-multi-stemcell-script" %> + +**Usage** + +```yaml +- task: assign-multi-stemcell + image: platform-automation-image + file: platform-automation-tasks/tasks/assign-multi-stemcell.yml + params: + ENV_FILE: ((foundation))/env/env.yml +``` + +### assign-stemcell + +`assign-stemcell` assigns a stemcell to a provided product. +For more information about how to use +this workflow, see [Stemcell Handling](./concepts/stemcell-handling.html). + +**Task** + +<%= partial "tasks/assign-stemcell" %> + +**Implementation** + +<%= partial "tasks/assign-stemcell-script" %> + +**Usage** + +```yaml +- task: assign-stemcell + image: platform-automation-image + file: platform-automation-tasks/tasks/assign-stemcell.yml + params: + ENV_FILE: ((foundation))/env/env.yml +``` + +### backup-director + +Use BBR to backup a BOSH Director deployed with Tanzu Operations Manager. + +**Task** + +<%= partial "tasks/backup-director" %> + +**Implementation** + +<%= partial "tasks/backup-director-script" %> + +**Usage** + +```yaml +- task: backup-director + image: platform-automation-image + file: platform-automation-tasks/tasks/backup-director.yml + params: + OPSMAN_SSH_PRIVATE_KEY: ((vsphere_private_ssh_key)) +``` + +### backup-product + +Use BBR to backup a product deployed with Tanzu Operations Manager. + +**Task** + +<%= partial "tasks/backup-product" %> + +**Implementation** + +<%= partial "tasks/backup-product-script" %> + +**Usage** + +```yaml +- task: backup-product + image: platform-automation-image + file: platform-automation-tasks/tasks/backup-product.yml + params: + PRODUCT_NAME: cf + ENV_FILE: env.yml + OPSMAN_SSH_PRIVATE_KEY: ((opsman-ssh-private-key)) +``` + +### backup-tkgi + +Use BBR to backup Tanzu Kubernetes Grid Integrated Edition (TKGI) +deployed with Tanzu Operations Manager. + ++PKS CLI may be temporarily unavailable: +During the backup, the PKS CLI is disabled. +Due to the nature of the backup, some commands may not work as expected.
+ +no_proxy can affect the SSH (though jumpbox) tunneling.
+When the task invokes the bbr CLI, an environment variable (BOSH_ALL_PROXY) has been set,
+this environment variable tries to honor the no_proxy settings.
+The task's usage of the SSH tunnel requires the no_proxy to not be set.
+no_proxy: "" as params on the task.
+
+
+- task: backup-tkgi
+ file: platform-automation-tasks/tasks/backup-tkgi.yml
+ params:
+ no_proxy: ""
+
+
+
+GCP with service account:
+For GCP, if service account is used, the property associated_service_account has to be set explicitly in the iaas_configuration section.
Creates a new certificate authority on Tanzu Operations Manager. This can either create a
+new CA using CredHub or create a new CA using a provided certificate and
+private key in PEM format via the certs/ input.
+Deprecation Notice:
+The credhub-interpolate task will be deprecated in future major versions of Platform Automation Toolkit.
+The prepare-tasks-with-secrets task replaces the credhub-interpolate task on Concourse versions 5.x+
+and provides additional benefits.
+This currently works only with product source being the Broadcom Support portal.
+ +**Task** + +<%= partial "../tasks/download-and-upload-product" %> + +**Implementation** + +<%= partial "../tasks/download-and-upload-product-script" %> + +**Usage** + +```yaml +- task: download-and-upload-pas + image: platform-automation-image + file: platform-automation-tasks/tasks/download-and-upload-product.yml + input_mapping: + env: configuration + config: configuration + params: + ENV_FILE: foundations/config/env.yml + CONFIG_FILE: download-product-pivnet/download-tas.yml +``` + +### download-product + +Downloads a product specified in a config file from the Broadcom Support portal: (`pivnet`), S3(`s3`), GCS(`gcs`), or Azure(`azure`). +Optionally, also downloads the latest stemcell for that product. + +Downloads are cached, so files are not re-downloaded each time. +When downloading from the Broadcom Support portal, +the cached file is verified +using the the Broadcom Support portal checksum +to validate the integrity of that file. +If it does not, the file is re-downloaded. +When downloading from a supported blobstore +the cached file is not-verified, +as there is no checksum from those blobstore APIs to use. + +Outputs can be persisted to any supported blobstore using a `put` to an appropriate resource +for later use with download-product using the `SOURCE` parameter, +or used directly as inputs to [upload-and-stage-product](#upload-and-stage-product) +and [upload-stemcell](#upload-stemcell) tasks. + +This task requires a [download-product config file](./inputs-outputs.html#download-product-config). + +If stemcell-iaas is specified in the download-product config file, +and the specified product is a `.pivotal` file, +`download-product` will attempt to download the stemcell for the product. +It will retrieve the latest compatible stemcell for the specified IaaS. +The valid IaaSs are: + +- `aws` +- `azure` +- `google` +- `openstack` +- `vsphere` + +If a configuration for S3, GCS, or Azure is present in the [download-product config file](./inputs-outputs.html#download-product-config), +the slug and version of the downloaded product file will be prepended in brackets to the filename. +For example: + +- original-pivnet-filenames: + ``` + ops-manager-aws-2.5.0-build.123.yml + cf-2.5.0-build.45.pivotal + ``` + +- download-product-filenames if blobstore configuration is present: + ``` + [ops-manager,2.5.0]ops-manager-aws-2.5.0-build.123.yml + [elastic-runtime,2.5.0]cf-2.5.0-build.45.pivotal + ``` + +This is to allow the same config parameters +that let us select a file from the Broadcom Support portal +select it again when pulling from the supported blobstore. +Note that the filename will be unchanged +if supported blobstore keys are not present in the configuration file. +This avoids breaking current pipelines. + +
+When using the s3 resource in Concourse:
+If you are using a regexp in your s3 resource definition
+that explicitly requires the the Broadcom Support portal filename
+to be the start of the regex, (that is, the pattern starts with ^)
+this won't work when using S3 config.
+The new file format preserves the original filename,
+so it is still possible to match on that,
+but if you need to match from the beginning of the filename,
+that will have been replaced by the prefix described earlier.
+When specifying Tanzu Platform for Cloud Foundry [Windows]: +This task will automatically download and inject the winfs for pas-windows.
+ ++This task cannot download the stemcell for pas-windows on vSphere. +To build this stemcell manually, see +Creating a vSphere Windows stemcell using stembuild +in the VMware Tanzu Platform for Cloud Foundry documentation.
+ +
+When the download product config only has the Broadcom Support portal credentials,
+it will not add the prefix to the downloaded product.
+For example, example-product.pivotal from the Broadcom Support portal will be displayed in the output
+as example-product.pivotal.
+The timestamp is generated using the time on Concourse worker. +If the time is different on different workers, the generated timestamp may fail to sort correctly. +Changing the time or timezone on workers might interfere with ordering.
+ +**Task** + +<%= partial "../tasks/export-installation" %> + +**Implementation** + +<%= partial "../tasks/export-installation-script" %> + +**Usage** + +```yaml +- task: export-installation + image: platform-automation-image + file: platform-automation-tasks/tasks/export-installation.yml + input_mapping: + env: configuration + params: + ENV_FILE: foundations/config/env.yml + INSTALLATION_FILE: ((foundation))-installation-$timestamp.zip +``` + +<%= partial "./export_installation_note" %> + +### generate-certificate + +Generate a certificate, signed by the active Tanzu Operations Manager certificate authority, +for the domains specified in the `DOMAINS` environment variable. + +This task outputs `certificate`, containing `certificate.pem` and +`privatekey.pem` for the new certificate. + +**Task** + +<%= partial "../tasks/generate-certificate" %> + +**Implementation** + +<%= partial "../tasks/generate-certificate-script" %> + + + +### import-installation + +Imports a previously exported installation to Tanzu Operations Manager. + +This is a part of the backup/restore and upgrade lifecycle processes. +This task is used after an installation has been exported and a new Tanzu Operations Manager +has been deployed, but before the new Tanzu Operations Manager is configured. + +**Task** + +<%= partial "../tasks/import-installation" %> + +**Implementation** + +<%= partial "../tasks/import-installation-script" %> + +**Usage** + +```yaml +- task: import-installation + image: platform-automation-image + file: platform-automation-tasks/tasks/import-installation.yml + input_mapping: + env: configuration + params: + ENV_FILE: ((foundation))/env/env.yml + INSTALLATION_FILE: installation-*.zip +``` + +### make-git-commit + +Copies a single file into a repo and makes a commit. +This is useful for persisting the state output of tasks that manage the VM, such as: + +- [create-vm](#create-vm) +- [upgrade-opsman](#upgrade-opsman) +- [delete-vm](#delete-vm) + +It is also useful for persisting the configuration output from: + +- [staged-config](#staged-config) +- [staged-director-config](#staged-director-config) + +
+This commits all changes present
+in the repo used for the repository input,
+in addition to copying in a single file.
+This does not perform a git push.
+You must put the output of this task to a git resource to persist it.
+Concourse 5+ only:
+This task uses a Concourse feature
+that allows inputs and outputs to have the same name.
+This feature is only available in Concourse v5+.
+prepare-image does not work with Concourse v4.
+Concourse 5+ only:
+This task uses a Concourse feature
+that allows inputs and outputs to have the same name.
+This feature is only available in Concourse v5+.
+prepare-tasks-with-secrets does not work with Concourse v4.
+replicate-product does not support storing the replicated product
+in a non-versioned blobstore, because it cannot generate a unique name.
+It is recommended to use the replicated tile immediately in the next task
+rather than storing it and using it in a different job.
+Since revert-staged-changes reverts all changes on a Tanzu Operations Manager,
+it can conflict with tasks that perform stage or configure operations.
+Use passed constraints to ensure things run in the order you mean them to.
+Tanzu Operations Manager is the main interface for interacting with BOSH, +and it has no way of knowing what is happening to the BOSH Director +outside of the Tanzu Operations Manager UI context. +By using this task, you are accepting the risk +that what you are doing cannot be tracked by your Tanzu Operations Manager.
+ ++Tanzu Operations Manager, by design, will re-run failed errands for you. +As this task interacts with BOSH directly, +your errand will not be re-run if it fails. +To replicate this retry behavior in your pipeline, use +the attempts +Concourse feature to run the task more than once.
+ +**Task** + +<%= partial "../tasks/run-bosh-errand" %> + +**Implementation** + +<%= partial "../tasks/run-bosh-errand-script" %> + +**Usage** + +```yaml +- task: run-bosh-errand + image: platform-automation-image + file: platform-automation-tasks/tasks/run-bosh-errand.yml + input_mapping: + env: configuration + params: + PRODUCT_NAME: cf + ERRAND_NAME: smoke_tests + ENV_FILE: foundations/config/env.yml + OPSMAN_SSH_PRIVATE_KEY: ((ops_manager_ssh_private_key)) +``` + +### send-telemetry + +Sends the `.tar` output from [`collect-telemetry`](#collect-telemetry) +to VMware. + +
+To use the send-telemetry,
+you must acquire a license key.
+Contact your VMware representative.
+When using runtime configs, Tanzu Operations Manager owns the default runtime config.
+If you use this task to edit "default" it will be replaced on every Apply Changes.
+Use the NAME param to provide a non-conflicting runtime config.
+
+cat /var/version && echo ""
+set -eux
+
+om --env env/"${ENV_FILE}" activate-certificate-authority
+
+
diff --git a/tasks/_activate-certificate-authority.html.md.erb b/tasks/_activate-certificate-authority.html.md.erb
new file mode 100644
index 00000000..d2a2a605
--- /dev/null
+++ b/tasks/_activate-certificate-authority.html.md.erb
@@ -0,0 +1,20 @@
+
+
+---
+platform: linux
+
+inputs:
+- name: platform-automation-tasks
+- name: env # contains the env file with target OpsMan Information
+
+params:
+ ENV_FILE: env.yml
+ # - Required
+ # - Filepath of the env config YAML
+ # - The path is relative to root of the `env` input
+
+run:
+ path: platform-automation-tasks/tasks/activate-certificate-authority.sh
+
+
+
diff --git a/tasks/apply-changes.sh b/tasks/_apply-changes-script.html.md.erb
old mode 100755
new mode 100644
similarity index 86%
rename from tasks/apply-changes.sh
rename to tasks/_apply-changes-script.html.md.erb
index 5865bbf6..f3557bd8
--- a/tasks/apply-changes.sh
+++ b/tasks/_apply-changes-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet apply-changes-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -29,4 +28,6 @@ fi
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" apply-changes \
${flags[@]}
-# code_snippet apply-changes-script end
+
+
+
diff --git a/tasks/apply-changes.yml b/tasks/_apply-changes.html.md.erb
similarity index 69%
rename from tasks/apply-changes.yml
rename to tasks/_apply-changes.html.md.erb
index 88610bea..aa5de0d0 100644
--- a/tasks/apply-changes.yml
+++ b/tasks/_apply-changes.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet apply-changes start yaml
+
+
---
platform: linux
@@ -21,8 +17,8 @@ params:
RECREATE: false
# - Optional
- # - If true, will recreate all product vms
- # - If true, will also recreate the director vm if there are changes
+ # - If true, will recreate all product VMs
+ # - If true, will also recreate the director VM if there are changes
ERRAND_CONFIG_FILE:
# - Optional
@@ -44,4 +40,6 @@ params:
run:
path: platform-automation-tasks/tasks/apply-changes.sh
-# code_snippet apply-changes end
+
+
+
diff --git a/tasks/apply-director-changes.sh b/tasks/_apply-director-changes-script.html.md.erb
old mode 100755
new mode 100644
similarity index 71%
rename from tasks/apply-director-changes.sh
rename to tasks/_apply-director-changes-script.html.md.erb
index e9bbe0b3..71151203
--- a/tasks/apply-director-changes.sh
+++ b/tasks/_apply-director-changes-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet apply-director-changes-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -14,4 +13,6 @@ fi
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" apply-changes \
${flags[@]}
-# code_snippet apply-director-changes-script end
+
+
+
diff --git a/tasks/apply-director-changes.yml b/tasks/_apply-director-changes.html.md.erb
similarity index 62%
rename from tasks/apply-director-changes.yml
rename to tasks/_apply-director-changes.html.md.erb
index 5cae74c9..7043c7fd 100644
--- a/tasks/apply-director-changes.yml
+++ b/tasks/_apply-director-changes.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet apply-director-changes start yaml
+
+
---
platform: linux
@@ -26,4 +22,6 @@ params:
run:
path: platform-automation-tasks/tasks/apply-director-changes.sh
-# code_snippet apply-director-changes end
+
+
+
diff --git a/tasks/assign-multi-stemcell.sh b/tasks/_assign-multi-stemcell-script.html.md.erb
old mode 100755
new mode 100644
similarity index 50%
rename from tasks/assign-multi-stemcell.sh
rename to tasks/_assign-multi-stemcell-script.html.md.erb
index 282741ce..8fc997cf
--- a/tasks/assign-multi-stemcell.sh
+++ b/tasks/_assign-multi-stemcell-script.html.md.erb
@@ -1,8 +1,10 @@
-#!/usr/bin/env bash
-# code_snippet assign-multi-stemcell-script start bash
+
+
cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" assign-multi-stemcell \
--config config/"${CONFIG_FILE}"
-# code_snippet assign-multi-stemcell-script end
+
+
+
diff --git a/tasks/assign-multi-stemcell.yml b/tasks/_assign-multi-stemcell.html.md.erb
similarity index 64%
rename from tasks/assign-multi-stemcell.yml
rename to tasks/_assign-multi-stemcell.html.md.erb
index 9b1e01fd..08f87f0a 100644
--- a/tasks/assign-multi-stemcell.yml
+++ b/tasks/_assign-multi-stemcell.html.md.erb
@@ -1,10 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet assign-multi-stemcell start yaml
-# This feature is only available in OpsMan 2.6+.
+
+
---
platform: linux
@@ -32,4 +27,6 @@ params:
run:
path: platform-automation-tasks/tasks/assign-multi-stemcell.sh
-# code_snippet assign-multi-stemcell end
+
+
+
diff --git a/tasks/assign-stemcell.sh b/tasks/_assign-stemcell-script.html.md.erb
old mode 100755
new mode 100644
similarity index 51%
rename from tasks/assign-stemcell.sh
rename to tasks/_assign-stemcell-script.html.md.erb
index ec14a1b4..5b2cb5a7
--- a/tasks/assign-stemcell.sh
+++ b/tasks/_assign-stemcell-script.html.md.erb
@@ -1,8 +1,9 @@
-#!/usr/bin/env bash
-# code_snippet assign-stemcell-script start bash
-
+
+
cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" assign-stemcell \
--config config/"${CONFIG_FILE}"
-# code_snippet assign-stemcell-script end
+
+
+
diff --git a/tasks/assign-stemcell.yml b/tasks/_assign-stemcell.html.md.erb
similarity index 67%
rename from tasks/assign-stemcell.yml
rename to tasks/_assign-stemcell.html.md.erb
index 755c69c7..e29bea33 100644
--- a/tasks/assign-stemcell.yml
+++ b/tasks/_assign-stemcell.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet assign-stemcell start yaml
+
+
---
platform: linux
@@ -30,4 +26,6 @@ params:
run:
path: platform-automation-tasks/tasks/assign-stemcell.sh
-# code_snippet assign-stemcell end
+
+
+
diff --git a/tasks/backup-director.sh b/tasks/_backup-director-script.html.md.erb
old mode 100755
new mode 100644
similarity index 87%
rename from tasks/backup-director.sh
rename to tasks/_backup-director-script.html.md.erb
index 149f2f83..7d80bed3
--- a/tasks/backup-director.sh
+++ b/tasks/_backup-director-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet backup-director-script start bash
-
+
+
cat /var/version && echo ""
set -eu
@@ -27,4 +26,5 @@ pushd backup
tar -zcvf director_"$( date +"%Y-%m-%d-%H-%M-%S" )".tgz --remove-files -- */*
popd
-# code_snippet backup-director-script end
+
+
diff --git a/tasks/backup-director.yml b/tasks/_backup-director.html.md.erb
similarity index 73%
rename from tasks/backup-director.yml
rename to tasks/_backup-director.html.md.erb
index 87b2876e..ca1fbfe0 100644
--- a/tasks/backup-director.yml
+++ b/tasks/_backup-director.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet backup-director start yaml
+
+
---
platform: linux
@@ -38,4 +34,6 @@ params:
run:
path: platform-automation-tasks/tasks/backup-director.sh
-# code_snippet backup-director end
+
+
+
diff --git a/tasks/backup-product.sh b/tasks/_backup-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 87%
rename from tasks/backup-product.sh
rename to tasks/_backup-product-script.html.md.erb
index dc53b690..90a9396c
--- a/tasks/backup-product.sh
+++ b/tasks/_backup-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet backup-product-script start bash
-
+
+
cat /var/version && echo ""
set -eu
@@ -29,4 +28,5 @@ pushd backup
tar -zcvf product_"${PRODUCT_NAME}"_"$( date +"%Y-%m-%d-%H-%M-%S" )".tgz --remove-files -- */*
popd
-# code_snippet backup-product-script end
+
+
diff --git a/tasks/backup-product.yml b/tasks/_backup-product.html.md.erb
similarity index 74%
rename from tasks/backup-product.yml
rename to tasks/_backup-product.html.md.erb
index ca33a0dc..a2935229 100644
--- a/tasks/backup-product.yml
+++ b/tasks/_backup-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet backup-product start yaml
+
+
---
platform: linux
@@ -38,4 +34,6 @@ params:
run:
path: platform-automation-tasks/tasks/backup-product.sh
-# code_snippet backup-product end
+
+
+
diff --git a/tasks/backup-tkgi.sh b/tasks/_backup-tkgi-script.html.md.erb
old mode 100755
new mode 100644
similarity index 91%
rename from tasks/backup-tkgi.sh
rename to tasks/_backup-tkgi-script.html.md.erb
index d9f50c80..fe4acd59
--- a/tasks/backup-tkgi.sh
+++ b/tasks/_backup-tkgi-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet backup-tkgi-script start bash
-
+
+
cat /var/version && echo ""
set -eu
@@ -38,4 +37,5 @@ pushd backup
--exclude "${PRODUCT_NAME}"_*.tgz \
--remove-files -- */*
popd
-# code_snippet backup-tkgi-script end
+
+
diff --git a/tasks/backup-tkgi.yml b/tasks/_backup-tkgi.html.md.erb
similarity index 74%
rename from tasks/backup-tkgi.yml
rename to tasks/_backup-tkgi.html.md.erb
index 85f8d53d..757294ae 100644
--- a/tasks/backup-tkgi.yml
+++ b/tasks/_backup-tkgi.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet backup-tkgi start yaml
+
+
---
platform: linux
@@ -35,4 +31,6 @@ params:
run:
path: platform-automation-tasks/tasks/backup-tkgi.sh
-# code_snippet backup-tkgi end
+
+
+
diff --git a/tasks/check-pending-changes.sh b/tasks/_check-pending-changes-script.html.md.erb
old mode 100755
new mode 100644
similarity index 68%
rename from tasks/check-pending-changes.sh
rename to tasks/_check-pending-changes-script.html.md.erb
index 8bbd41aa..3a2026f8
--- a/tasks/check-pending-changes.sh
+++ b/tasks/_check-pending-changes-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet check-pending-changes-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -13,4 +12,6 @@ fi
# shellcheck disable=SC2068
om --env env/"${ENV_FILE}" pending-changes \
${flags[@]}
-# code_snippet check-pending-changes-script end
+
+
+
diff --git a/tasks/check-pending-changes.yml b/tasks/_check-pending-changes.html.md.erb
similarity index 56%
rename from tasks/check-pending-changes.yml
rename to tasks/_check-pending-changes.html.md.erb
index ebcc9645..c4531017 100644
--- a/tasks/check-pending-changes.yml
+++ b/tasks/_check-pending-changes.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet check-pending-changes start yaml
+
+
---
platform: linux
@@ -23,4 +19,6 @@ params:
run:
path: platform-automation-tasks/tasks/check-pending-changes.sh
-# code_snippet check-pending-changes end
+
+
+
diff --git a/tasks/collect-telemetry.sh b/tasks/_collect-telemetry-script.html.md.erb
old mode 100755
new mode 100644
similarity index 87%
rename from tasks/collect-telemetry.sh
rename to tasks/_collect-telemetry-script.html.md.erb
index 251671f1..f93615c6
--- a/tasks/collect-telemetry.sh
+++ b/tasks/_collect-telemetry-script.html.md.erb
@@ -1,5 +1,5 @@
-#!/bin/bash
-# code_snippet collect-telemetry-script start bash
+
+
set -eux
cat config/"${CONFIG_FILE}" env/"${ENV_FILE}" >combined-config.yml
@@ -24,4 +24,6 @@ om --env env/"${ENV_FILE}" curl --path /api/v0/info >/dev/null 2>&1
./telemetry-collector-binary/telemetry-collector-linux-amd64 collect \
--output-dir ./collected-telemetry-data \
--config /tmp/pipe.yml
-# code_snippet collect-telemetry-script end bash
+
+
+
diff --git a/tasks/collect-telemetry.yml b/tasks/_collect-telemetry.html.md.erb
similarity index 73%
rename from tasks/collect-telemetry.yml
rename to tasks/_collect-telemetry.html.md.erb
index 069343c4..d5eeba17 100644
--- a/tasks/collect-telemetry.yml
+++ b/tasks/_collect-telemetry.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet collect-telemetry start yaml
+
+
---
platform: linux
@@ -38,4 +34,6 @@ params:
run:
path: platform-automation-tasks/tasks/collect-telemetry.sh
-# code_snippet collect-telemetry end
+
+
+
diff --git a/tasks/configure-authentication.sh b/tasks/_configure-authentication-script.html.md.erb
old mode 100755
new mode 100644
similarity index 74%
rename from tasks/configure-authentication.sh
rename to tasks/_configure-authentication-script.html.md.erb
index b186b72f..cc4684d0
--- a/tasks/configure-authentication.sh
+++ b/tasks/_configure-authentication-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-authentication-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -14,4 +13,6 @@ done
om --env env/"${ENV_FILE}" --skip-ssl-validation configure-authentication \
--config config/"${AUTH_CONFIG_FILE}" \
${vars_files_args[@]}
-# code_snippet configure-authentication-script end
+
+
+
diff --git a/tasks/configure-authentication.yml b/tasks/_configure-authentication.html.md.erb
similarity index 63%
rename from tasks/configure-authentication.yml
rename to tasks/_configure-authentication.html.md.erb
index 2e6dc39b..68b1ebdf 100644
--- a/tasks/configure-authentication.yml
+++ b/tasks/_configure-authentication.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-authentication start yaml
+
+
---
platform: linux
@@ -25,10 +21,12 @@ params:
VARS_FILES:
# - Optional
- # - Filepath to the Ops Manager vars yaml file
+ # - Filepath to the Ops Manager vars YAML file
# - The path is relative to root of the task build
# - These vars can come from the `env` or `config` inputs
run:
path: platform-automation-tasks/tasks/configure-authentication.sh
-# code_snippet configure-authentication end
+
+
+
diff --git a/tasks/configure-director.sh b/tasks/_configure-director-script.html.md.erb
old mode 100755
new mode 100644
similarity index 82%
rename from tasks/configure-director.sh
rename to tasks/_configure-director-script.html.md.erb
index f8ffde5c..df76d0f6
--- a/tasks/configure-director.sh
+++ b/tasks/_configure-director-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-director-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -21,4 +20,6 @@ om --env env/"${ENV_FILE}" configure-director \
--config "config/${DIRECTOR_CONFIG_FILE}" \
${vars_files_args[@]} \
${ops_files_args[@]}
-# code_snippet configure-director-script end
+
+
+
diff --git a/tasks/configure-director.yml b/tasks/_configure-director.html.md.erb
similarity index 66%
rename from tasks/configure-director.yml
rename to tasks/_configure-director.html.md.erb
index fbb1d850..57f62728 100644
--- a/tasks/configure-director.yml
+++ b/tasks/_configure-director.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-director start yaml
+
+
---
platform: linux
@@ -23,13 +19,13 @@ inputs:
params:
VARS_FILES:
# - Optional
- # - Filepath to the Ops Manager vars yaml file
+ # - Filepath to the Ops Manager vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPS_FILES:
# - Optional
- # - Filepath to the Ops Manager operations yaml files
+ # - Filepath to the Ops Manager operations YAML files
# - The path is relative to root of the task build
ENV_FILE: env.yml
@@ -39,9 +35,11 @@ params:
DIRECTOR_CONFIG_FILE: director.yml
# - Required
- # - Filepath to the director configuration yaml file
+ # - Filepath to the director configuration YAML file
# - The path is relative to the root of the `config` input
run:
path: platform-automation-tasks/tasks/configure-director.sh
-# code_snippet configure-director end
+
+
+
diff --git a/tasks/configure-ldap-authentication.sh b/tasks/_configure-ldap-authentication-script.html.md.erb
old mode 100755
new mode 100644
similarity index 73%
rename from tasks/configure-ldap-authentication.sh
rename to tasks/_configure-ldap-authentication-script.html.md.erb
index a621f66d..876fda50
--- a/tasks/configure-ldap-authentication.sh
+++ b/tasks/_configure-ldap-authentication-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-ldap-authentication-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -14,4 +13,6 @@ done
om --env env/"${ENV_FILE}" --skip-ssl-validation configure-ldap-authentication \
--config config/"${AUTH_CONFIG_FILE}" \
${vars_files_args[@]}
-# code_snippet configure-ldap-authentication-script end
+
+
+
diff --git a/tasks/configure-ldap-authentication.yml b/tasks/_configure-ldap-authentication.html.md.erb
similarity index 62%
rename from tasks/configure-ldap-authentication.yml
rename to tasks/_configure-ldap-authentication.html.md.erb
index 6c6c0506..f5bca18f 100644
--- a/tasks/configure-ldap-authentication.yml
+++ b/tasks/_configure-ldap-authentication.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-ldap-authentication start yaml
+
+
---
platform: linux
@@ -25,10 +21,12 @@ params:
VARS_FILES:
# - Optional
- # - Filepath to the Ops Manager vars yaml file
+ # - Filepath to the Ops Manager vars YAML file
# - The path is relative to root of the task build
# - These vars can come from the `env` or `config` inputs
run:
path: platform-automation-tasks/tasks/configure-ldap-authentication.sh
-# code_snippet configure-ldap-authentication end
+
+
+
diff --git a/tasks/configure-new-certificate-authority.sh b/tasks/_configure-new-certificate-authority-script.html.md.erb
old mode 100755
new mode 100644
similarity index 70%
rename from tasks/configure-new-certificate-authority.sh
rename to tasks/_configure-new-certificate-authority-script.html.md.erb
index b76230df..6e5cba06
--- a/tasks/configure-new-certificate-authority.sh
+++ b/tasks/_configure-new-certificate-authority-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-new-certificate-authority-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -12,4 +11,6 @@ if [[ -f "certs/certificate.pem" && -f "certs/privatekey.pem" ]]; then
else
om --env env/"${ENV_FILE}" generate-certificate-authority
fi
-# code_snippet configure-new-certificate-authority-script end
+
+
+
diff --git a/tasks/configure-new-certificate-authority.yml b/tasks/_configure-new-certificate-authority.html.md.erb
similarity index 55%
rename from tasks/configure-new-certificate-authority.yml
rename to tasks/_configure-new-certificate-authority.html.md.erb
index 6992e7fb..60baf1ad 100644
--- a/tasks/configure-new-certificate-authority.yml
+++ b/tasks/_configure-new-certificate-authority.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-new-certificate-authority start yaml
+
+
---
platform: linux
@@ -21,4 +17,6 @@ params:
run:
path: platform-automation-tasks/tasks/configure-new-certificate-authority.sh
-# code_snippet configure-new-certificate-authority end
\ No newline at end of file
+
+
+
diff --git a/tasks/configure-opsman.sh b/tasks/_configure-opsman-script.html.md.erb
old mode 100755
new mode 100644
similarity index 75%
rename from tasks/configure-opsman.sh
rename to tasks/_configure-opsman-script.html.md.erb
index b41b7e90..0ea74b4c
--- a/tasks/configure-opsman.sh
+++ b/tasks/_configure-opsman-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-opsman-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -15,4 +14,5 @@ om --env env/"${ENV_FILE}" configure-opsman \
--config "config/${OPSMAN_CONFIG_FILE}" \
${vars_files_args[@]}
-# code_snippet configure-opsman-script end
+
+
diff --git a/tasks/configure-opsman.yml b/tasks/_configure-opsman.html.md.erb
similarity index 73%
rename from tasks/configure-opsman.yml
rename to tasks/_configure-opsman.html.md.erb
index 854f61a1..fb7cc1eb 100644
--- a/tasks/configure-opsman.yml
+++ b/tasks/_configure-opsman.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-opsman start yaml
+
+
---
platform: linux
@@ -35,9 +31,11 @@ params:
# - filepath of the Ops Manager Application Settings
# config file. (such as banner, pivnet token, etc)
# - relative to root of the `config` input
- # - It is recommended to use one config file to
+ # - VMware recommends using one config file to
# configure-opsman, upgrade-opsman, create-vm, delete-vm
run:
path: platform-automation-tasks/tasks/configure-opsman.sh
-# code_snippet configure-opsman end
+
+
+
diff --git a/tasks/configure-product.sh b/tasks/_configure-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 81%
rename from tasks/configure-product.sh
rename to tasks/_configure-product-script.html.md.erb
index fdbaf06d..2edab52c
--- a/tasks/configure-product.sh
+++ b/tasks/_configure-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-product-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -21,4 +20,6 @@ om --env env/"${ENV_FILE}" configure-product \
--config "config/${CONFIG_FILE}" \
${vars_files_args[@]} \
${ops_files_args[@]}
-# code_snippet configure-product-script end
+
+
+
diff --git a/tasks/configure-product.yml b/tasks/_configure-product.html.md.erb
similarity index 65%
rename from tasks/configure-product.yml
rename to tasks/_configure-product.html.md.erb
index ec2deb6a..c54a884d 100644
--- a/tasks/configure-product.yml
+++ b/tasks/_configure-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-product start yaml
+
+
---
platform: linux
@@ -23,18 +19,18 @@ inputs:
params:
CONFIG_FILE:
# - Required
- # - Filepath to the product configuration yaml file
+ # - Filepath to the product configuration YAML file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
- # - Filepath to the product configuration vars yaml file
+ # - Filepath to the product configuration vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPS_FILES:
# - Optional
- # - Filepath to the product configuration operations yaml files
+ # - Filepath to the product configuration operations YAML files
# - The path is relative to root of the task build
ENV_FILE: env.yml
@@ -44,4 +40,6 @@ params:
run:
path: platform-automation-tasks/tasks/configure-product.sh
-# code_snippet configure-product end
+
+
+
diff --git a/tasks/configure-saml-authentication.sh b/tasks/_configure-saml-authentication-script.html.md.erb
old mode 100755
new mode 100644
similarity index 73%
rename from tasks/configure-saml-authentication.sh
rename to tasks/_configure-saml-authentication-script.html.md.erb
index b11ab067..ed676327
--- a/tasks/configure-saml-authentication.sh
+++ b/tasks/_configure-saml-authentication-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet configure-saml-authentication-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -14,4 +13,6 @@ done
om --env env/"${ENV_FILE}" --skip-ssl-validation configure-saml-authentication \
--config config/"${AUTH_CONFIG_FILE}" \
${vars_files_args[@]}
-# code_snippet configure-saml-authentication-script end
+
+
+
diff --git a/tasks/configure-saml-authentication.yml b/tasks/_configure-saml-authentication.html.md.erb
similarity index 62%
rename from tasks/configure-saml-authentication.yml
rename to tasks/_configure-saml-authentication.html.md.erb
index 83646ab2..50760755 100644
--- a/tasks/configure-saml-authentication.yml
+++ b/tasks/_configure-saml-authentication.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet configure-saml-authentication start yaml
+
+
---
platform: linux
@@ -25,10 +21,12 @@ params:
VARS_FILES:
# - Optional
- # - Filepath to the Ops Manager vars yaml file
+ # - Filepath to the Ops Manager vars YAML file
# - The path is relative to root of the task build
# - These vars can come from the `env` or `config` inputs
run:
path: platform-automation-tasks/tasks/configure-saml-authentication.sh
-# code_snippet configure-saml-authentication end
+
+
+
diff --git a/tasks/create-vm.sh b/tasks/_create-vm-script.html.md.erb
old mode 100755
new mode 100644
similarity index 93%
rename from tasks/create-vm.sh
rename to tasks/_create-vm-script.html.md.erb
index b4d2deb4..880ecf0c
--- a/tasks/create-vm.sh
+++ b/tasks/_create-vm-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet create-vm-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -42,5 +41,5 @@ om vm-lifecycle create-vm \
# input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2086
cp state/${input_state_file} "generated-state/${generated_state_file_name}"
-
-# code_snippet create-vm-script end
+
+
diff --git a/tasks/create-vm.yml b/tasks/_create-vm.html.md.erb
similarity index 76%
rename from tasks/create-vm.yml
rename to tasks/_create-vm.html.md.erb
index d132b821..04606221 100644
--- a/tasks/create-vm.yml
+++ b/tasks/_create-vm.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet create-vm start yaml
+
+
---
platform: linux
@@ -26,7 +22,7 @@ outputs:
params:
VARS_FILES:
# - Optional
- # - Filepath to the Ops Manager vars yaml file
+ # - Filepath to the Ops Manager vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
@@ -37,7 +33,7 @@ params:
STATE_FILE: state.yml
# - Required
- # - Filepath of the state yaml file
+ # - Filepath of the state YAML file
# - The path is relative to root of the `state` output
# - if the filename includes "$timestamp",
# for example "state-$timestamp.yml",
@@ -50,4 +46,6 @@ params:
run:
path: platform-automation-tasks/tasks/create-vm.sh
-# code_snippet create-vm end
+
+
+
diff --git a/tasks/credhub-interpolate.sh b/tasks/_credhub-interpolate-script.html.md.erb
old mode 100755
new mode 100644
similarity index 88%
rename from tasks/credhub-interpolate.sh
rename to tasks/_credhub-interpolate-script.html.md.erb
index 7bb4ffb8..5c17affb
--- a/tasks/credhub-interpolate.sh
+++ b/tasks/_credhub-interpolate-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet credhub-interpolate-script start bash
-
+
+
cat /var/version && echo ""
set -euo pipefail
@@ -36,5 +35,5 @@ for file in ${files}; do
--file files/"${file}" ${flags[@]} \
>interpolated-files/"${file}"
done
-
-# code_snippet credhub-interpolate-script end
+
+
diff --git a/tasks/credhub-interpolate.yml b/tasks/_credhub-interpolate.html.md.erb
similarity index 75%
rename from tasks/credhub-interpolate.yml
rename to tasks/_credhub-interpolate.html.md.erb
index f00c6a8f..e43b3d0c 100644
--- a/tasks/credhub-interpolate.yml
+++ b/tasks/_credhub-interpolate.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet credhub-interpolate start yaml
+
+
---
platform: linux
@@ -17,7 +13,7 @@ inputs:
outputs:
- name: interpolated-files
-# Contains only yaml files found and interpolated by this task.
+# Contains only YAML files found and interpolated by this task.
# Maintains the filestructure of the `files` input.
# all params are required to be filled out
@@ -32,7 +28,7 @@ params:
CREDHUB_CA_CERT:
# - Optional
# - This is only necessary if your Concourse worker
- # is not already configured to trust the CA used for Credhub.
+ # is not already configured to trust the CA used for CredHub.
# - If more than one CA cert is required (ie the UAA),
# the CA certs can be concatenated together and separated by a newline.
# For example,
@@ -61,4 +57,6 @@ params:
run:
path: platform-automation-tasks/tasks/credhub-interpolate.sh
-# code_snippet credhub-interpolate end
+
+
+
diff --git a/tasks/_delete-certificate-authority-script.html.md.erb b/tasks/_delete-certificate-authority-script.html.md.erb
new file mode 100644
index 00000000..7d34573f
--- /dev/null
+++ b/tasks/_delete-certificate-authority-script.html.md.erb
@@ -0,0 +1,8 @@
+
+
+cat /var/version && echo ""
+set -eux
+
+om --env env/"${ENV_FILE}" delete-certificate-authority --all-inactive
+
+
diff --git a/tasks/_delete-certificate-authority.html.md.erb b/tasks/_delete-certificate-authority.html.md.erb
new file mode 100644
index 00000000..7a5ca294
--- /dev/null
+++ b/tasks/_delete-certificate-authority.html.md.erb
@@ -0,0 +1,19 @@
+
+
+---
+platform: linux
+
+inputs:
+- name: platform-automation-tasks
+- name: env # contains the env file with target OpsMan Information
+
+params:
+ ENV_FILE: env.yml
+ # - Required
+ # - Filepath of the env config YAML
+
+run:
+ path: platform-automation-tasks/tasks/delete-certificate-authority.sh
+
+
+
diff --git a/tasks/_delete-installation-script.html.md.erb b/tasks/_delete-installation-script.html.md.erb
new file mode 100644
index 00000000..835eb735
--- /dev/null
+++ b/tasks/_delete-installation-script.html.md.erb
@@ -0,0 +1,7 @@
+
+
+cat /var/version && echo ""
+set -eux
+om --env env/"${ENV_FILE}" delete-installation --force
+
+
diff --git a/tasks/delete-installation.yml b/tasks/_delete-installation.html.md.erb
similarity index 50%
rename from tasks/delete-installation.yml
rename to tasks/_delete-installation.html.md.erb
index 48b11a94..95a68e4e 100644
--- a/tasks/delete-installation.yml
+++ b/tasks/_delete-installation.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet delete-installation start yaml
+
+
---
platform: linux
@@ -19,4 +15,6 @@ params:
run:
path: platform-automation-tasks/tasks/delete-installation.sh
-# code_snippet delete-installation end
+
+
+
diff --git a/tasks/delete-vm.sh b/tasks/_delete-vm-script.html.md.erb
old mode 100755
new mode 100644
similarity index 92%
rename from tasks/delete-vm.sh
rename to tasks/_delete-vm-script.html.md.erb
index 6671bed7..72afad1e
--- a/tasks/delete-vm.sh
+++ b/tasks/_delete-vm-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet delete-vm-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -31,5 +30,5 @@ om vm-lifecycle delete-vm \
# input_state_file need to be globbed (SC2086)
# shellcheck disable=SC2086
cp state/${input_state_file} "generated-state/${generated_state_file_name}"
-
-# code_snippet delete-vm-script end
+
+
diff --git a/tasks/delete-vm.yml b/tasks/_delete-vm.html.md.erb
similarity index 76%
rename from tasks/delete-vm.yml
rename to tasks/_delete-vm.html.md.erb
index 173bc273..03a54ae2 100644
--- a/tasks/delete-vm.yml
+++ b/tasks/_delete-vm.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet delete-vm start yaml
+
+
---
platform: linux
@@ -24,7 +20,7 @@ outputs:
params:
VARS_FILES:
# - Optional
- # - Filepath to the Ops Manager vars yaml file
+ # - Filepath to the Ops Manager vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
@@ -35,7 +31,7 @@ params:
STATE_FILE: state.yml
# - Required
- # - Filepath of the state yaml file
+ # - Filepath of the state YAML file
# - The path is relative to root of the `state` output
# - if the filename includes "$timestamp",
# for example "state-$timestamp.yml",
@@ -48,4 +44,6 @@ params:
run:
path: platform-automation-tasks/tasks/delete-vm.sh
-# code_snippet delete-vm end
+
+
+
diff --git a/tasks/download-and-upload-product.sh b/tasks/_download-and-upload-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 91%
rename from tasks/download-and-upload-product.sh
rename to tasks/_download-and-upload-product-script.html.md.erb
index e44412e0..e7a7ad4e
--- a/tasks/download-and-upload-product.sh
+++ b/tasks/_download-and-upload-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet download-and-upload-product-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -48,4 +47,5 @@ if [ "${downloaded_stemcell}" != "" ]; then
om --env env/"${ENV_FILE}" upload-stemcell \
--stemcell "${downloaded_stemcell}" "${floatingArg}"
fi
-# code_snippet download-and-upload-product-script end
+
+
diff --git a/tasks/download-and-upload-product.yml b/tasks/_download-and-upload-product.html.md.erb
similarity index 68%
rename from tasks/download-and-upload-product.yml
rename to tasks/_download-and-upload-product.html.md.erb
index 15ed85bd..7b19304d 100644
--- a/tasks/download-and-upload-product.yml
+++ b/tasks/_download-and-upload-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet download-and-upload-product start yaml
+
+
---
platform: linux
@@ -25,12 +21,12 @@ params:
CONFIG_FILE: download-config.yml
# - Required
- # - Filepath to the product configuration yaml file
+ # - Filepath to the product configuration YAML file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
- # - Filepath to the product configuration vars yaml file
+ # - Filepath to the product configuration vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
@@ -41,4 +37,6 @@ params:
run:
path: platform-automation-tasks/tasks/download-and-upload-product.sh
-# code_snippet download-and-upload-product end
+
+
+
diff --git a/tasks/download-product.sh b/tasks/_download-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 92%
rename from tasks/download-product.sh
rename to tasks/_download-product-script.html.md.erb
index 02a9cbb6..071e1c0e
--- a/tasks/download-product.sh
+++ b/tasks/_download-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet download-product-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -49,4 +48,5 @@ if [ -e downloaded-product/assign-stemcell.yml ]; then
fi
rm -f downloaded-product/download-file.json
-# code_snippet download-product-script end
+
+
diff --git a/tasks/download-product.yml b/tasks/_download-product.html.md.erb
similarity index 67%
rename from tasks/download-product.yml
rename to tasks/_download-product.html.md.erb
index 24e40c81..27cd64b5 100644
--- a/tasks/download-product.yml
+++ b/tasks/_download-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet download-product start yaml
+
+
---
platform: linux
@@ -29,12 +25,12 @@ caches:
params:
CONFIG_FILE: download-config.yml
# - Required
- # - Filepath to the product configuration yaml file
+ # - Filepath to the product configuration YAML file
# - The path is relative to the root of the `config` input
VARS_FILES:
# - Optional
- # - Filepath to the product configuration vars yaml file
+ # - Filepath to the product configuration vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
@@ -45,4 +41,6 @@ params:
run:
path: platform-automation-tasks/tasks/download-product.sh
-# code_snippet download-product end
+
+
+
diff --git a/tasks/expiring-certificates.sh b/tasks/_expiring-certificates-script.html.md.erb
old mode 100755
new mode 100644
similarity index 64%
rename from tasks/expiring-certificates.sh
rename to tasks/_expiring-certificates-script.html.md.erb
index 9e1440de..18cea390
--- a/tasks/expiring-certificates.sh
+++ b/tasks/_expiring-certificates-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet expiring-certificates-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -11,4 +10,6 @@ fi
om --env env/"${ENV_FILE}" expiring-certificates \
--expires-within "${EXPIRES_WITHIN}"
-# code_snippet expiring-certificates-script end
+
+
+
diff --git a/tasks/expiring-certificates.yml b/tasks/_expiring-certificates.html.md.erb
similarity index 62%
rename from tasks/expiring-certificates.yml
rename to tasks/_expiring-certificates.html.md.erb
index 62cae820..8ebc8b17 100644
--- a/tasks/expiring-certificates.yml
+++ b/tasks/_expiring-certificates.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet expiring-certificates start yaml
+
+
---
platform: linux
@@ -26,4 +22,6 @@ params:
run:
path: platform-automation-tasks/tasks/expiring-certificates.sh
-# code_snippet expiring-certificates end
\ No newline at end of file
+
+
+
\ No newline at end of file
diff --git a/tasks/export-installation.sh b/tasks/_export-installation-script.html.md.erb
old mode 100755
new mode 100644
similarity index 78%
rename from tasks/export-installation.sh
rename to tasks/_export-installation-script.html.md.erb
index a4c3b2b6..468d41d2
--- a/tasks/export-installation.sh
+++ b/tasks/_export-installation-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet export-installation-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -14,4 +13,6 @@ output_file_name="$(echo "${INSTALLATION_FILE}" | envsubst '$timestamp')"
om --env env/"${ENV_FILE}" export-installation \
--output-file installation/"${output_file_name}"
-# code_snippet export-installation-script end
+
+
+
diff --git a/tasks/export-installation.yml b/tasks/_export-installation.html.md.erb
similarity index 75%
rename from tasks/export-installation.yml
rename to tasks/_export-installation.html.md.erb
index 1fa86209..b717ae85 100644
--- a/tasks/export-installation.yml
+++ b/tasks/_export-installation.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet export-installation start yaml
+
+
---
platform: linux
@@ -35,4 +31,6 @@ params:
run:
path: platform-automation-tasks/tasks/export-installation.sh
-# code_snippet export-installation end
\ No newline at end of file
+
+
+
diff --git a/tasks/generate-certificate.sh b/tasks/_generate-certificate-script.html.md.erb
old mode 100755
new mode 100644
similarity index 70%
rename from tasks/generate-certificate.sh
rename to tasks/_generate-certificate-script.html.md.erb
index 7c4d7796..04121560
--- a/tasks/generate-certificate.sh
+++ b/tasks/_generate-certificate-script.html.md.erb
@@ -1,10 +1,10 @@
-#!/usr/bin/env bash
-# code_snippet generate-certificate-script start bash
-
+
+
cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" generate-certificate -d "${DOMAINS}" > /tmp/certificate.json
om interpolate -c /tmp/certificate.json --path /certificate > certificate/certificate.pem
om interpolate -c /tmp/certificate.json --path /key > certificate/privatekey.pem
-# code_snippet generate-certificate-script end
+
+
diff --git a/tasks/generate-certificate.yml b/tasks/_generate-certificate.html.md.erb
similarity index 60%
rename from tasks/generate-certificate.yml
rename to tasks/_generate-certificate.html.md.erb
index d91e209e..12aff170 100644
--- a/tasks/generate-certificate.yml
+++ b/tasks/_generate-certificate.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet generate-certificate start yaml
+
+
---
platform: linux
@@ -26,4 +22,6 @@ params:
run:
path: platform-automation-tasks/tasks/generate-certificate.sh
-# code_snippet generate-certificate end
\ No newline at end of file
+
+
+
diff --git a/tasks/import-installation.sh b/tasks/_import-installation-script.html.md.erb
old mode 100755
new mode 100644
similarity index 65%
rename from tasks/import-installation.sh
rename to tasks/_import-installation-script.html.md.erb
index eb8d3cc3..6db21167
--- a/tasks/import-installation.sh
+++ b/tasks/_import-installation-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet import-installation-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -8,4 +7,6 @@ set -eux
# shellcheck disable=SC2086
om --env env/"${ENV_FILE}" --skip-ssl-validation import-installation \
--installation installation/${INSTALLATION_FILE}
-# code_snippet import-installation-script end
+
+
+
diff --git a/tasks/import-installation.yml b/tasks/_import-installation.html.md.erb
similarity index 69%
rename from tasks/import-installation.yml
rename to tasks/_import-installation.html.md.erb
index 47b88a1c..a45f3ed0 100644
--- a/tasks/import-installation.yml
+++ b/tasks/_import-installation.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet import-installation start yaml
+
+
---
platform: linux
@@ -28,4 +24,6 @@ params:
run:
path: platform-automation-tasks/tasks/import-installation.sh
-# code_snippet import-installation end
\ No newline at end of file
+
+
+
diff --git a/tasks/make-git-commit.sh b/tasks/_make-git-commit-script.html.md.erb
old mode 100755
new mode 100644
similarity index 85%
rename from tasks/make-git-commit.sh
rename to tasks/_make-git-commit-script.html.md.erb
index 5f56f6b6..6aa0319b
--- a/tasks/make-git-commit.sh
+++ b/tasks/_make-git-commit-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet make-git-commit-script start bash
-
+
+
cat /var/version && echo ""
set -eu
@@ -23,4 +22,5 @@ if [[ -n $(git status --porcelain) ]]; then
git add -A
git commit -m "${COMMIT_MESSAGE}" --allow-empty
fi
-# code_snippet make-git-commit-script end
+
+
diff --git a/tasks/make-git-commit.yml b/tasks/_make-git-commit.html.md.erb
similarity index 79%
rename from tasks/make-git-commit.yml
rename to tasks/_make-git-commit.html.md.erb
index cf76195a..acf3ebd4 100644
--- a/tasks/make-git-commit.yml
+++ b/tasks/_make-git-commit.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet make-git-commit start yaml
+
+
---
platform: linux
@@ -51,4 +47,6 @@ params:
run:
path: platform-automation-tasks/tasks/make-git-commit.sh
-# code_snippet make-git-commit end
+
+
+
diff --git a/tasks/_pre-deploy-check-script.html.md.erb b/tasks/_pre-deploy-check-script.html.md.erb
new file mode 100644
index 00000000..cd007485
--- /dev/null
+++ b/tasks/_pre-deploy-check-script.html.md.erb
@@ -0,0 +1,8 @@
+
+
+cat /var/version && echo ""
+set -eux
+
+om --env env/"${ENV_FILE}" pre-deploy-check
+
+
diff --git a/tasks/pre-deploy-check.yml b/tasks/_pre-deploy-check.html.md.erb
similarity index 50%
rename from tasks/pre-deploy-check.yml
rename to tasks/_pre-deploy-check.html.md.erb
index dbdbb375..0e373ef6 100644
--- a/tasks/pre-deploy-check.yml
+++ b/tasks/_pre-deploy-check.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet pre-deploy-check start yaml
+
+
---
platform: linux
@@ -19,4 +15,6 @@ params:
run:
path: platform-automation-tasks/tasks/pre-deploy-check.sh
-# code_snippet pre-deploy-check end
+
+
+
diff --git a/tasks/prepare-image.sh b/tasks/_prepare-image-script.html.md.erb
old mode 100755
new mode 100644
similarity index 88%
rename from tasks/prepare-image.sh
rename to tasks/_prepare-image-script.html.md.erb
index c7f93f6d..a13c532f
--- a/tasks/prepare-image.sh
+++ b/tasks/_prepare-image-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet prepare-image-script start bash
-
+
+
cat /var/version && echo ""
set -eu
@@ -27,5 +26,5 @@ update-ca-certificates
rsync -al /etc/ssl/certs/ "${PWD}"/platform-automation-image/rootfs/etc/ssl/certs
rsync -al /usr/local/share/ca-certificates/ "${PWD}"/platform-automation-image/rootfs/usr/local/share/ca-certificates
rsync -al /usr/share/ca-certificates/ "${PWD}"/platform-automation-image/rootfs/usr/share/ca-certificates
-
-# code_snippet prepare-image-script end
+
+
diff --git a/tasks/prepare-image.yml b/tasks/_prepare-image.html.md.erb
similarity index 65%
rename from tasks/prepare-image.yml
rename to tasks/_prepare-image.html.md.erb
index af3acf70..7f25bfc3 100644
--- a/tasks/prepare-image.yml
+++ b/tasks/_prepare-image.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet prepare-image start yaml
+
+
---
platform: linux
@@ -30,4 +26,6 @@ params:
run:
path: platform-automation-tasks/tasks/prepare-image.sh
-# code_snippet prepare-image end
+
+
+
diff --git a/tasks/prepare-tasks-with-secrets.sh b/tasks/_prepare-tasks-with-secrets-script.html.md.erb
old mode 100755
new mode 100644
similarity index 81%
rename from tasks/prepare-tasks-with-secrets.sh
rename to tasks/_prepare-tasks-with-secrets-script.html.md.erb
index 1310d393..cf47f58c
--- a/tasks/prepare-tasks-with-secrets.sh
+++ b/tasks/_prepare-tasks-with-secrets-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet prepare-tasks-with-secrets-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -26,4 +25,5 @@ om vm-lifecycle prepare-tasks-with-secrets \
${config_file_args[@]} \
${vars_file_args[@]}
-# code_snippet prepare-tasks-with-secrets-script end
+
+
diff --git a/tasks/prepare-tasks-with-secrets.yml b/tasks/_prepare-tasks-with-secrets.html.md.erb
similarity index 82%
rename from tasks/prepare-tasks-with-secrets.yml
rename to tasks/_prepare-tasks-with-secrets.html.md.erb
index f649ba26..e20762cd 100644
--- a/tasks/prepare-tasks-with-secrets.yml
+++ b/tasks/_prepare-tasks-with-secrets.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet prepare-tasks-with-secrets start yaml
+
+
---
platform: linux
@@ -53,4 +49,6 @@ params:
run:
path: platform-automation-tasks/tasks/prepare-tasks-with-secrets.sh
-# code_snippet prepare-tasks-with-secrets end
+
+
+
diff --git a/tasks/_regenerate-certificates-script.html.md.erb b/tasks/_regenerate-certificates-script.html.md.erb
new file mode 100644
index 00000000..d566f342
--- /dev/null
+++ b/tasks/_regenerate-certificates-script.html.md.erb
@@ -0,0 +1,8 @@
+
+
+cat /var/version && echo ""
+set -eux
+
+om --env env/"${ENV_FILE}" regenerate-certificates
+
+
diff --git a/tasks/_regenerate-certificates.html.md.erb b/tasks/_regenerate-certificates.html.md.erb
new file mode 100644
index 00000000..c53bca59
--- /dev/null
+++ b/tasks/_regenerate-certificates.html.md.erb
@@ -0,0 +1,20 @@
+
+
+---
+platform: linux
+
+inputs:
+- name: platform-automation-tasks
+- name: env # contains the env file with target OpsMan Information
+
+params:
+ ENV_FILE: env.yml
+ # - Required
+ # - Filepath of the env config YAML
+ # - The path is relative to root of the `env` input
+
+run:
+ path: platform-automation-tasks/tasks/regenerate-certificates.sh
+
+
+
\ No newline at end of file
diff --git a/tasks/replicate-product.sh b/tasks/_replicate-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 68%
rename from tasks/replicate-product.sh
rename to tasks/_replicate-product-script.html.md.erb
index 20d35b1f..cd9259b3
--- a/tasks/replicate-product.sh
+++ b/tasks/_replicate-product-script.html.md.erb
@@ -1,5 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet replicate-product-script start bash
+
+
cat /var/version && echo ""
set -eux
@@ -11,4 +11,6 @@ fi
iso-replicator -name "${REPLICATED_NAME}" \
-output "replicated-product/${REPLICATED_NAME}.pivotal" \
-path product/*.pivotal
-# code_snippet replicate-product-script end bash
+
+
+
diff --git a/tasks/replicate-product.yml b/tasks/_replicate-product.html.md.erb
similarity index 56%
rename from tasks/replicate-product.yml
rename to tasks/_replicate-product.html.md.erb
index 62e7cb60..6cf4d110 100644
--- a/tasks/replicate-product.yml
+++ b/tasks/_replicate-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet replicate-product start yaml
+
+
---
platform: linux
@@ -23,4 +19,6 @@ params:
run:
path: platform-automation-tasks/tasks/replicate-product.sh
-# code_snippet replicate-product end
+
+
+
diff --git a/tasks/_revert-staged-changes-script.html.md.erb b/tasks/_revert-staged-changes-script.html.md.erb
new file mode 100644
index 00000000..f05218d0
--- /dev/null
+++ b/tasks/_revert-staged-changes-script.html.md.erb
@@ -0,0 +1,8 @@
+
+
+cat /var/version && echo ""
+set -eux
+
+om --env env/"${ENV_FILE}" revert-staged-changes
+
+
diff --git a/tasks/_revert-staged-changes.html.md.erb b/tasks/_revert-staged-changes.html.md.erb
new file mode 100644
index 00000000..4f6a317b
--- /dev/null
+++ b/tasks/_revert-staged-changes.html.md.erb
@@ -0,0 +1,20 @@
+
+
+---
+platform: linux
+
+inputs:
+- name: platform-automation-tasks
+- name: env # contains the env file with target OpsMan Information
+
+params:
+ ENV_FILE: env.yml
+ # - Required
+ # - Filepath of the env config YAML
+ # - The path is relative to root of the `env` input
+
+run:
+ path: platform-automation-tasks/tasks/revert-staged-changes.sh
+
+
+
diff --git a/tasks/run-bosh-errand.sh b/tasks/_run-bosh-errand-script.html.md.erb
old mode 100755
new mode 100644
similarity index 88%
rename from tasks/run-bosh-errand.sh
rename to tasks/_run-bosh-errand-script.html.md.erb
index 6a9fabcf..f33efe2c
--- a/tasks/run-bosh-errand.sh
+++ b/tasks/_run-bosh-errand-script.html.md.erb
@@ -1,5 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet run-bosh-errand-script start bash
+
+
cat /var/version && echo ""
set -eux
@@ -24,4 +24,5 @@ if [ -z "${INSTANCE}" ]; then
else
bosh -d "${installation}" run-errand "${ERRAND_NAME}" --instance "${INSTANCE}"
fi
-# code_snippet run-bosh-errand-script end
+
+
diff --git a/tasks/run-bosh-errand.yml b/tasks/_run-bosh-errand.html.md.erb
similarity index 80%
rename from tasks/run-bosh-errand.yml
rename to tasks/_run-bosh-errand.html.md.erb
index d1d881f1..465feb69 100644
--- a/tasks/run-bosh-errand.yml
+++ b/tasks/_run-bosh-errand.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet run-bosh-errand start yaml
+
+
---
platform: linux
@@ -32,7 +28,7 @@ params:
# - Optional
# - May be required to communicate with the Ops Manager BOSH director
# if your Concourse worker doesn't otherwise have a route
- # to your bosh director.
+ # to your BOSH Director.
# - This is the private key for the Ops Manager VM
# (used during VM creation)
@@ -54,4 +50,6 @@ params:
run:
path: platform-automation-tasks/tasks/run-bosh-errand.sh
-# code_snippet run-bosh-errand end
+
+
+
diff --git a/tasks/send-telemetry.sh b/tasks/_send-telemetry-script.html.md.erb
old mode 100755
new mode 100644
similarity index 71%
rename from tasks/send-telemetry.sh
rename to tasks/_send-telemetry-script.html.md.erb
index de62ca25..f4fb142c
--- a/tasks/send-telemetry.sh
+++ b/tasks/_send-telemetry-script.html.md.erb
@@ -1,5 +1,5 @@
-#!/bin/bash
-# code_snippet send-telemetry-script start bash
+
+
set -eux
./telemetry-collector-binary/telemetry-collector-linux-amd64 --version
@@ -8,4 +8,6 @@ set -eux
# shellcheck disable=SC2086
./telemetry-collector-binary/telemetry-collector-linux-amd64 send \
--path ${DATA_FILE_PATH}
-# code_snippet send-telemetry-script end
+
+
+
diff --git a/tasks/_send-telemetry.html.md.erb b/tasks/_send-telemetry.html.md.erb
new file mode 100644
index 00000000..39b10d3a
--- /dev/null
+++ b/tasks/_send-telemetry.html.md.erb
@@ -0,0 +1,23 @@
+
+
+---
+platform: linux
+
+inputs:
+- name: platform-automation-tasks
+- name: telemetry-collector-binary
+- name: collected-telemetry-data
+
+params:
+ API_KEY:
+ # required
+ # The API key provided by Pivotal after accepting the EULA
+
+ DATA_FILE_PATH:
+ # required
+
+run:
+ path: platform-automation-tasks/tasks/send-telemetry.sh
+
+
+
diff --git a/tasks/setup-bosh-env.sh b/tasks/_setup-bosh-env-script.html.md.erb
old mode 100755
new mode 100644
similarity index 96%
rename from tasks/setup-bosh-env.sh
rename to tasks/_setup-bosh-env-script.html.md.erb
index 7c5bed8f..236832a9
--- a/tasks/setup-bosh-env.sh
+++ b/tasks/_setup-bosh-env-script.html.md.erb
@@ -1,3 +1,5 @@
+
+
set +x
if [ -n "${OPSMAN_SSH_PRIVATE_KEY}" ]; then
eval "$(om --env env/"${ENV_FILE}" bosh-env)"
@@ -26,3 +28,5 @@ if [ -n "${OPSMAN_SSH_PRIVATE_KEY}" ]; then
else
eval "$(om --env env/"${ENV_FILE}" bosh-env)"
fi
+
+
diff --git a/tasks/stage-configure-apply.sh b/tasks/_stage-configure-apply-script.html.md.erb
old mode 100755
new mode 100644
similarity index 94%
rename from tasks/stage-configure-apply.sh
rename to tasks/_stage-configure-apply-script.html.md.erb
index 1bf7437c..063f1a5a
--- a/tasks/stage-configure-apply.sh
+++ b/tasks/_stage-configure-apply-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet stage-configure-apply-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -77,4 +76,6 @@ om --env env/"${ENV_FILE}" \
apply-changes \
--product-name "${product_name}" \
${flags[@]}
-# code_snippet stage-configure-apply-script end
+
+
+
diff --git a/tasks/stage-configure-apply.yml b/tasks/_stage-configure-apply.html.md.erb
similarity index 82%
rename from tasks/stage-configure-apply.yml
rename to tasks/_stage-configure-apply.html.md.erb
index b8185342..20455c60 100644
--- a/tasks/stage-configure-apply.yml
+++ b/tasks/_stage-configure-apply.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet stage-configure-apply start yaml
+
+
---
platform: linux
@@ -24,7 +20,7 @@ inputs:
- name: stemcell # contains the stemcell tarball
optional: true
# - The stemcell filename is important and must be preserved.
- # if using the bosh.io concourse resource,
+ # if using the bosh.io Concourse resource,
# set `params.preserve_filename: true` on your GET.
- name: assign-stemcell-config # contains the configuration file for assign-stemcell command
optional: true
@@ -37,7 +33,7 @@ inputs:
params:
CONFIG_FILE:
# - Required
- # - Filepath to the product configuration yaml file
+ # - Filepath to the product configuration YAML file
# - The path is relative to the root of the `config` input
STAGE_PRODUCT_CONFIG_FILE:
@@ -73,13 +69,13 @@ params:
VARS_FILES:
# - Optional
- # - Filepath to the product configuration vars yaml file
+ # - Filepath to the product configuration vars YAML file
# - The path is relative to root of the task build,
# so `vars` and `secrets` can be used.
OPS_FILES:
# - Optional
- # - Filepath to the product configuration operations yaml files
+ # - Filepath to the product configuration operations YAML files
# - The path is relative to root of the task build
ENV_FILE: env.yml
@@ -93,8 +89,8 @@ params:
RECREATE: false
# - Optional
- # - If true, will recreate the vms for the product
- # - If true, will also recreate the director vm if there are changes
+ # - If true, will recreate the VMs for the product
+ # - If true, will also recreate the director VM if there are changes
ERRAND_CONFIG_FILE:
# - Optional
@@ -112,4 +108,6 @@ params:
run:
path: platform-automation-tasks/tasks/stage-configure-apply.sh
-# code_snippet stage-configure-apply end
+
+
+
diff --git a/tasks/stage-product.sh b/tasks/_stage-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 92%
rename from tasks/stage-product.sh
rename to tasks/_stage-product-script.html.md.erb
index 13dd1f4d..525a58bd
--- a/tasks/stage-product.sh
+++ b/tasks/_stage-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet stage-product-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -34,5 +33,5 @@ else
om --env env/"${ENV_FILE}" stage-product \
--config config/"${CONFIG_FILE}"
fi
-
-# code_snippet stage-product-script end
+
+
diff --git a/tasks/stage-product.yml b/tasks/_stage-product.html.md.erb
similarity index 70%
rename from tasks/stage-product.yml
rename to tasks/_stage-product.html.md.erb
index 1660ac79..1e96a696 100644
--- a/tasks/stage-product.yml
+++ b/tasks/_stage-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet stage-product start yaml
+
+
---
platform: linux
@@ -33,4 +29,6 @@ params:
run:
path: platform-automation-tasks/tasks/stage-product.sh
-# code_snippet stage-product end
+
+
+
diff --git a/tasks/staged-config.sh b/tasks/_staged-config-script.html.md.erb
old mode 100755
new mode 100644
similarity index 74%
rename from tasks/staged-config.sh
rename to tasks/_staged-config-script.html.md.erb
index 514c64f9..1bdca802
--- a/tasks/staged-config.sh
+++ b/tasks/_staged-config-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet staged-config-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -15,4 +14,6 @@ flag=$(
om --env env/"${ENV_FILE}" staged-config \
--product-name "${PRODUCT_NAME}" \
"${flag}" >generated-config/"${PRODUCT_NAME}".yml
-# code_snippet staged-config-script end
+
+
+
diff --git a/tasks/staged-config.yml b/tasks/_staged-config.html.md.erb
similarity index 68%
rename from tasks/staged-config.yml
rename to tasks/_staged-config.html.md.erb
index 37edd19e..40a53d5d 100644
--- a/tasks/staged-config.yml
+++ b/tasks/_staged-config.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet staged-config start yaml
+
+
---
platform: linux
@@ -31,4 +27,6 @@ params:
run:
path: platform-automation-tasks/tasks/staged-config.sh
-# code_snippet staged-config end
+
+
+
diff --git a/tasks/staged-director-config.sh b/tasks/_staged-director-config-script.html.md.erb
old mode 100755
new mode 100644
similarity index 53%
rename from tasks/staged-director-config.sh
rename to tasks/_staged-director-config-script.html.md.erb
index 59101744..84f48e22
--- a/tasks/staged-director-config.sh
+++ b/tasks/_staged-director-config-script.html.md.erb
@@ -1,8 +1,9 @@
-#!/usr/bin/env bash
-# code_snippet staged-director-config-script start bash
-
+
+
cat /var/version && echo ""
set -eux
om --env env/"${ENV_FILE}" staged-director-config \
--include-placeholders >generated-config/director.yml
-# code_snippet staged-director-config-script end
+
+
+
diff --git a/tasks/staged-director-config.yml b/tasks/_staged-director-config.html.md.erb
similarity index 54%
rename from tasks/staged-director-config.yml
rename to tasks/_staged-director-config.html.md.erb
index 937cfc25..1f0163dd 100644
--- a/tasks/staged-director-config.yml
+++ b/tasks/_staged-director-config.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet staged-director-config start yaml
+
+
---
platform: linux
@@ -22,4 +18,6 @@ params:
run:
path: platform-automation-tasks/tasks/staged-director-config.sh
-# code_snippet staged-director-config end
+
+
+
diff --git a/tasks/test-interpolate.sh b/tasks/_test-interpolate-script.html.md.erb
old mode 100755
new mode 100644
similarity index 77%
rename from tasks/test-interpolate.sh
rename to tasks/_test-interpolate-script.html.md.erb
index cc609900..897b5815
--- a/tasks/test-interpolate.sh
+++ b/tasks/_test-interpolate-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet test-interpolate-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -17,4 +16,5 @@ fi
# ${vars_files_args[@] needs to be globbed to pass through properly
# shellcheck disable=SC2068
om interpolate --config "config/${CONFIG_FILE}" ${flags[@]}
-# code_snippet test-interpolate-script end
+
+
diff --git a/tasks/test-interpolate.yml b/tasks/_test-interpolate.html.md.erb
similarity index 59%
rename from tasks/test-interpolate.yml
rename to tasks/_test-interpolate.html.md.erb
index 02acf673..1bdc9458 100644
--- a/tasks/test-interpolate.yml
+++ b/tasks/_test-interpolate.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet test-interpolate start yaml
+
+
---
platform: linux
@@ -16,13 +12,13 @@ inputs:
params:
VARS_FILES:
# - Optional
- # - Filepath to the vars yaml file
+ # - Filepath to the vars YAML file
# - The path is relative to root of the task build
# - These vars can come from the `vars` or `config` inputs
CONFIG_FILE: base.yml
# - Required
- # - Filepath to the base yaml file to interpolate from
+ # - Filepath to the base YAML file to interpolate from
# - The path is relative to root of the task build
SKIP_MISSING: true
@@ -32,4 +28,6 @@ params:
run:
path: platform-automation-tasks/tasks/test-interpolate.sh
-# code_snippet test-interpolate end
+
+
+
diff --git a/tasks/_test-script.html.md.erb b/tasks/_test-script.html.md.erb
new file mode 100644
index 00000000..3b7a2dd7
--- /dev/null
+++ b/tasks/_test-script.html.md.erb
@@ -0,0 +1,14 @@
+
+
+echo "Platform Automation for PCF version:"
+cat /var/version && echo ""
+
+printf "\\nom version:"
+om -v
+
+set -eux
+om vm-lifecycle --help
+om --help
+{ echo "Successfully validated tasks and image!"; } 2>/dev/null
+
+
diff --git a/tasks/_test.html.md.erb b/tasks/_test.html.md.erb
new file mode 100644
index 00000000..e6513aa3
--- /dev/null
+++ b/tasks/_test.html.md.erb
@@ -0,0 +1,13 @@
+
+
+---
+platform: linux
+
+inputs:
+- name: platform-automation-tasks
+
+run:
+ path: platform-automation-tasks/tasks/test.sh
+
+
+
diff --git a/tasks/update-runtime-config.sh b/tasks/_update-runtime-config-script.html.md.erb
old mode 100755
new mode 100644
similarity index 87%
rename from tasks/update-runtime-config.sh
rename to tasks/_update-runtime-config-script.html.md.erb
index 2feae1f4..9f5ee4a8
--- a/tasks/update-runtime-config.sh
+++ b/tasks/_update-runtime-config-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet update-runtime-config-script start bash
-
+
+
cat /var/version && echo ""
set -eu
@@ -37,4 +36,5 @@ bosh -n update-config \
config/"${CONFIG_FILE}" \
${vars_files_args[@]}
-# code_snippet update-runtime-config-script end
+
+
diff --git a/tasks/update-runtime-config.yml b/tasks/_update-runtime-config.html.md.erb
similarity index 79%
rename from tasks/update-runtime-config.yml
rename to tasks/_update-runtime-config.html.md.erb
index ad462aed..324a94f1 100644
--- a/tasks/update-runtime-config.yml
+++ b/tasks/_update-runtime-config.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet update-runtime-config start yaml
+
+
---
platform: linux
@@ -50,9 +46,11 @@ params:
VARS_FILES:
# - Optional
- # - Filepaths of the product configuration vars yaml file
+ # - Filepaths of the product configuration vars YAML file
# - The path is relative to the root of the task build,
# so `vars` can be used.
run:
path: platform-automation-tasks/tasks/update-runtime-config.sh
-# code_snippet update-runtime-config end
+
+
+
diff --git a/tasks/upgrade-opsman.sh b/tasks/_upgrade-opsman-script.html.erb
old mode 100755
new mode 100644
similarity index 94%
rename from tasks/upgrade-opsman.sh
rename to tasks/_upgrade-opsman-script.html.erb
index 7e8265d5..11b51ad0
--- a/tasks/upgrade-opsman.sh
+++ b/tasks/_upgrade-opsman-script.html.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet upgrade-opsman-script start bash
-
+
+
cat /var/version && echo ""
om -v
set -eux
@@ -52,4 +51,5 @@ om --env env/"${ENV_FILE}" configure-opsman \
--config "config/${OPSMAN_CONFIG_FILE}" \
${vars_files_args[@]}
-# code_snippet upgrade-opsman-script end
+
+
diff --git a/tasks/upgrade-opsman.yml b/tasks/_upgrade-opsman.html.md.erb
similarity index 84%
rename from tasks/upgrade-opsman.yml
rename to tasks/_upgrade-opsman.html.md.erb
index e31aded2..45671ece 100644
--- a/tasks/upgrade-opsman.yml
+++ b/tasks/_upgrade-opsman.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet upgrade-opsman start yaml
+
+
---
platform: linux
@@ -46,7 +42,7 @@ params:
STATE_FILE: state.yml
# - Required
- # - Filepath of the state yaml file
+ # - Filepath of the state YAML file
# - The path is relative to root of the `state` output
# - if the filename includes "$timestamp",
# for example "state-$timestamp.yml",
@@ -65,4 +61,6 @@ params:
run:
path: platform-automation-tasks/tasks/upgrade-opsman.sh
-# code_snippet upgrade-opsman end
+
+
+
diff --git a/tasks/upload-and-stage-product.sh b/tasks/_upload-and-stage-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 81%
rename from tasks/upload-and-stage-product.sh
rename to tasks/_upload-and-stage-product-script.html.md.erb
index 7429b7b1..08128950
--- a/tasks/upload-and-stage-product.sh
+++ b/tasks/_upload-and-stage-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet upload-and-stage-product-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -22,4 +21,6 @@ product_version="$(om product-metadata \
om --env env/"${ENV_FILE}" stage-product \
--product-name "${product_name}" \
--product-version "${product_version}"
-# code_snippet upload-and-stage-product-script end
+
+
+
diff --git a/tasks/upload-and-stage-product.yml b/tasks/_upload-and-stage-product.html.md.erb
similarity index 70%
rename from tasks/upload-and-stage-product.yml
rename to tasks/_upload-and-stage-product.html.md.erb
index 7b3cc7bd..07a05680 100644
--- a/tasks/upload-and-stage-product.yml
+++ b/tasks/_upload-and-stage-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet upload-and-stage-product start yaml
+
+
---
platform: linux
@@ -32,4 +28,6 @@ params:
run:
path: platform-automation-tasks/tasks/upload-and-stage-product.sh
-# code_snippet upload-and-stage-product end
+
+
+
diff --git a/tasks/upload-product.sh b/tasks/_upload-product-script.html.md.erb
old mode 100755
new mode 100644
similarity index 73%
rename from tasks/upload-product.sh
rename to tasks/_upload-product-script.html.md.erb
index c369dd03..ae75b0f7
--- a/tasks/upload-product.sh
+++ b/tasks/_upload-product-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet upload-product-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -12,4 +11,6 @@ fi
om --env env/"${ENV_FILE}" upload-product \
--product product/*.pivotal \
${OPTIONAL_CONFIG_FLAG}
-# code_snippet upload-product-script end
+
+
+
diff --git a/tasks/upload-product.yml b/tasks/_upload-product.html.md.erb
similarity index 71%
rename from tasks/upload-product.yml
rename to tasks/_upload-product.html.md.erb
index def27f23..bbfe16d3 100644
--- a/tasks/upload-product.yml
+++ b/tasks/_upload-product.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet upload-product start yaml
+
+
---
platform: linux
@@ -31,4 +27,6 @@ params:
run:
path: platform-automation-tasks/tasks/upload-product.sh
-# code_snippet upload-product end
+
+
+
diff --git a/tasks/upload-stemcell.sh b/tasks/_upload-stemcell-script.html.md.erb
old mode 100755
new mode 100644
similarity index 75%
rename from tasks/upload-stemcell.sh
rename to tasks/_upload-stemcell-script.html.md.erb
index 705aa9e9..6a0aa6aa
--- a/tasks/upload-stemcell.sh
+++ b/tasks/_upload-stemcell-script.html.md.erb
@@ -1,6 +1,5 @@
-#!/usr/bin/env bash
-# code_snippet upload-stemcell-script start bash
-
+
+
cat /var/version && echo ""
set -eux
@@ -13,4 +12,6 @@ om --env env/"${ENV_FILE}" upload-stemcell \
--floating="${FLOATING_STEMCELL}" \
--stemcell "${PWD}"/stemcell/*.tgz \
${OPTIONAL_CONFIG_FLAG}
-# code_snippet upload-stemcell-script end
+
+
+
diff --git a/tasks/upload-stemcell.yml b/tasks/_upload-stemcell.html.md.erb
similarity index 72%
rename from tasks/upload-stemcell.yml
rename to tasks/_upload-stemcell.html.md.erb
index d5e2500c..88744c18 100644
--- a/tasks/upload-stemcell.yml
+++ b/tasks/_upload-stemcell.html.md.erb
@@ -1,9 +1,5 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet upload-stemcell start yaml
+
+
---
platform: linux
@@ -12,7 +8,7 @@ inputs:
- name: env # contains the env file with target OpsMan Information
- name: stemcell # contains the stemcell tarball
# - The stemcell filename is important and must be preserved.
-# if using the bosh.io concourse resource,
+# if using the bosh.io oncourse resource,
# set `params.preserve_filename: true` on your GET.
params:
@@ -37,4 +33,6 @@ params:
run:
path: platform-automation-tasks/tasks/upload-stemcell.sh
-# code_snippet upload-stemcell end
+
+
+
diff --git a/tasks/activate-certificate-authority.sh b/tasks/activate-certificate-authority.sh
deleted file mode 100755
index 2ec765e6..00000000
--- a/tasks/activate-certificate-authority.sh
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/usr/bin/env bash
-# code_snippet activate-certificate-authority-script start bash
-
-cat /var/version && echo ""
-set -eux
-
-om --env env/"${ENV_FILE}" activate-certificate-authority
-# code_snippet activate-certificate-authority-script end
diff --git a/tasks/activate-certificate-authority.yml b/tasks/activate-certificate-authority.yml
deleted file mode 100644
index c543da76..00000000
--- a/tasks/activate-certificate-authority.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet activate-certificate-authority start yaml
----
-platform: linux
-
-inputs:
-- name: platform-automation-tasks
-- name: env # contains the env file with target OpsMan Information
-
-params:
- ENV_FILE: env.yml
- # - Required
- # - Filepath of the env config YAML
- # - The path is relative to root of the `env` input
-
-run:
- path: platform-automation-tasks/tasks/activate-certificate-authority.sh
-# code_snippet activate-certificate-authority end
\ No newline at end of file
diff --git a/tasks/delete-certificate-authority.sh b/tasks/delete-certificate-authority.sh
deleted file mode 100755
index e02b0e7b..00000000
--- a/tasks/delete-certificate-authority.sh
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/usr/bin/env bash
-# code_snippet delete-certificate-authority-script start bash
-
-cat /var/version && echo ""
-set -eux
-
-om --env env/"${ENV_FILE}" delete-certificate-authority --all-inactive
-# code_snippet delete-certificate-authority-script end
diff --git a/tasks/delete-certificate-authority.yml b/tasks/delete-certificate-authority.yml
deleted file mode 100644
index ff333c2c..00000000
--- a/tasks/delete-certificate-authority.yml
+++ /dev/null
@@ -1,21 +0,0 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet delete-certificate-authority start yaml
----
-platform: linux
-
-inputs:
-- name: platform-automation-tasks
-- name: env # contains the env file with target OpsMan Information
-
-params:
- ENV_FILE: env.yml
- # - Required
- # - Filepath of the env config YAML
-
-run:
- path: platform-automation-tasks/tasks/delete-certificate-authority.sh
-# code_snippet delete-certificate-authority end
\ No newline at end of file
diff --git a/tasks/delete-installation.sh b/tasks/delete-installation.sh
deleted file mode 100755
index 2caed47d..00000000
--- a/tasks/delete-installation.sh
+++ /dev/null
@@ -1,7 +0,0 @@
-#!/usr/bin/env bash
-# code_snippet delete-installation-script start bash
-
-cat /var/version && echo ""
-set -eux
-om --env env/"${ENV_FILE}" delete-installation --force
-# code_snippet delete-installation-script end
diff --git a/tasks/pre-deploy-check.sh b/tasks/pre-deploy-check.sh
deleted file mode 100755
index d5102386..00000000
--- a/tasks/pre-deploy-check.sh
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/usr/bin/env bash
-# code_snippet pre-deploy-check-script start bash
-
-cat /var/version && echo ""
-set -eux
-
-om --env env/"${ENV_FILE}" pre-deploy-check
-# code_snippet pre-deploy-check-script end
diff --git a/tasks/regenerate-certificates.sh b/tasks/regenerate-certificates.sh
deleted file mode 100755
index 99988ac6..00000000
--- a/tasks/regenerate-certificates.sh
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/usr/bin/env bash
-# code_snippet regenerate-certificates-script start bash
-
-cat /var/version && echo ""
-set -eux
-
-om --env env/"${ENV_FILE}" regenerate-certificates
-# code_snippet regenerate-certificates-script end
diff --git a/tasks/regenerate-certificates.yml b/tasks/regenerate-certificates.yml
deleted file mode 100644
index e7b69377..00000000
--- a/tasks/regenerate-certificates.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet regenerate-certificates start yaml
----
-platform: linux
-
-inputs:
-- name: platform-automation-tasks
-- name: env # contains the env file with target OpsMan Information
-
-params:
- ENV_FILE: env.yml
- # - Required
- # - Filepath of the env config YAML
- # - The path is relative to root of the `env` input
-
-run:
- path: platform-automation-tasks/tasks/regenerate-certificates.sh
-# code_snippet regenerate-certificates end
\ No newline at end of file
diff --git a/tasks/revert-staged-changes.sh b/tasks/revert-staged-changes.sh
deleted file mode 100755
index 9b3b7b75..00000000
--- a/tasks/revert-staged-changes.sh
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/usr/bin/env bash
-# code_snippet revert-staged-changes-script start bash
-
-cat /var/version && echo ""
-set -eux
-
-om --env env/"${ENV_FILE}" revert-staged-changes
-# code_snippet revert-staged-changes-script end
diff --git a/tasks/revert-staged-changes.yml b/tasks/revert-staged-changes.yml
deleted file mode 100644
index 44c9c706..00000000
--- a/tasks/revert-staged-changes.yml
+++ /dev/null
@@ -1,22 +0,0 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet revert-staged-changes start yaml
----
-platform: linux
-
-inputs:
-- name: platform-automation-tasks
-- name: env # contains the env file with target OpsMan Information
-
-params:
- ENV_FILE: env.yml
- # - Required
- # - Filepath of the env config YAML
- # - The path is relative to root of the `env` input
-
-run:
- path: platform-automation-tasks/tasks/revert-staged-changes.sh
-# code_snippet revert-staged-changes end
diff --git a/tasks/send-telemetry.yml b/tasks/send-telemetry.yml
deleted file mode 100644
index 17447501..00000000
--- a/tasks/send-telemetry.yml
+++ /dev/null
@@ -1,25 +0,0 @@
-# The inputs, outputs, params, filename, and filepath
-# of this task file are part of its semantically versioned API.
-# See our documentation for a detailed discussion of our semver API.
-# See www.semver.org for an explanation of semantic versioning.
-
-# code_snippet send-telemetry start yaml
----
-platform: linux
-
-inputs:
-- name: platform-automation-tasks
-- name: telemetry-collector-binary
-- name: collected-telemetry-data
-
-params:
- API_KEY:
- # required
- # The API key provided by Pivotal after accepting the EULA
-
- DATA_FILE_PATH:
- # required
-
-run:
- path: platform-automation-tasks/tasks/send-telemetry.sh
-# code_snippet send-telemetry end
diff --git a/tasks/test.sh b/tasks/test.sh
index 482aa5d9..6b15c2d0 100755
--- a/tasks/test.sh
+++ b/tasks/test.sh
@@ -11,4 +11,4 @@ set -eux
om vm-lifecycle --help
om --help
{ echo "Successfully validated tasks and image!"; } 2>/dev/null
-# code_snippet test-script end
+# code_snippet test-script end
\ No newline at end of file
diff --git a/tasks/test.yml b/tasks/test.yml
index 268803c8..364918f4 100644
--- a/tasks/test.yml
+++ b/tasks/test.yml
@@ -8,8 +8,8 @@
platform: linux
inputs:
-- name: platform-automation-tasks
+ - name: platform-automation-tasks
run:
path: platform-automation-tasks/tasks/test.sh
-# code_snippet test end
+# code_snippet test end
\ No newline at end of file