diff --git a/docs/block-storage-guide.md b/docs/block-storage-guide.md deleted file mode 100644 index aa7f3d5b7f..0000000000 --- a/docs/block-storage-guide.md +++ /dev/null @@ -1,54 +0,0 @@ -# Storage Guide - -This is a overview of how Cinder is implemented in Kolla so that it is easier -to understand how to use it. Keep in mind, this is the first iteration for -Cinder as support for Ceph and physical devices will follow. - -## Overview - -Kolla's setup for Cinder uses tgtd as the default iSCSI helper to implement -persistent targets. By default, we use a loop back file that is defined by -CINDER_LVM_LO_VOLUME_SIZE to create the cinder-volumes volume group. - -## Configure Cinder - -Listed below are the default configurations for Cinder. For more info on what -each variable does look at the [integration guide.](https://github.com/stackforge/kolla/blob/master/docs/integration-guide.md): - - # Cinder Volume - CINDER_ENABLED_BACKEND=lvm57 - CINDER_LVM_LO_VOLUME_SIZE=4G - CINDER_VOLUME_API_LISTEN=$HOST_IP - CINDER_VOLUME_BACKEND_NAME=LVM_iSCSI57 - CINDER_VOLUME_DRIVER=cinder.volume.drivers.lvm.LVMISCSIDriver - CINDER_VOLUME_GROUP=cinder-volumes - ISCSI_HELPER=tgtadm - ISCSI_IP_ADDRESS=$HOST_IP - -## Using Cinder - -After you've started all your containers, you should be able to interact -with Cinder. - - cinder list - -Next, you will want to create a volume and attach it to a running instance. - - cinder create 1 - nova volume-attach - -## Debugging and deleting volumes - -The cinder-volumes volume group can't be seen from the host. In order to -interact with an existing volume, you need to jump into the Cinder Volume -container. - - sudo docker exec -it /bin/bash - vgs - -Running 'vgs' will list the volumes groups. From there, you can look -specific volumes to make sure volume creation succeeded. - -To delete the cinder-volumes volume group from within the container run: - - vgs remove cinder-volumes diff --git a/docs/database-container-set.md b/docs/database-container-set.md deleted file mode 100644 index b4a16388a5..0000000000 --- a/docs/database-container-set.md +++ /dev/null @@ -1,50 +0,0 @@ -MariaDB Container Set -===================== - -The MariaDB database application has been organized into two containers, -known as a [container-set][] within the Kolla project. One container runs -the MariaDB application and the other stores the actual data. - -Operational efficiencies and service stability is provided by -separating the application from the stored data. For example, stored data -can be backed-up or restored without touching the MariaDB application -component. - -The containers work in a cooperative fashion by using [docker-compose][] -(aka Fig) to ensure the containers are co-located on the same host. -With docker-compose, you can manage the containers collectively -as a single unit. - -Here is a sample docker-compose yaml file for using both MariaDB containers: - -``` -mariadbdata: - image: kollaglue/centos-rdo-mariadb-data - volumes: - - /var/lib/mysql:/var/lib/mysql - - /var/log/mariadb:/var/log/mariadb - net: "host" - privileged: true -mariadbapp: - image: kollaglue/centos-rdo-mariadb-app - env_file: - - openstack.env - volumes_from: - - mariadbdata - net: "host" - ports: - - "3306:3306" - privileged: true -``` - -In addition to the MariaDB application being organized across two containers, the data -container follows the [data-only container][] design pattern. In this design pattern, -a dedicated container is used to perform a host mount and separate application -container(s) mount volumes from the data-only container instead of performing the host -mount directly. In the example above, the MariaDbApp container mounts the /var/lib/mysql -and /var/log/mariadb volumes through the MariaDbData container instead of mounting -these directly to the Docker host. - -[docker-compose]: http://www.fig.sh/ -[container-set]: https://review.openstack.org/#/c/153798/ -[data-only container]: http://www.tech-d.net/2013/12/16/persistent-volumes-with-docker-container-as-volume-pattern/ diff --git a/docs/integration-guide.md b/docs/integration-guide.md deleted file mode 100755 index ecfe65a43c..0000000000 --- a/docs/integration-guide.md +++ /dev/null @@ -1,219 +0,0 @@ - -# Integrating with Kolla - -This guide describes how to integrate with Kolla. The main integration path is -via docker-compose using docker-compose YML files. Each container set has -a common YML and associated `openstack.env`. The `openstack.env` file -describes the command line environment to pass to the docker-compose yml files. - -## Why integrate with Kolla? - -Integrating with Kolla takes a hard part of managing an OpenStack system, -specifically managing the container images, and places the burden on a third -party project. We strive to do an excellent job of providing world-class -OpenStack containers at least as a reference architecture, and possibly as what -may be desirable to deploy into live production. - -## Docker Command Line Arguments - -Every container set YML file includes the necessary docker CLI operations -needed to launch the container in a tidy YML file. Instead of guessing which -set of command line operations are needed per container, the docker-compose -YML file can be used directly and will pass the appropriate command line -values to the container on container start. - -The parameterized docker features used by kolla are: - -* --pid=host -* --net=host -* -v host:container -* --privileged - -These parameterized features are not exposed to the user. Instead they are -executed via docker-compose. - -## Environment Variables - -Rather then document which individual containers require specific configuration -variables, Kolla integration requires passing all configuration variables to -all containers. This allows a simple method of ensuring every type of node -(controller, storage, compute) receives the same configuration. - -### Environment Variable KEY/VALUE pairs - - DEBUG_LOGGING= - Defaults to false. Enable/disable debug level logging for all OpenStack services. - VERBOSE_LOGGING= - Defaults to true. Enable/disable verbose level logging for all OpenStack services. - NOVA_LOG_DIR= - Defaults to none. The base directory used for relative Nova --log-file paths. - NEUTRON_LOG_DIR - Defaults to none. The base directory used for relative Neutron --log-file paths. - NOVA_API_LOG_FILE= Defaults to none. Name of Nova API log file to output to. If no default is set, logging will go to stdout. - NOVA_CONDUCTOR_LOG_FILE= Defaults to none. Name of Nova Conductor log file to output to. If no default is set, logging will go to stdout. - NOVA_SCHEDULER_LOG_FILE= Defaults to none. Name of Nova Scheduler log file to output to. If no default is set, logging will go to stdout. - NOVA_COMPUTE_LOG_FILE= Defaults to none. Name of Nova Compute log file to output to. If no default is set, logging will go to stdout. - NEUTRON_SERVER_LOG_FILE= Defaults to none. Name of Neutron Server log file to output to. If no default is set, logging will go to stdout. - NEUTRON_L3_AGENT_LOG_FILE= Defaults to none. Name of Neutron L3 Agent log file to output to. If no default is set, logging will go to stdout. - NEUTRON_LINUXBRIDGE_AGENT_LOG_FILE= Defaults to none. Name of Neutron Linux Bridge Agent log file to output to. If no default is set, logging will go to stdout. - NEUTRON_METADATA_AGENT_LOG_FILE= Defaults to none. Name of Neutron Metadata Agent log file to output to. If no default is set, logging will go to stdout. - ADMIN_USER_PASSWORD= - The admin user password - ADMIN_TENANT_NAME= - tenant name - FLAT_INTERFACE= - nova networking flat interface device name - DB_CLUSTER_BIND_ADDRESS= - Defaults to 0.0.0.0. Listening address for database. - DB_CLUSTER_INIT_DB= - Defaults to false. Configures if Galera should be initialized. - DB_CLUSTER_NAME=. Defaults to kollacluster. Galera cluster name. - DB_CLUSTER_NODES=. Defaults to none. List of nodes in Galera cluster, separated by comma(IP address or hostname). - DB_CLUSTER_WSREP_METHOD= - Defaults to mysqldump. Galera replication method. - GLANCE_API_SERVICE_HOST= - address where glance API is running> - GLANCE_DB_NAME= - DB name of glance service - GLANCE_DB_PASSWORD= - - GLANCE_DB_USER= - User name of glance in the database - GLANCE_KEYSTONE_PASSWORD= - Keystone DB password - GLANCE_KEYSTONE_USER= - Glance Keystone User - GLANCE_REGISTRY_SERVICE_HOST= Glance registry service host - GNOCCHI_ADMIN_PASSWORD= - admin password for gnocchi user - GNOCCHI_API_SERVICE_HOST= - address where gnocchi API is running - GNOCCHI_KEYSTONE_PASSWORD= - Gnocchi keystone password - GNOCCHI_KEYSTONE_USER= - Gnocchi Keystone User - GNOCCHI_SERVICE_PORT=<8041> - Port where gnocchi operates - GNOCCHI_STORAGE_BACKEND= - Storage backend for gnocchi - KEYSTONE_ADMIN_PASSWORD= - KEYSTONE_ADMIN_SERVICE_HOST= - IP Address of Keystone Host - KEYSTONE_ADMIN_SERVICE_PORT=<35357> - Port where Keystone admin endpoint operates. - KEYSTONE_ADMIN_TOKEN= - A token used to access Keystone - KEYSTONE_AUTH_PROTOCOL= - The keystone authentication protocol - KEYSTONE_DB_PASSWORD= - The password used to access Keystone in the DB - KEYSTONE_PUBLIC_SERVICE_HOST= - The IP address where Keystone is running - KEYSTONE_PUBLIC_SERVICE_PORT=<5000> - Port which keystone uses for public service. - MARIADB_ROOT_PASSWORD= - defines the MariaDB root password - MARIADB_SERVICE_HOST= - The IP Address where Mariadb is running - MARIADB_MAX_CONNECTIONS=<151> - The maximum number of connections to the MariaDB server - NETWORK_MANAGER= - Use Nova or Neutron networking - NOVA_API_SERVICE_HOST= - The IP Address where the Nova API Service is hosted - METADATA_HOST= - The IP address of the Nova Metadata service - ENABLED_APIS= - Enabled Nova API services. - NOVA_DB_NAME= - The name of the nova entry in the database - NOVA_DB_PASSWORD= - The password used to access nova - NOVA_DB_USER= - The name of the nova DB password - NOVA_EC2_API_SERVICE_HOST= - The IP Address where the Nova EC2 API is hosted - arn't these two the same? - NOVA_EC2_SERVICE_HOST= _ The IP Address where the Nova EC2 service is hosted - NOVA_VNCSERVER_PROXYCLIENT_ADDRESS= The IP address for the VNC Proxy Client to use - NOVA_VNCSERVER_LISTEN_ADDRESS= The IP address for the VNC Server to use - NOVA_NOVNC_BASE_ADDRESS= The IP/DNS Name to use for the NOVNC Base URL - NOVA_NOVNC_PROXY_PORT=<6080> The TCP port used by Nova NoVNC - NOVA_KEYSTONE_PASSWORD= - The Nova keystone password - NOVA_KEYSTONE_USER= - The Nova keystone username - NEUTRON_DB_NAME= - The name of the Neutron database - NEUTRON_DB_USER= - The name used by Neutron to access the Neutron database - NEUTRON_DB_PASSWORD= The password used by Neutron to access the Neutron database - NEUTRON_KEYSTONE_USER= - The name used by Neutron to communicate with Keystone - NEUTRON_KEYSTONE_PASSWORD= - The password used by Neutron to communicate with Keystone - NEUTRON_SERVER_SERVICE_HOST=<$HOST_IP> - The IP address/hostname used to commuicate with the Neutron API - NEUTRON_SHARED_SECRET= - The shared secret used between Neutron/Nova to secure metadata communication - NEUTRON_API_PASTE_CONFIG= - Location of Neutron's API paste config file - NEUTRON_VLAN_NETWORK_NAME= - List of physical_network names with which vlan networks can be created - NEUTRON_NETWORK_VLAN_RANGES=<1:1> - Colon seperated range of addresses - TYPE_DRIVERS= - List of network type driver entrypoints to be loaded - TENANT_NETWORK_TYPES= - List of network_types to allocate as tenant networks - MECHANISM_DRIVERS= - List of networking mechanism driver entrypoints to be loaded - NEUTRON_FLAT_NETWORK_NAME= - List of physical_network names with which flat networks can be created - NEUTRON_FLAT_NETWORK_INTERFACE= - List of physical interface names that connect to physical_networks - HEAT_DB_NAME= - The heat DB name - HEAT_DB_PASSWORD= - The heat db password - HEAT_KEYSTONE_PASSWORD= - The keystone password for the heat user - HEAT_API_SERVICE_HOST= - The IP Address where the Heat API service is hosted - HEAT_API_CFN_SERVICE_HOST= - The IP Address where Heat users will contact the heat-engine in search for meta data - HEAT_API_CFN_URL_HOST= - The IP Address where Heat virtual machines will contact the heat-engine to signal wait conditions - HEAT_DOMAIN_PASS= - The Heat domain password - INIT_CINDER_DB= - Initialize or update the Cinder db - INIT_DESIGNATE_DB= - Initialize or update the Designate db - INIT_GLANCE_DB= - Initialize or update the Glance db - INIT_HEAT_DB= - Initialize or update the Heat db - INIT_KEYSTONE_DB= - Initialize or update the Keystone db - INIT_NOVA_DB= - Initialize or update the Nova db - PUBLIC_INTERFACE= - The nova public interface - PUBLIC_IP= - The IP Address of this host - RABBITMQ_PASS= - The rabbitmq password used to join AMQP - RABBITMQ_SERVICE_HOST= - The IP Address where the Rabbit service is running - RABBITMQ_USER= - The RabbitMQ user name - RABBITMQ_CLUSTER_NODES= - Default to none. RabbitMQ cluster nodes list in format 'hostname1@IP1 hostname2@IP2' (without quotes) - RABBITMQ_CLUSTER_COOKIE= - Default to none. RabbitMQ cookie content. Alphabetical value here - RABBIT_PASSWORD= - The RabbitMQ password - RABBIT_USERID= - The RabbitMQ user id on the host - MAGNUM_DB_NAME= - The Magnum database name - MAGNUM_DB_USER= - The Magnum database username - MAGNUM_DB_PASSWORD= - The Magnum database password - MAGNUM_KEYSTONE_USER= - The Magnum keystone username - MAGNUM_KEYSTONE_PASSWORD= - The Magnum keystone password - MAGNUM_API_SERVICE_HOST= - The Magnum Host IP address - MAGNUM_API_SERVICE_PORT=<9511> - The Magnum port - DESIGNATE_DB_NAME= - The Designate database name - DESIGNATE_DB_PASSWORD= - The Designate database password - DESIGNATE_KEYSTONE_PASSWORD= - The keystone password for the designate user - DESIGNATE_BIND9_RNDC_KEY= - The rndc/bind key to use for communication between pool_manager and bind9 - DESIGNATE_MASTERNS= - The IP Address of the master (primary) DNS server (the backend) - DESIGNATE_BACKEND= - The backend to use in Designate, currently only bind9 is supported - DESIGNATE_SLAVENS= - The IP Address of a slave nameserver under control of pool_manager - DESIGNATE_API_SERVICE_HOST= - The IP Address of the Designate API - DESIGNATE_API_SERVICE_PORT=<9001> - The port of the Designate API - DESIGNATE_MDNS_PORT=<5354> - The port of the Designate MiniDNS server acting as master server - DESIGNATE_DNS_PORT=<53> - The port of the Designate-backed DNS slaves that are used by the world - DESIGNATE_ALLOW_RECURSION= - Configure a recursive nameserver - DESIGNATE_DEFAULT_POOL_NS_RECORD= - Name of server used to generate NS records - DESIGNATE_SINK_NOVA_DOMAIN_NAME= - Name of domain used to create records from Nova notifications - DESIGNATE_SINK_NEUTRON_DOMAIN_NAME= - Name of domain used to create records from Neutron notifications - DESIGNATE_SINK_NOVA_FORMATS=<("%(octet0)s-%(octet1)s-%(octet2)s-%(octet3)s.%(domain)s" "%(hostname)s.%(domain)s")> - List of formats for records that will be created by Nova handler - DESIGNATE_SINK_NEUTRON_FORMATS=<("%(octet0)s-%(octet1)s-%(octet2)s-%(octet3)s.%(domain)s" "%(hostname)s.%(domain)s")> - List of formats for records that will be created by Neutron handler - CINDER_API_SERVICE_HOST= - The IP Address where the Cinder service is running - CINDER_API_SERVICE_PORT=<8776> - Port where Cinder operates - CINDER_API_SERVICE_LISTEN= - The IP Address where the Cinder API listens - CINDER_KEYSTONE_USER= - Cinder Keystone User - CINDER_KEYSTONE_PASSWORD= - The Cinder Keystone password - CINDER_ADMIN_PASSWORD= - The Cinder password - CINDER_DB_NAME= - Cinder's DB name - CINDER_DB_USER= - User name of Cinder in the database - CINDER_DB_PASSWORD= - Cinder DB password - CINDER_BACKUP_DRIVER= - The backup driver for Cinder - CINDER_BACKUP_MANAGER= - The backup manager for Cinder - CINDER_BACKUP_API_CLASS= - The cinder-backup api class - CINDER_BACKUP_NAME_TEMPLATE=