[Starlingx-discuss] Intentions toward enhancements for Starlingx Libvirt deployment method host utilization

[Thebeau, Michel]

Good morning Greg,

Thanks for letting me know.

I was not aware that the documents were out-of-sync and that the examples under virtual deployment were out-of-date.  Especially: I had not noticed any out-of-date instruction while using the examples from virtual section.

To answer your first question: I have an intention of not impacting the canonical examples and current usage/use-case.  In this way I did not anticipate documentation changes.  I especially intend that if one were using the libvirt deployment method as it is presented today, then the changes I intend would have no impact on that usage.

I am not prepared to accept the assignment this morning.  I can, for example, contribute to ensuring that a merging of the documents will continue to accurately reflect the libvirt virtual deployment method - either by proposing changes or reviewing the changes.  Please feel free to bring me into the conversation.

M

________________________________
From: Waines, Greg <Greg.Waines at windriver.com>
Sent: 10 July 2023 8:24 AM
To: Thebeau, Michel <Michel.Thebeau at windriver.com>; starlingx-discuss at lists.starlingx.io <starlingx-discuss at lists.starlingx.io>
Cc: Balaraj, Juanita <Juanita.Balaraj at windriver.com>; Stone, Ronald <Ronald.Stone at windriver.com>
Subject: RE: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization


Hey Mich,

Thanksfor looking at this.



Do you intent to update the virtual install guides as well ? … as part of this work ?

e.g.   https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_install_kubernetes.html



A heads up if you do … (I think I’ve mentioned this a couple of times)

  *   The bare-metal install guides have been enhanced/updated and maintained over the last few stx releases
  *   … but the virtual install guides have not
     *   E.g. if you compare
        *   https://docs.starlingx.io/deploy_install_guides/release/bare_metal/aio_simplex_install_kubernetes.html
        *   And
        *   https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.html
           *   https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_environ.html
              *   https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_install_kubernetes.html

you’ll see several differences that are not necessarily due virtual versus bare-metal.

  *   We (doc team) did not maintain the virtual install guides because we were thinking that
     *   It was too much overhead maintaining both guides,
     *   Instead we were going to combine the guides
        *   And just have in the very few places, the difference between virtual versus bare-metal
     *   BUT
… we have not had time to look at this.
     *
     *   If you are interested in doing this … let me, Juanita and Ron know and we can provide some guidance here.



Greg.



From: Thebeau, Michel <Michel.Thebeau at windriver.com>
Sent: Wednesday, June 28, 2023 3:51 PM
To: starlingx-discuss at lists.starlingx.io
Subject: [Starlingx-discuss] Intentions toward enhancements for Starlingx Libvirt deployment method host utilization



Hi,

I prepared the following description of enhancements I intend towards the libvirt virtual deployment method.  Please let me know I should follow a particular procedure.  Otherwise I intend to create a story in storyboard.



Mitch.
===
Starlingx Libvirt deployment method host utilization enhancements



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<https://urldefense.com/v3/__https:/docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html*index-install-r7-8966076f0e81__;Iw!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3g0pfSBm$>

Libvirt deployment method in starlingx/tools - https://opendev.org/starlingx/tools/src/branch/master/deployment/libvirt<https://urldefense.com/v3/__https:/opendev.org/starlingx/tools/src/branch/master/deployment/libvirt__;!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3i5MQhv-$>

Libvirt deployment method moved this week to starlingx/virtual-deployment - https://opendev.org/starlingx/virtual-deployment/src/branch/master/libvirt<https://urldefense.com/v3/__https:/opendev.org/starlingx/virtual-deployment/src/branch/master/libvirt__;!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3sDypkJm$>



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<https://urldefense.com/v3/__http:/setup_network.sh__;!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3h6jVq1i$>, setup_configation.sh<https://urldefense.com/v3/__http:/setup_configation.sh__;!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3s6zQf--$>, destroy_configuration.sh<https://urldefense.com/v3/__http:/destroy_configuration.sh__;!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3p-0jJRx$>, 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<https://urldefense.com/v3/__http:/functions.sh__;!!AjveYdw8EvQ!Z4_8uAlE2hflEwoj6PLS-fkscNHofrzze0Z8TcwKqUWt8eZuvXR2BYDbfdQ1NRxwAPidwaXpiTs6mEaYmZdFwN3y3svzl4kA$>)

  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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20230710/fb52a0e8/attachment-0001.htm>