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

191 lines
8.4 KiB
YAML
Raw Permalink Normal View History

Add YAML header to sample config files
2019-07-06 02:24:28 -04:00
---
Use consistent naming of components Rename "pvcd" to "pvcnoded", and "pvc-api" to "pvcapid" so names for the daemons are fully consistent. Update the names of the configuration files as well to match this new formatting. References #79
2020-02-08 19:16:19 -05:00
# pvcnoded configuration file example
Add example YAML file
2019-03-10 20:40:45 -04:00
#
# 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.
#
Use consistent naming of components Rename "pvcd" to "pvcnoded", and "pvc-api" to "pvcapid" so names for the daemons are fully consistent. Update the names of the configuration files as well to match this new formatting. References #79
2020-02-08 19:16:19 -05:00
# Copy this example to /etc/pvc/pvcnoded.conf and edit to your needs
Add example YAML file
2019-03-10 20:40:45 -04:00
pvc:
# node: The (short) hostname of the node, set during provisioning
Update default configuration samples
2020-01-12 21:33:15 -05:00
node: pvchv1
Properly support debug logging via config
2019-08-01 11:22:27 -04:00
# debug: Enable or disable debug output
debug: False
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
Enable autostart of API client on Primary Adds a config flag that turns on the API client following the Primary coordinator. The retcode of the start/stop commands is ignore so this can fail gracefully if e.g. the client isn't installed.
2019-07-06 02:42:56 -04:00
# enable_api: Enable or disable the API client, if installed, when node is Primary
enable_api: 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:
Update default configuration samples
2020-01-12 21:33:15 -05:00
- pvchv1
- pvchv2
- pvchv3
Add example YAML file
2019-03-10 20:40:45 -04:00
# 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
Integrate metadata API into node daemon
2019-12-14 15:55:30 -05:00
# metadata: Metadata API subsystem
metadata:
# database: Patroni PostgreSQL database configuration
database:
# host: PostgreSQL hostname, invariably 'localhost'
host: localhost
# port: PostgreSQL port, invariably 'localhost'
port: 5432
Rename sample database for API From pvcprov to pvcapi to facilitate the changing nature of this database and its expansion to benchmark results.
2020-08-25 01:59:35 -04:00
# name: PostgreSQL database name, invariably 'pvcapi'
name: pvcapi
# user: PostgreSQL username, invariable 'pvcapi'
user: pvcapi
Integrate metadata API into node daemon
2019-12-14 15:55:30 -05:00
# pass: PostgreSQL user password, randomly generated
Rename sample database for API From pvcprov to pvcapi to facilitate the changing nature of this database and its expansion to benchmark results.
2020-08-25 01:59:35 -04:00
pass: pvcapi
Add example YAML file
2019-03-10 20:40:45 -04:00
# system: Local PVC instance configuration
system:
Move intervals config one level up Makes for a slightly-better-organized configuration and explanation.
2019-07-28 19:33:08 -04:00
# intervals: Intervals for keepalives and fencing
intervals:
Add configurable VM shutdown timeout Closes #102
2020-08-20 21:26:12 -04:00
# vm_shutdown_timeout: Number of seconds for a VM to 'shutdown' before being forced off
vm_shutdown_timeout: 180
Move intervals config one level up Makes for a slightly-better-organized configuration and explanation.
2019-07-28 19:33:08 -04:00
# 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
Add example YAML file
2019-03-10 20:40:45 -04:00
# fencing: Node fencing configuration
fencing:
# 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
Update default configuration samples
2020-01-12 21:33:15 -05:00
host: pvchv1-lom
Add example YAML file
2019-03-10 20:40:45 -04:00
# 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
Support disabling log colours and dates For usecases such as a pure-syslog, allow disabling of dates or colours in the log messages (separately).
2019-07-10 21:39:25 -04:00
# log_colours: Enable or disable ANSI colours in log output
log_colours: True
# log_dates: Enable or disable date strings in log output
log_dates: True
Support disabling keepalive logging
2019-06-18 12:44:07 -04:00
# log_keepalives: Enable or disable keepalive logging
log_keepalives: True
Add support for enable/disable keepalive detail
2019-06-18 19:54:42 -04:00
# log_keepalive_cluster_details: Enable or disable node status logging during keepalive
log_keepalive_cluster_details: True
# log_keepalive_storage_details: Enable or disable node storage logging during keepalive
log_keepalive_storage_details: 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:
Implement bridge_device for bridged VNIs Required due to #64. Bridged networks were being created on top of a vLAN if the Cluster network was a vLAN device, rather than being created on the underlying device. This came from a previous revision of the cluster architecture guidelines where Cluster was supposed to be a raw device rather than a vLAN. This fixed the problem by implementing a configuration field for a "bridge_device", a NIC device that can then have the bridged vLANs created on top of it. Fixes #64
2020-01-06 14:44:56 -05:00
# bridge_device: Underlying device to use for bridged vLAN networks; usually the device underlying <cluster>
bridge_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
# 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
Use Rados and add Ceph entries to pvcnoded.yaml
2020-06-06 21:12:51 -04:00
# storage; PVC storage configuration
# OPTIONAL if enable_storage: False
storage:
# ceph_config_file: The config file containing the Ceph cluster configuration
ceph_config_file: "/etc/ceph/ceph.conf"
# ceph_admin_keyring: The file containing the Ceph client admin keyring
ceph_admin_keyring: "/etc/ceph/ceph.client.admin.keyring"