parallelvirtualcluster
/
pvc
1
0
Fork 0
Code Issues 11 Pull Requests Projects Releases 111 Wiki Activity
pvc/node-daemon/pvcd.sample.yaml

151 lines
6.5 KiB
YAML
Raw Normal View History

Add example YAML file
2019-03-10 20:40:45 -04:00
# pvcd cluster configuration file example
#
# This configuration file specifies details for this node in PVC. Multiple node
# blocks can be added but only the one matching the current system nodename will
# be used by the local daemon. Default values are not supported; the values in
# this sample configuration are considered defaults and, with adjustment of the
# nodename section and coordinators list, can be used as-is on a Debian system.
#
# Copy this example to /etc/pvc/pvcd.conf and edit to your needs
pvc:
# node: The (short) hostname of the node, set during provisioning
node: pvc-hv1
Move to YAML config and allow split functions 1. Move to a YAML-based configuration format instead of the original INI-based configuration to facilitate better organization and readability. 2. Modify the daemon to be able to operate in several modes based on configuration flags. Either networking or storage functions can be disabled using the configuration, allowing the PVC system to be used only for hypervisor management if required.
2019-03-11 01:44:26 -04:00
# functions: The daemon functions to enable
functions:
# enable_hypervisor: Enable or disable hypervisor functionality
# This should never be False except in very advanced usecases
enable_hypervisor: True
# enable_networking: Enable or disable virtual networking and routing functionality
enable_networking: True
# enable_storage: Enable or disable Ceph storage management functionality
enable_storage: True
Add example YAML file
2019-03-10 20:40:45 -04:00
# cluster: Cluster-level configuration
cluster:
# coordinators: The list of cluster coordinator hostnames
coordinators:
- pvc-hv1
- pvc-hv2
- pvc-hv3
# networks: Cluster-level network configuration
Move to YAML config and allow split functions 1. Move to a YAML-based configuration format instead of the original INI-based configuration to facilitate better organization and readability. 2. Modify the daemon to be able to operate in several modes based on configuration flags. Either networking or storage functions can be disabled using the configuration, allowing the PVC system to be used only for hypervisor management if required.
2019-03-11 01:44:26 -04:00
# OPTIONAL if enable_networking: False
Add example YAML file
2019-03-10 20:40:45 -04:00
networks:
# upstream: Upstream routed network for in- and out-bound upstream networking
upstream:
# domain: Upstream domain name, may be None
domain: "mydomain.net"
# network: Upstream network block
network: "1.1.1.0/24"
# floating_ip: Upstream floating IP address for the primary coordinator
floating_ip: "1.1.1.10/24"
Add support for upstream default gateway
2019-03-17 00:36:19 -04:00
# gateway: Upstream static default gateway, if applicable
gateway: "1.1.1.1"
Add example YAML file
2019-03-10 20:40:45 -04:00
# cluster: Cluster internal network for node communication and client virtual networks
cluster:
# domain: Cluster internal domain name
domain: "pvc.local"
# network: Cluster internal network block
network: "10.255.0.0/24"
# floating_ip: Cluster internal floating IP address for the primary coordinator
floating_ip: "10.255.0.254/24"
# storage: Cluster internal network for storage traffic
storage:
# domain: Cluster storage domain name
domain: "pvc.storage"
# network: Cluster storage network block
network: "10.254.0.0/24"
# floating_ip: Cluster storage floating IP address for the primary coordinator
Move to YAML config and allow split functions 1. Move to a YAML-based configuration format instead of the original INI-based configuration to facilitate better organization and readability. 2. Modify the daemon to be able to operate in several modes based on configuration flags. Either networking or storage functions can be disabled using the configuration, allowing the PVC system to be used only for hypervisor management if required.
2019-03-11 01:44:26 -04:00
floating_ip: "10.254.0.254/24"
Add example YAML file
2019-03-10 20:40:45 -04:00
# coordinator: Coordinator-specific configuration
Move to YAML config and allow split functions 1. Move to a YAML-based configuration format instead of the original INI-based configuration to facilitate better organization and readability. 2. Modify the daemon to be able to operate in several modes based on configuration flags. Either networking or storage functions can be disabled using the configuration, allowing the PVC system to be used only for hypervisor management if required.
2019-03-11 01:44:26 -04:00
# OPTIONAL if enable_networking: False
Add example YAML file
2019-03-10 20:40:45 -04:00
coordinator:
# dns: DNS aggregator subsystem
dns:
Switch DNS aggregator to PostgreSQL MariaDB+Galera was terribly unstable, with the cluster failing to start or dying randomly, and generally seemed incredibly unsuitable for an HA solution. This commit switches the DNS aggregator SQL backend to PostgreSQL, implemented via Patroni HA. It also manages the Patroni state, forcing the primary instance to follow the PVC coordinator, such that the active DNS Aggregator instance is always able to communicate read+write with the local system. This required some logic changes to how the DNS Aggregator worked, specifically ensuring that database changes aren't attempted while the instance isn't actively running - to be honest this was a bug anyways that had just never been noticed. Closes #34
2019-05-20 22:40:07 -04:00
# database: Patroni PostgreSQL database configuration
Add example YAML file
2019-03-10 20:40:45 -04:00
database:
Switch DNS aggregator to PostgreSQL MariaDB+Galera was terribly unstable, with the cluster failing to start or dying randomly, and generally seemed incredibly unsuitable for an HA solution. This commit switches the DNS aggregator SQL backend to PostgreSQL, implemented via Patroni HA. It also manages the Patroni state, forcing the primary instance to follow the PVC coordinator, such that the active DNS Aggregator instance is always able to communicate read+write with the local system. This required some logic changes to how the DNS Aggregator worked, specifically ensuring that database changes aren't attempted while the instance isn't actively running - to be honest this was a bug anyways that had just never been noticed. Closes #34
2019-05-20 22:40:07 -04:00
# host: PostgreSQL hostname, invariably 'localhost'
Add example YAML file
2019-03-10 20:40:45 -04:00
host: localhost
Switch DNS aggregator to PostgreSQL MariaDB+Galera was terribly unstable, with the cluster failing to start or dying randomly, and generally seemed incredibly unsuitable for an HA solution. This commit switches the DNS aggregator SQL backend to PostgreSQL, implemented via Patroni HA. It also manages the Patroni state, forcing the primary instance to follow the PVC coordinator, such that the active DNS Aggregator instance is always able to communicate read+write with the local system. This required some logic changes to how the DNS Aggregator worked, specifically ensuring that database changes aren't attempted while the instance isn't actively running - to be honest this was a bug anyways that had just never been noticed. Closes #34
2019-05-20 22:40:07 -04:00
# port: PostgreSQL port, invariably 'localhost'
port: 5432
# name: PostgreSQL database name, invariably 'pvcdns'
Add example YAML file
2019-03-10 20:40:45 -04:00
name: pvcdns
Switch DNS aggregator to PostgreSQL MariaDB+Galera was terribly unstable, with the cluster failing to start or dying randomly, and generally seemed incredibly unsuitable for an HA solution. This commit switches the DNS aggregator SQL backend to PostgreSQL, implemented via Patroni HA. It also manages the Patroni state, forcing the primary instance to follow the PVC coordinator, such that the active DNS Aggregator instance is always able to communicate read+write with the local system. This required some logic changes to how the DNS Aggregator worked, specifically ensuring that database changes aren't attempted while the instance isn't actively running - to be honest this was a bug anyways that had just never been noticed. Closes #34
2019-05-20 22:40:07 -04:00
# user: PostgreSQL username, invariable 'pvcdns'
Add example YAML file
2019-03-10 20:40:45 -04:00
user: pvcdns
Switch DNS aggregator to PostgreSQL MariaDB+Galera was terribly unstable, with the cluster failing to start or dying randomly, and generally seemed incredibly unsuitable for an HA solution. This commit switches the DNS aggregator SQL backend to PostgreSQL, implemented via Patroni HA. It also manages the Patroni state, forcing the primary instance to follow the PVC coordinator, such that the active DNS Aggregator instance is always able to communicate read+write with the local system. This required some logic changes to how the DNS Aggregator worked, specifically ensuring that database changes aren't attempted while the instance isn't actively running - to be honest this was a bug anyways that had just never been noticed. Closes #34
2019-05-20 22:40:07 -04:00
# pass: PostgreSQL user password, randomly generated
Add example YAML file
2019-03-10 20:40:45 -04:00
pass: pvcdns
# system: Local PVC instance configuration
system:
# fencing: Node fencing configuration
fencing:
# intervals: Intervals for fencing determination
intervals:
# keepalive_interval: Number of seconds between keepalive/status updates
keepalive_interval: 5
# fence_intervals: Number of keepalive_intervals to declare a node dead and fence it
fence_intervals: 6
# suicide_intervals: Numer of keepalive_intervals before a node considers itself dead and self-fences, 0 to disable
suicide_intervals: 0
# actions: Actions to take after a fence trigger
actions:
# successful_fence: Action to take after successfully fencing a node, options: migrate, None
successful_fence: migrate
# failed_fence: Action to take after failing to fence a node, options: migrate, None
failed_fence: None
# ipmi: Local system IPMI options
ipmi:
# host: Hostname/IP of the local system's IPMI interface, must be reachable
host: pvc-hv1-lom
# user: Local system IPMI username
user: admin
# pass: Local system IPMI password
pass: Passw0rd
# migration: Migration option configuration
migration:
# target_selector: Criteria to select the ideal migration target, options: mem, load, vcpus, vms
target_selector: mem
# configuration: Local system configurations
configuration:
# directories: PVC system directories
directories:
# dynamic_directory: Temporary in-memory directory for active configurations
dynamic_directory: "/run/pvc"
# log_directory: Logging directory
log_directory: "/var/log/pvc"
Implement domain log watching Implements the ability for a client to watch almost-live domain console logs from the hypervisors. It does this using a deque-based "tail -f" mechanism (with a configurable buffer per-VM) that watches the domain console logfile in the (configurable) directory every half-second. It then stores the current buffer in Zookeeper when changed, where a client can then request it, either as a static piece of text in the `less` pager, or via a similar "tail -f" functionality implemented using fixed line splitting and comparison to provide a generally-seamless output. Enabling this feature requires each guest VM to implement a Libvirt serial log and write its (text) console to it, for example using the default logging directory: ``` <serial type='pty'> <log file='/var/log/libvirt/vmname.log' append='off'/> <serial> ``` The append mode can be either on or off; on grows files unbounded, off causes the log (and hence the PVC log data) to be truncated on initial VM startup from offline. The administrator must choose how they best want to handle this until Libvirt implements their own clog-type logging format.
2019-04-11 19:06:06 -04:00
# console_log_directory: Libvirt console logging directory
console_log_directory: "/var/log/libvirt"
Add example YAML file
2019-03-10 20:40:45 -04:00
# logging: PVC logging configuration
logging:
# file_logging: Enable or disable logging to files under log_directory
file_logging: True
# stdout_logging: Enable or disable logging to stdout (i.e. journald)
stdout_logging: True
Implement domain log watching Implements the ability for a client to watch almost-live domain console logs from the hypervisors. It does this using a deque-based "tail -f" mechanism (with a configurable buffer per-VM) that watches the domain console logfile in the (configurable) directory every half-second. It then stores the current buffer in Zookeeper when changed, where a client can then request it, either as a static piece of text in the `less` pager, or via a similar "tail -f" functionality implemented using fixed line splitting and comparison to provide a generally-seamless output. Enabling this feature requires each guest VM to implement a Libvirt serial log and write its (text) console to it, for example using the default logging directory: ``` <serial type='pty'> <log file='/var/log/libvirt/vmname.log' append='off'/> <serial> ``` The append mode can be either on or off; on grows files unbounded, off causes the log (and hence the PVC log data) to be truncated on initial VM startup from offline. The administrator must choose how they best want to handle this until Libvirt implements their own clog-type logging format.
2019-04-11 19:06:06 -04:00
# console_log_lines: Number of console log lines to store in Zookeeper per VM
console_log_lines: 1000
Add example YAML file
2019-03-10 20:40:45 -04:00
# networking: PVC networking configuration
Move to YAML config and allow split functions 1. Move to a YAML-based configuration format instead of the original INI-based configuration to facilitate better organization and readability. 2. Modify the daemon to be able to operate in several modes based on configuration flags. Either networking or storage functions can be disabled using the configuration, allowing the PVC system to be used only for hypervisor management if required.
2019-03-11 01:44:26 -04:00
# OPTIONAL if enable_networking: False
Add example YAML file
2019-03-10 20:40:45 -04:00
networking:
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
# upstream: Upstream physical interface device
upstream:
Rename network device field It seems much nicer and more consistent as "device" rather than as "name".
2019-06-17 23:44:41 -04:00
# device: Upstream interface device name
device: ens4
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
# mtu: Upstream interface MTU; use 9000 for jumbo frames (requires switch support)
mtu: 1500
Rename network device field It seems much nicer and more consistent as "device" rather than as "name".
2019-06-17 23:44:41 -04:00
# address: Upstream interface IP address, options: None, by-id, <static>/<mask>
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
address: None
# cluster: Cluster (VNIC) physical interface device
cluster:
Rename network device field It seems much nicer and more consistent as "device" rather than as "name".
2019-06-17 23:44:41 -04:00
# device: Cluster (VNIC) interface device name
device: ens4
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
# mtu: Cluster (VNIC) interface MTU; use 9000 for jumbo frames (requires switch support)
mtu: 1500
Rename network device field It seems much nicer and more consistent as "device" rather than as "name".
2019-06-17 23:44:41 -04:00
# address: Cluster (VNIC) interface IP address, options: None, by-id, <static>/<mask>
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
address: by-id
# storage: Storage (Ceph OSD) physical interface device
storage:
Rename network device field It seems much nicer and more consistent as "device" rather than as "name".
2019-06-17 23:44:41 -04:00
# device: Storage (Ceph OSD) interface device name
device: ens4
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
# mtu: Storage (Ceph OSD) interface MTU; use 9000 for jumbo frames (requires switch support)
mtu: 1500
Rename network device field It seems much nicer and more consistent as "device" rather than as "name".
2019-06-17 23:44:41 -04:00
# address: Storage (Ceph OSD) interface IP address, options: None, by-id, <static>/<mask>
Unify network devices and addresses in config The old way of doing this was a little cumbersome, with an upper YAML tree split between "devices" (name and MTU) and addresses. This commit unifies these under the root "networking" section to make this section clearer.
2019-06-17 23:41:07 -04:00
address: by-id