kolla-ansible/etc/kolla/globals.yml
MD NADEEM de695f04db Fix inconsistancy in globals.yml
The parameter values in global.yml were inconsist,
for some variable default values are shown while for
others it's not.

From user point of view it is important to know
the default values of the parameters and the globals.yml is
the file where user is supposed to look for config variable,
for sure a user do not want to look kolla/ansible/group_var/all.yml
file just for checking default values. So it is better to show all
default values in global.yml

This patch will solve this issue.

TrivialFix

Change-Id: I991fc5e1d4ed48d106da002a0f18a2b31525a482
2016-03-18 15:17:10 +00:00

141 lines
5.3 KiB
YAML

---
# You can use this file to override _any_ variable throughout Kolla.
# Additional options can be found in the 'kolla/ansible/group_vars/all.yml' file.
# Default value of all the commented parameters are shown here, To override
# the default value uncomment the parameter and change its value.
###################
# Kolla options
###################
# Valid options are [ COPY_ONCE, COPY_ALWAYS ]
#config_strategy: "COPY_ALWAYS"
# Valid options are [ centos, fedora, oraclelinux, ubuntu ]
#kolla_base_distro: "centos"
# Valid options are [ binary, source ]
#kolla_install_type: "binary"
# This should be a VIP, an unused IP on your network that will float between
# the hosts running keepalived for high-availability. When running an All-In-One
# without haproxy and keepalived, this should be the first IP on your
# 'network_interface' as set in the Networking section below.
kolla_internal_vip_address: "10.10.10.254"
# This is the DNS name that maps to the kolla_internal_vip_address VIP. By
# default it is the same as kolla_internal_vip_address.
#kolla_internal_fqdn: "{{ kolla_internal_vip_address }}"
# This should be a VIP, an unused IP on your network that will float between
# the hosts running keepalived for high-availability. It defaults to the
# kolla_internal_vip_address, allowing internal and external communication to
# share the same address. Specify a kolla_external_vip_address to separate
# internal and external requests between two VIPs.
#kolla_external_vip_address: "{{ kolla_internal_vip_address }}"
# The Public address used to communicate with OpenStack as set in the public_url
# for the endpoints that will be created. This DNS name should map to
# kolla_external_vip_address.
#kolla_external_fqdn: "{{ kolla_external_vip_address }}"
####################
# Docker options
####################
### Example: Private repository with authentication
#docker_registry: "172.16.0.10:4000"
#docker_namespace: "companyname"
#docker_registry_username: "sam"
#docker_registry_password: "correcthorsebatterystaple"
####################
# Networking options
####################
# This interface is what all your api services will be bound to by default.
# Additionally, all vxlan/tunnel and storage network traffic will go over this
# interface by default. This interface must contain an IPv4 address.
network_interface: "eth0"
# These can be adjusted for even more customization. The default is the same as
# the 'network_interface'. These interfaces must container an IPv4 address.
#kolla_external_vip_interface: "{{ network_interface }}"
#api_interface: "{{ network_interface }}"
#storage_interface: "{{ network_interface }}"
#tunnel_interface: "{{ network_interface }}"
# This is the raw interface given to neutron as its external network port. Even
# though an IP address can exist on this interface, it will be unusable in most
# configurations. It is recommended this interface not be configured with any IP
# addresses for that reason.
neutron_external_interface: "eth1"
# Valid options are [ openvswitch, linuxbridge ]
#neutron_plugin_agent: "openvswitch"
####################
# TLS options
####################
# To provide encryption and authentication on the kolla_external_vip_interface,
# TLS can be enabled. When TLS is enabled, certificates must be provided to
# allow clients to perform authentication.
#kolla_enable_tls_external: "no"
#kolla_external_fqdn_cert: "{{ node_config_directory }}/certificates/haproxy.pem"
####################
# OpenStack options
####################
# Use these options to set the various log levels across all OpenStack projects
# Valid options are [ True, False ]
#openstack_logging_debug: "False"
# Valid options are [ novnc, spice ]
#nova_console: "novnc"
# OpenStack services can be enabled or disabled with these options
#enable_cinder: "no"
#enable_heat: "yes"
#enable_magnum: "no"
#enable_swift: "no"
###################
# Ceph options
###################
# Ceph can be setup with a caching to improve performance. To use the cache you
# must provide separate disks than those for the OSDs
#ceph_enable_cache: "no"
# Valid options are [ forward, none, writeback ]
#ceph_cache_mode: "writeback"
# A requirement for using the erasure-coded pools is you must setup a cache tier
# Valid options are [ erasure, replicated ]
#ceph_pool_type: "replicated"
#######################################
# Manila - Shared File Systems Options
#######################################
#manila_enable_dhss: "yes"
#######################################
# Swift options
#######################################
# Swift expects block devices to be available for storage. Two types of storage
# are supported: 1 - storage device with a special partition name and filesystem
# label, 2 - unpartitioned disk with a filesystem. The label of this filesystem
# is used to detect the disk which Swift will be using.
# Swift support two mathcing modes, valid options are [ prefix, strict ]
#swift_devices_match_mode: "strict"
# This parameter defines matching pattern: if "strict" mode was selected,
# for swift_devices_match_mode then swift_device_name should specify the name of
# the special swift partition for example: "KOLLA_SWIFT_DATA", if "prefix" mode was
# selected then swift_devices_name should specify a pattern which would match to
# filesystems' labels prepared for swift.
#swift_devices_name: "KOLLA_SWIFT_DATA"