sample-config.yml

# Copyright (c) 2009-2013 VMware, Inc.
# clouds are configured into stac2 by including a cloud config file in the
# nabv/config/clouds directory. The filename must be {domain}.config.yml
# for instance, if your cloud serves apps at mycloudfoundry.com, the config
# file for that cloud would be: mycloudfoundry.com.config.yml
#
# There are 4 main sections to the cloud config file:
# 1 - the basic addressing settings
# 2 - the optional email settings
# 3 - the default workload and maximum concurrency
# 4 - the list of user accounts
#
# 1) for addressing settings the config needs to supply
# - the short name of the cloud, typically a one word alias like staging, prod, p01, p02, etc. This key is used
#   internally and in the various UIs to remind the user which cloud is being tested
# - the cc_target of the cloud. For classic cloud foundry, apps and system api's live on the same domain.
#   for next generation/v2 cloud foundry, apps are served off of a domain that's different than the api domain.
#   the cc_target is the cloud controller address the cf target command for this cloud
# - the app_domain of the cloud. This is the base domain that apps are served from (see previous).
#
# If we assume a v1 cloud, named staging, living at cf01.qa.las01.vcsops.com, the following three
# properties would be used
#
# shortname: staging
# cc_target: api.cf01.qa.las01.vcsops.com
# app_domain: cf01.qa.las01.vcsops.com
#
# 2) the email section is optional. If present, and configured correctly, you can click on the email
# button to generate an email report of the current state of the run. The email section below shows
# how to correctly configure the email section which includes
# - the address of the smtp server and credentials
# - the to/from address
# - end
# email:
#   address: smtp.somedomain.com
#   port: 587
#   domain: cloudfoundry.com
#   user_name: theusername
#   password: andthepassword
#   from: stac2@cloudfoundry.com
#   default: someuser@somedomain.com
#   to:
#     webapi: someuser@somedomain.com, someotheruser@somedomain.com
#
# 3) the default workload and maximum concurrency for a given cloud are set here
#    - the value of cmax supplies the maximum concurrency, i.e., the maximum number of concurrent nabv threads
#      that should be running at a time. The practical max on this (based on the current UI is 192).
#    - the value of default_workload supplies the default workload in the workload selector box
# cmax: 192
# default_workload: sys_basic_http_cpu
#
# 4) For classic cloud foundry, stac2 needs to use a large pool of user accounts which is creates apps
# and services within. This allows it to stay mostly within the 2GB quota. If your user pool is too small
# and you run heavy app loads you will high quota issues and will need to increase the pool of user accounts
# available to stac2.
#
# For v2 clouds, run stac2 in a paid account and you can run with a very large quota. For these clouds you can
# get by with only a single user, but that user MUST be a member of the specified organization and must have
# full access to the specified space.
#
# For both v1 and v2 clouds you need a user section that looks like the one shown below. Just use cf register
# to create user accounts. Note for large values of cmax you need large pools of users. A 3:1 or 2:1 ratio is best.
#
# users:
#   - name: stac2u0@rbcon.com
#     password: 123456
#   - name: stac2u1@rbcon.com
#     password: 123456
#
# For v2 clouds, note that the cloud is a v2 cloud and also supply the org and space for the cloud. While this data
# is very related to the user list, for readability, It's probably best to include the following properties below the
# shortname property
# mode: v2
# org: stac2
# space: stac2_run