[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-896... 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.
Hello, Mitch. * "Please let me know I should follow a particular procedure. Otherwise I intend to create a story in storyboard." I believe that's the way to go. Just so you know, for the work under the /virtualbox directory of the same repository, we used the original story<https://storyboard.openstack.org/#!/story/2005051> with the Task that merged the code back in 2019, adding new Tasks to it. Regarding the "Install StarlingX Kubernetes in a virtual environment" page, you might want to look at what we're proposing at https://review.opendev.org/c/starlingx/docs/+/886178. Basically, for now, we don't remove all the detailed procedures but provide an additional "automated install" guide at the top. Regards, Bruno. ________________________________ From: Thebeau, Michel <Michel.Thebeau@windriver.com> Sent: Wednesday, June 28, 2023 16:50 To: starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] Intentions toward enhancements for Starlingx Libvirt deployment method host utilization You don't often get email from michel.thebeau@windriver.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. 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-896... 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.
Good morning Bruno, Thank you. I am aware of the VirtualBox deployment method and the work of your team members. "Basically, for now, we don't remove all the detailed procedures" The installation guides of Starlingx present a "lesson" in the use of Starlingx for those who are exploring the project. Please consider keeping and maintaining these guides as "canonical" examples of deploying Starlingx. Our libvirt and VirtualBox deployment methods are intended to make Starlingx more accessible to those who are learning about the project: not requiring them to have dedicated hardware to explore Starlingx. In this sense, you may consider my intentions towards the libvirt deployment method to include this intention: to have no impact on the canonical examples. M ________________________________ From: Bruno Drugowick Muniz <Bruno.Muniz@encora.com> Sent: 04 July 2023 3:17 PM To: Thebeau, Michel <Michel.Thebeau@windriver.com>; starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Subject: Re: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization CAUTION: This email comes from a non Wind River email account! Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, Mitch. * "Please let me know I should follow a particular procedure. Otherwise I intend to create a story in storyboard." I believe that's the way to go. Just so you know, for the work under the /virtualbox directory of the same repository, we used the original story<https://urldefense.com/v3/__https://storyboard.openstack.org/*!/story/2005051__;Iw!!AjveYdw8EvQ!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9ch8-6eg0$> with the Task that merged the code back in 2019, adding new Tasks to it. Regarding the "Install StarlingX Kubernetes in a virtual environment" page, you might want to look at what we're proposing at https://review.opendev.org/c/starlingx/docs/+/886178<https://urldefense.com/v3/__https://review.opendev.org/c/starlingx/docs/*/886178__;Kw!!AjveYdw8EvQ!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9cjAbdLR8$>. Basically, for now, we don't remove all the detailed procedures but provide an additional "automated install" guide at the top. Regards, Bruno. ________________________________ From: Thebeau, Michel <Michel.Thebeau@windriver.com> Sent: Wednesday, June 28, 2023 16:50 To: starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Subject: [Starlingx-discuss] Intentions toward enhancements for Starlingx Libvirt deployment method host utilization You don't often get email from michel.thebeau@windriver.com. Learn why this is important<https://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!AjveYdw8EvQ!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9cXOHYvsI$> External Mail: Do not click links or open attachments unless you recognize the sender and know the content is safe. 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!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9c5fhrqXY$> 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!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9cT-wq3Gs$> 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!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9cNsICzsI$> 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!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9cwygZXHk$>, setup_configation.sh<https://urldefense.com/v3/__http://setup_configation.sh__;!!AjveYdw8EvQ!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9c4LSHYJU$>, destroy_configuration.sh<https://urldefense.com/v3/__http://destroy_configuration.sh__;!!AjveYdw8EvQ!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9csZDYZHk$>, 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!fIqXGqykkhUxQQg5_KIIRmmXRwF4yIIU-KyMlN4C53gJt6JqkO0FTW5TkRDI1NT_JsZKlFaEM6gE9KGQFe9cO_AOnX0$>) 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.
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_... 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_simpl... * And * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... 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@windriver.com> Sent: Wednesday, June 28, 2023 3:51 PM To: starlingx-discuss@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.
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@windriver.com> Sent: 10 July 2023 8:24 AM To: Thebeau, Michel <Michel.Thebeau@windriver.com>; starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@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_... 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_simpl... * And * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... 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@windriver.com> Sent: Wednesday, June 28, 2023 3:51 PM To: starlingx-discuss@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.
Where is the 'libvirt virtual deployment method' documented under docs.starlingx.io ? Is it here ? https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... ( and corresponding spots for other configs ) So you're saying your changes won't impact the current documentation of the 'libvirt virtual deployment method' ? Greg. From: Thebeau, Michel <Michel.Thebeau@windriver.com> Sent: Monday, July 10, 2023 8:55 AM To: Waines, Greg <Greg.Waines@windriver.com>; starlingx-discuss@lists.starlingx.io Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@windriver.com> Subject: Re: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization 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@windriver.com<mailto:Greg.Waines@windriver.com>> Sent: 10 July 2023 8:24 AM To: Thebeau, Michel <Michel.Thebeau@windriver.com<mailto:Michel.Thebeau@windriver.com>>; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com<mailto:Juanita.Balaraj@windriver.com>>; Stone, Ronald <Ronald.Stone@windriver.com<mailto:Ronald.Stone@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_... 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_simpl... * And * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... 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@windriver.com<mailto:Michel.Thebeau@windriver.com>> Sent: Wednesday, June 28, 2023 3:51 PM To: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@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.
Hi Greg, Yes, that's the example for aio-simplex specifically. I would have referred to the parent page which links to each deployment option: https://docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html<https://docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html#index-install-r7-8966076f0e81> Each of the listed deployment options under "Install StarlingX Kubernetes in a virtual environment" has the instruction for libvirt method. Yes, I am saying that I am intending that the changes should not impact anything that a user would do currently. I want to add options to better use a host's resources for disk, memory and CPU without affecting the current examples and default behaviour presented in the Starlingx documentation (and the libvirt method's README) M ________________________________ From: Waines, Greg <Greg.Waines@windriver.com> Sent: 10 July 2023 9:21 AM To: Thebeau, Michel <Michel.Thebeau@windriver.com>; starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@windriver.com> Subject: RE: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization Where is the ‘libvirt virtual deployment method’ documented under docs.starlingx.io ? Is it here ? https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... ( and corresponding spots for other configs ) So you’re saying your changes won’t impact the current documentation of the ‘libvirt virtual deployment method’ ? Greg. From: Thebeau, Michel <Michel.Thebeau@windriver.com> Sent: Monday, July 10, 2023 8:55 AM To: Waines, Greg <Greg.Waines@windriver.com>; starlingx-discuss@lists.starlingx.io Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@windriver.com> Subject: Re: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization 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@windriver.com<mailto:Greg.Waines@windriver.com>> Sent: 10 July 2023 8:24 AM To: Thebeau, Michel <Michel.Thebeau@windriver.com<mailto:Michel.Thebeau@windriver.com>>; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com<mailto:Juanita.Balaraj@windriver.com>>; Stone, Ronald <Ronald.Stone@windriver.com<mailto:Ronald.Stone@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_... 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_simpl... * And * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_... 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@windriver.com<mailto:Michel.Thebeau@windriver.com>> Sent: Wednesday, June 28, 2023 3:51 PM To: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@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.
Thanks for the feedback, the new story is here: https://storyboard.openstack.org/#!/story/2010816 Henry Bailey and I will be working through it. M ________________________________ From: Thebeau, Michel <Michel.Thebeau@windriver.com> Sent: 10 July 2023 9:48 AM To: Waines, Greg <Greg.Waines@windriver.com>; starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@windriver.com> Subject: Re: [Starlingx-discuss] Intentions toward enhancements for Starlingx Libvirt deployment method host utilization Hi Greg, Yes, that's the example for aio-simplex specifically. I would have referred to the parent page which links to each deployment option: https://docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/index-install-r7-8966076f0e81.html*index-install-r7-8966076f0e81__;Iw!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD9GIpFh1Q$> Each of the listed deployment options under "Install StarlingX Kubernetes in a virtual environment" has the instruction for libvirt method. Yes, I am saying that I am intending that the changes should not impact anything that a user would do currently. I want to add options to better use a host's resources for disk, memory and CPU without affecting the current examples and default behaviour presented in the Starlingx documentation (and the libvirt method's README) M ________________________________ From: Waines, Greg <Greg.Waines@windriver.com> Sent: 10 July 2023 9:21 AM To: Thebeau, Michel <Michel.Thebeau@windriver.com>; starlingx-discuss@lists.starlingx.io <starlingx-discuss@lists.starlingx.io> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@windriver.com> Subject: RE: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization Where is the ‘libvirt virtual deployment method’ documented under docs.starlingx.io<https://urldefense.com/v3/__http://docs.starlingx.io__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD_blypH5w$> ? Is it here ? https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_environ.html<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_environ.html__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD9wnjuUMw$> ( and corresponding spots for other configs ) So you’re saying your changes won’t impact the current documentation of the ‘libvirt virtual deployment method’ ? Greg. From: Thebeau, Michel <Michel.Thebeau@windriver.com> Sent: Monday, July 10, 2023 8:55 AM To: Waines, Greg <Greg.Waines@windriver.com>; starlingx-discuss@lists.starlingx.io Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com>; Stone, Ronald <Ronald.Stone@windriver.com> Subject: Re: Intentions toward enhancements for Starlingx Libvirt deployment method host utilization 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@windriver.com<mailto:Greg.Waines@windriver.com>> Sent: 10 July 2023 8:24 AM To: Thebeau, Michel <Michel.Thebeau@windriver.com<mailto:Michel.Thebeau@windriver.com>>; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io> <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Cc: Balaraj, Juanita <Juanita.Balaraj@windriver.com<mailto:Juanita.Balaraj@windriver.com>>; Stone, Ronald <Ronald.Stone@windriver.com<mailto:Ronald.Stone@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<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_install_kubernetes.html__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD_FQ7ev9A$> 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<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/bare_metal/aio_simplex_install_kubernetes.html__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD9i4tdKAA$> * And * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.html<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex.html__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD8v-CCg9g$> * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_environ.html<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_environ.html__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD9wnjuUMw$> * https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_install_kubernetes.html<https://urldefense.com/v3/__https://docs.starlingx.io/deploy_install_guides/release/virtual/aio_simplex_install_kubernetes.html__;!!AjveYdw8EvQ!boP47ELlpMl-EgbezJWOfV88GHWEL-73ZwIT9x9i2aefFtfwQQn6vsVsZMm4k1jnWWpP545WcyJZsZsXzMkdY-Wp8Q92yD_FQ7ev9A$> 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@windriver.com<mailto:Michel.Thebeau@windriver.com>> Sent: Wednesday, June 28, 2023 3:51 PM To: starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@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.
participants (3)
-
Bruno Drugowick Muniz
-
Thebeau, Michel
-
Waines, Greg