References:

"Install StarlingX Kubernetes in a virtual environment" - https://docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html#index-install-r7-8966076f0e81

Libvirt deployment method in starlingx/tools - https://opendev.org/starlingx/tools/src/branch/master/deployment/libvirt

Libvirt deployment method moved this week to starlingx/virtual-deployment - https://opendev.org/starlingx/virtual-deployment/src/branch/master/libvirt

Motivation is to:

 A) maintain attributes for more than one virtual lab

 B) improve the usage and selection of the host's resources for disk, memory and cpu

 C) isolate cluster networks where more than one virtual lab may be running

Philosophy of continuity:

Introduce changes and developments in continuity with established examples and approaches.

 - Maintain the existing examples for default setting and the 'mad' override.

 - Establish regression test based on the default setting and 'mad' override to ensure that a user of the deployment method can continue to do the same thing they used to do.

 - Maintain and extend the use of overridable variable definitions for the attributes of a lab.

 - Maintain and extend the use of command line parameters for configuration selection, such as "-c 'simplex'".

 - Maintain and extend the existing workflow: "exporting variables, setup_network.sh, setup_configation.sh, destroy_configuration.sh, destroy_network.sh".

A) Maintain configurations for more than one virtual cluster:

Motivation: allow a lab's attributes to be recalled from a configuration file and operate upon that lab specifically.

Establish a precedent for a configuration file used to override the default attributes.  Refer to the README.rst "Overview" section which lists environment variables CONTROLLER, WORKER, BRIDGE_INTERFACE, EXTERNAL_NETWORK, EXTERNAL_IP.

Provide a default configuration file that will reset the variables to defaults as they currently exist within the deployment/libvirt scripts, including:

    BRIDGE_INTERFACE=${BRIDGE_INTERFACE:-stxbr}

    EXTERNAL_NETWORK=${EXTERNAL_NETWORK:-10.10.10.0/24}

    EXTERNAL_IP=${EXTERNAL_IP:-10.10.10.1/24}

    CONFIGURATION=${CONFIGURATION:-simplex}

    CONTROLLER=${CONTROLLER:-controller}

    WORKER=${WORKER:-worker}

    STORAGE=${STORAGE:-storage}

    WORKER_NODES_NUMBER=${WORKER_NODES_NUMBER:-1}

    STORAGE_NODES_NUMBER=${STORAGE_NODES_NUMBER:-1}

Provide an example configuration file that sets a lab's attributes deviating from the default.  Especially, the default and the example should co-exist.  Consider honouring the "mad" example in README.rst.

If necessary provide an option to select values, or a script to set variables, from that configuration file.

B) Improve usage and selection of host's resources:

Motivation: allow lab specific attributes for the host's resources and provide tools to inspect those resources within the contexts of the virtual labs and/or overall

Note: Ensure that all changes are providing defaults that are equivalent to the existing implementation.

Values to add to the lab's attributes:

  Add DOMAIN_DIRECTORY to the set of overridable variables

  Add an override variable for the DISK file location for each node in a virtual lab. (currently hardcoded /var/lib/libvirt/images in functions.sh)

  Add an override variable for the MEMORY setting for each node (currently XML hardcoded <memory>)

  Add an override variable for the CPU setting of each node (currently XML hardcoded <vcpu>)

Add scripting to assist with supervising the host's resources, such as:

    - listing the lab's nodes and networks;

    - inspecting the lab's network configurations;

    - inspecting the host's and lab's disk usage per configured disk;

    - listing a lab's nodes' cpu and memory allocations

C) Isolate cluster networks where more than one cluster may be running:

Motivation: on a host that has a capacity to run virtual clusters, ensure that there is no networking crosstalk between the running clusters.

Provide scripting to add/remove iptables restrictions for a lab's networks. Initially assume no inter-cluster communication, and only the OAM network will route to external networks.  Include:

    - ipv4 and/or ipv6

    - a lab specific iptables CHAIN

Probably: omit running this script automatically, since it changes the deployment behaviour.  Consider adding an optional parameter to setup_network.sh.