Fixes an issue in Caracal where setting a volume's bootable property
fails due to uninitialized oslo_privesp daemon inside cinder-volume
container.
This is a temporary workaround to set cinder-volume as privileged in
cinder static overrides. The details of the fix and associated task are
also in Openstack Storyboard.
Test Plan:
- PASS: Apply stx-openstack with changes.
- PASS: Verify bootable volume creation.
Closes-Bug: 2100010
Reference: https://storyboard.openstack.org/#!/story/2011307
Change-Id: I39cbdcb85ad81a66da7e4331cc1a543cb8416d68
Signed-off-by: Mateus Nascimento <mateus.soaresdonascimento@windriver.com>
(cherry picked from commit b49af69dc15c320c12e2d165b1af3954e9632ac1)
Removing unsupported client packages from the Caracal version
of the list of debian packages that are buildable. Reducing
unnecessary builds in the build-pkgs process.
Test Plan:
- PASS: Run build-pkgs -c -a.
- PASS: Build stx-openstack tarbal.
- PASS: Apply stx-openstack tarbal.
Story: 2011369
Task: 51727
Change-Id: I596c9eb5e51e5622c343c2b4a040de75e3d67ae8
Signed-off-by: vrochalo <vinicius.rochalobo@windriver.com>
It was found that after disabling the ingress reconciliation
during the update process, if for any reason the update fails
the old Ingress will not come back when the suspend flag is 'True'
in the Ingress Helmrelease.
This review aims to add an update step during the application
recovery, that will reactivate the Helmrelease reconciliation.
Test Plan:
PASS - Build python3-k8sapp-openstack package
PASS - Build STX-Openstack tarball
PASS - Run system application-update and force fail it
PASS - Update recovery is triggered
PASS - Full recovery to 24.09
Story: 2011262
Task: 51285
Change-Id: Ic390c81e65eaf40989318f4f91c75539a7a7295a
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
It was found that during the update process, after the
helmrelease is uninstalled, the FluxCD would automatically
redeploy the helmrelease that was uninstalled because of
the reconcile function of FluxCD.
To prevent this, this review adds a step to patch the helmrelease
and inform FluxCD that the Helm release is not to be reconciled.
Also, it was changed the moment where the cleanup function is called.
Before, it was being called as soon as the application apply began.
Now it will begin after the process of downloading the docker images
is finished. This will dimish the downtime and if the download failed
the application would not be down at any time.
Test Plan:
PASS - Build python3-k8sapp-openstack package
PASS - Build STX-Openstack tarball
PASS - Run system application-update
PASS - Application updated to 25.03
Story: 2011262
Task: 51657
Change-Id: I8fa90c7167f856df47d10a9fb55fcea08cb18ab6
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
After the upversion of OSH and OSH-I Helm charts to the caracal version, the image docker.io/starlingx/stx-ovs:master-debian-stable-latest is no longer compatible with the openvswitch deployment. This causes a CrashLoopBackOff in the OVS pods and STX-Openstack does not apply.
The focus here is to change the actual openvswitch to the community
version.
Test plan:
PASS: build-pkgs -c -a -l openstack
PASS: apply stx-openstack on a vdm
PASS: apply stx-openstack on a lab
PASS: create 2 vm's and ping each other separately
Closes-bug: #2096992
Change-Id: I2e82928f2083d2ebd5f3c7df71a781667f9260d7
Signed-off-by: kgoncalv <kayo.goncalvesdacosta@windriver.com>
As part of the STX-Openstack upversion, it was noticed that this
package creates a .deb necessary for images build.
All patches were updated in order to make the package buildable in the
new version.
With that upversion, future images updates will happen easily.
NOTE: this was initially committed on [1] but an error occurred on the
build of other packages so it was reverted until now, when that error
was fixed. The problem was a missed file on patch 0002
Test Plan:
PASS: Build the openstack-pkg-tools package
PASS: Build all packages
PASS: Build all stx docker images
Story: 2011303
Task: 51552
[1] https://review.opendev.org/c/starlingx/openstack-armada-app/+/939474
Change-Id: I2f53aadec423264404c6c004e477d798da4ba86f
Signed-off-by: Romulo Leite <romulo.leite@windriver.com>
This change aims to remove the default daemonsets agents that are being
created but are not being used.
The _daemonset_overrides.tpl file, creates the daemonsets with
overrides and still creates the default daemonsets that end up not
being used.
The solution for this was by patching openstack-helm-infra removing a
section that aggregate the default daemonset to a global list.
In order to not remove the neutron-netns-cleanup-cron-default, an
override for this was created in the static overrides under the name
neutron-netns-cleanup-cron-openstack-control-plane.
Before the patch we had 25 daemonsets and 8 of them were not being used.
After the patch been applied we now have 17 daemonsets and all of them are being used.
Test Plan:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
PASS: Upload and Apply openstack tarball on standard system
PASS: *default* daemonsets are not deployed in openstack ns
PASS: New daemonset neutron-netns-cleanup-cron-openstack-control-plane
deployed in openstack ns
PASS: Launch 2x Guest instances (centos-guest VMs)
PASS: Access instances through a remote console
PASS: Ping instances from remote console (all to all)
PASS: Ping instances from external server in the management network
Story: 2011304
Task: 51652
Change-Id: I0f83a8bf43ad4803820fdca22f77ceb182f30e9f
Signed-off-by: kgoncalv <kayo.goncalvesdacosta@windriver.com>
Co-authored-by: Ingo Almendros <ingo.almendrosgirao@windriver.com>
Cryptography changes implemented in Rust are using PyO3, which does not support multiple subinterpreters.
To address this, the Apache configuration for Horizon has been updated to ensure that the WSGI server uses the global Python interpreter.
This change ensures compatibility with the new Rust-based cryptography implementation and prevents potential issues with request handling.
Changes:
- Updated the Horizon Helm override configuration in conf.horizon.apache inside the VirtualHost directive.
Test Plan:
- PASS: Confirm that no errors related to subinterpreters appear in Horizon logs.
- PASS: Ensure that Horizon responds with HTTP status code 200 upon accessing the main page.
Reference:
- PyO3's lack of support for subinterpreters:
https://github.com/PyO3/pyo3/issues/3451
- Related OpenStack-Helm commit:
e81872d948
Story: 2011303
Task: 51502
Change-Id: I2d7b00719f0be17fae389c6a7326518f77be0404
Signed-off-by: Mateus Nascimento <mateus.soaresdonascimento@windriver.com>
stx-ironic image is currently failing to build on the f/caracal branch.
The charts aodh, barbican, ceilimoter and ironic are not currently
supported by STX-Openstack. Despite that, the stx-* images for this
charts are present on the list of images to be built.
This review removes the 4 images from the debian_stable_docker_images.inc
file. This way, unecessary images stops to being built
Test Plan:
PASS - Run build-stx-images.sh to build all images
PASS - No errors are given by the bash file
PASS - aodh, barbican, ceilometer and ironic images are not built
Closes-Bug: 2097783
Change-Id: If272117ce3983ec040cb508ca94ddf5b41954e3e
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
After the OSH-I upversion to caracal, the helm-toolkit used
in the Helm charts present in the openstack-armada-app repo
needs to have their version updated to reflect the changes
made to the OSH-I helm-tookit chart.
Test Plan:
PASS - Build stx-openstack-helm-fluxcd package
PASS - All charts have the new version in the built package
PASS - STX-O applies using the new Helm charts version.
Story: 2011303
Task: 51655
Depends-On: https://review.opendev.org/c/starlingx/openstack-armada-app/+/941984
Change-Id: I77cc1440712354266ae9a40c3d75b5b813499802
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
After the OSH-I upversion [1], a new Ingress chart was
introduced to STX-O application [2]. This resulted in 2
different Ingress Controllers running when trying a live
upgrade of the app.
This review aims to have the lifecycle plugin deleting the
deprecated Ingress release during an app update.
[1] - https://review.opendev.org/c/starlingx/openstack-armada-app/+/939081
[2] - https://review.opendev.org/c/starlingx/openstack-armada-app/+/939376
Test Plan:
PASS - Build python3-k8sapp-openstack package
PASS - Build StarlingX Openstack tarball
PASS - Run system application-update with the new tarball
PASS - Deprecated Ingress deleted during update
Story: 2011262
task: 51657
Change-Id: I2e3a9d2278512d88e9e66c62020add9afa095bbd
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
The _get_platform_res_limit function [1], used by the ingress plugin to
define resource limits, returns zero to both cpu and memory limits when
called from a standard system ("system_type != TIS_AIO_BUILD"). However,
in this case the function also returns "limit_enabled=False" to indicate
that the zero limits should not by applied.
Unlike the previous used ingress chart, the new ingress-nginx-openstack
chart activated by [2] does not support the "resources.enabled" config
to enable/disable the resource limits deployment. Therefore, the invalid
zero limits returned by the _get_platform_res_limit function on standard
systems is being incorrectly applied and preventing the new ingress
chart to be deployed on those systems.
This change ensures that the resource limits overrides will only be
defined and applied when the limits values returned by the function
_get_platform_res_limit are valid (limit_enabled==True).
[1] be275b6776/sysinv/sysinv/sysinv/sysinv/helm/base.py (L348)
[2] https://review.opendev.org/c/starlingx/openstack-armada-app/+/939376
Test Plan:
- STX-O tarball built and applied to a standard system
- ingress-nginx-openstack helm release deployed
Closes-Bug: #2097457
Change-Id: I1b0ae260154f7b365ba458308efff2d41948cd08
Signed-off-by: Alex Figueiredo <alex.fernandesfigueiredo@windriver.com>
The current horizon local config help url is leading to the
ussuri (2020) version of Openstack. With this update, the
current url is set to be the 2024.1 one
Test Plan:
- PASS: Generate tarball with new manifest version
- PASS: Apply generated tarball
Story: 2011303
Task: 51520
Depends-on: https://review.opendev.org/c/starlingx/openstack-armada-app/+/941984
Change-Id: I8c036e20af90c00d83dbed454b60a09efe9fed76
Signed-off-by: jbarboza <joaopedro.barbozalioneza@windriver.com>
This update modifies the Horizon image file to track the latest commit
of stable/2024.1, enabling the build of the stx-horizon Docker image.
It also updates the static overrides for MariaDB to upgrade it, as
Django 4.2 of Horizon requirements for 2024.1 mandate MariaDB 10.4 or
higher.
Additionally, this change includes pymemcache in the image and aligns
various components, including Horizon static overrides, to ensure
compatibility with pymemcache and the new version of Django. These
updates align with the stable/2024.1 branch of Horizon.
Test Plan:
- PASS: Successfully build the stx-horizon Docker image
- PASS: Apply the new tarball containing static override changes
- PASS: Override stx-horizon image tags
- PASS: Apply stx-openstack with Horizon and MariaDB image overrides
Story: 2011303
Task: 51502
Depends-on: https://review.opendev.org/c/starlingx/root/+/940525
Change-Id: I7be859eda41c0a22cb3b1cb6f0fe3180c7e2f492
Signed-off-by: Mateus Nascimento <mateus.soaresdonascimento@windriver.com>
After the OSH-I upversion, the Ingress Helm chart was
changed from the one from Openstack community to the
Ingress-nginx. A previous commit [1] added the new
Helm chart to the build environment and another [2]
created the manifest for this new Ingress chart. Now,
this review removes the old Ingress manifest and activates
the new Ingress Helm chart.
A patch was created to rename the Ingress Helm-chart so it
wouldn't have a conflict with the Ingress deployed by the platform.
All manifests and plugins of the old Ingress was deleted, and
all references (kustomization, dependencies, etc...) was changed
to the new Ingress chart name.
The new Ingress was placed as a dependency to the OSH-I debian package.
This dependencie was moved to the stx-openstack-helm-fluxcd debian
control, to facilitate the tarball building proccess. As it was, the
new Ingress needed to be declared in the tarball building call, with
this change this is not necessary anymore.
Finally the name for the ingressClass name in all Helm charts' Ingress
was changed for the new name defined by the Ingress patch.
[1] - https://review.opendev.org/c/starlingx/openstack-armada-app/+/937396
[2] - https://review.opendev.org/c/starlingx/openstack-armada-app/+/937174
Test Plan:
PASS - Build all packages and STX-O tarball
PASS - STX-O upload and apply
PASS - New Ingress Helm chart deployed with new name
PASS - Ingress from all charts with new ingressclassname
PASS - Ingress comunicates with other Helm charts
PASS - Launch a VM
This is the last change in the realtion chain related to the upversion
to the Caracal version and the activation of the new Ingress chart. All
reviews must be merged together, otherwise the build and apply of STX-O
will break.
Story: 2011303
Task: 51611
Change-Id: If10a47a470b6e32ccb1090dbaa604fcbf6d1f82e
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
This task aims to Upversion base OSH to Caracal (3013cbc9)
This change upversions the base commit SHA for openstack-helm
to the Caracal version. Because upstream OSH does not track
versions the same way Openstack does, the base commit [1] was
chosen after the caracal release date and the stability of the
changes in the upstream repo.
It also ports all StarlingX specific patches on top of it,
dropping the patches that are no longer necessary and updating
what needs to be updated in order to be applied on top of the
new base SHA.
Patches 0002, 0009, 0019 and 0022 had their changes merged
on the upstream OSH repo, therefore they were dropped in this
upversion.
Patch 0003 was also removed since a similar job was created
upstream. It remains a point of attention because altough
a similar job was created upstream there are some differences
between them. Patch 0012 was dropped as it only modified the
file created by the patch 0003.
Most of patch 0020 was merged upstream, because of that the size
of the patch was significantly reduced.
All static overrides had the dep_check image added, this image
was already present on the values file upstream but was not being
exposed on the static overrides.
In the Neutron Helm chart, some additional images were added. Most
of the images that were not previously used by STX-O were set as "null"
in the static overrides. The rpc_server proved to be necessary for the
deployment. Similarly, the Nova Helm chart had some images added and
deleted. The static overrides was updated accordingly.
Test Plan:
PASS - Run downloader to get new OSH version
PASS - Run build-pkgs -c -a -l openstack to rebuild all packages
PASS - OSH is on the Caracal version
PASS - All OSH patches are applied
PASS - STX-O is built
With this change STX-Openstack will stop applying until the all
reviews in the relation chain are merged as well. Because of that,
the Test Plan does not include the apply and proper functioning of
the application. The last review of the relation chain will have a
more torough test plan. In order for the build not to be broken, all
reviews in the relation chain should be merged together.
Story: 2011303
Task: 51429
[1] - 3013cbc94a
Change-Id: I988051a73c405c0df810cd24e9dc08fa1051faac
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
This task aims to Upversion base OSH-I to Caracal (05f2f459)
This change upversion the base commit SHA for openstack-helm-infra
to the Caracal version. Because upstream OSH-I does not track
versions the same way Openstack does, the base commit [1] was
chosen after the caracal release date and the stability of the
changes in the upstream repo.
It also ports all StarlingX specific patches on top of it,
dropping the patches that are no longer necessary and updating
what needs to be updated in order to be applied on top of the
new base SHA.
Patch 0005 was removed because upstream OSH-I implemented the same
config. Additional configurations set on the patch was translated
into a change in the static-overrides. Patch 0018 was dropped
because the Ingress Helm chart was removed from upstream OSH-I.
Finally, the changes in the patch 0016 were also merged
on upstream OSH-I, so with the upversion they can be dropped.
Helm Releases are updated to the caracal version of each Helm
chart from OSH-I.
Test Plan:
PASS - Run downloader to get new OSH-I version
PASS - Run build-pkgs -c -a -l openstack to rebuild all packages
PASS - OSH-I is on the Caracal version
PASS - All OSH-I patches are applied
PASS - STX-O is built
With this change STX-Openstack will stop applying until the all
reviews in the relation chain are merged as well. Because of that,
the Test Plan does not include the apply and proper functioning of
the application. The last review of the relation chain will have a
more torough test plan. In order for the build not to be broken, all
reviews in the relation chain should be merged together.
Story: 2011303
Task: 51428
[1] - 05f2f45971
Change-Id: I43a11570a176f1b5aceda88c0cb3c76b2f5d228e
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
Updated PROJECT_REF in stx-nova
to ensure compatibility with stable/2024.1.
The upversion depends on requirements being updated to newer versions,
as outlined in https://review.opendev.org/c/starlingx/root/+/939645.
Test Plan:
- PASS: Build stx-nova image
- PASS: Override nova tag
- PASS: Apply STX-O with image overrides
Story: 2011303
Task: 51606
Depends-on: https://review.opendev.org/c/starlingx/openstack-armada-app/+/941979/
Change-Id: I49683000c065f31b811b352cc1e42211a6aef8d8
Signed-off-by: vrochalo <vinicius.rochalobo@windriver.com>
The AvailabilityZoneFilter was deprecated and removed from the list of
filters defined in nova scheduler [1].
Therefore, the filter must be removed from the list of "enabled_filters"
defined in the nova static overrides. Otherwise, nova scheduler will
raise a SchedulerHostFilterNotFound exception [2].
[1] https://review.opendev.org/c/openstack/nova/+/886779
[2] https://docs.openstack.org/nova/2024.1/configuration/config.html
Test Plan:
PASS - build stx-openstack tarball
PASS - upload and apply stx-openstack tarball to a running system
Story: 2011303
Task: 51621
Change-Id: I42c9347c92787378f503d856b0c9ac06159a5738
Signed-off-by: Alex Figueiredo <alex.fernandesfigueiredo@windriver.com>
Added test for cluster host overrides with same configurations.
This change improves scalability by grouping compute nodes with
identical configurations under a single profile, reducing the size of
neutron overrides.
The update allows specifying multiple hosts for a single daemonset.
These tests validates that the configurations are being correctly
grouped.
TEST PLAN:
PASS: Build python3-k8sapp-openstack
PASS: Build openstack
PASS: Execute all unit tests locally
PASS: Confirm that all new unit tests are executed as part of the local
test run
Story: 2011304
Task: 51612
Change-Id: I54b5bd396f77accae3887e8b250eb9b24b2a67e2
Signed-off-by: Thiago Miranda <tmarques@windriver.com>
As part of the STX-Openstack upversion to CARACAL, the python-
cinderclient is being upversioned to version 9.5.0-1 [1], which is the
latest supported on CARACAL [2].
The commit hash of the used repo is:
3b2e2c028bd6b650dce64976f8b48409e2fa85b2
All patches were updated in order to make the package buildable in the
new version.
[1] https://salsa.debian.org/openstack-team/clients/python-cinderclient/-/tree/debian/9.5.0-1?ref_type=tags
[2] https://releases.openstack.org/caracal/index.html#caracal-python-cinderclient
Story: 2011303
Task: 51470
Test Plan:
PASS: Build the python-cinderclient package
PASS: Build the stx-openstackclients image
PASS: Tested custom image in a running stx-openstack
Change-Id: Ifec8b4714a7d45c1cf8dab332d1e76778b276db1
Signed-off-by: Joao Fracarolli <joao.vicentinifracarolli@windriver.com>
The Openstack upstream community have deprecated its
Ingress Helm chart and begun to use the Helm chart from
Nginx.
The purpose of this task is to add a new FluxCD Manifest
for the Ingress-nginx Helm chart without removing the
current Ingress manifest. There will be a follow-up to
this review that will substitute the current ingress
manifest with the new one. Because of that, ingress-nginx
is not being added to the kustomization file, as it is
not to be deployed right now.
The plugin for this new Helm chart is also added to the
helm folder.
Test Plan:
PASS - Build stx-openstack-helm-fluxcd and STX-O
PASS - Ingress-nginx Helm chart appears in the build
PASS - Update and apply STX-O
PASS - Ingress-nginx is present but not deployed
Story: 2011303
Task: 51430
Change-Id: Iaf3cb33724871141abb5f8334b5043d3b823041b
Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
With the deprecation of the Ingress Helm chart [1], this change
replaces it with a community-supported version. This commit
introduces the base ingress-nginx-helm package to the project,
allowing future updates to be easily integrated
The ingress-nginx-helm package was copied from [2] and
reviewed based on Starling Packaging Reference doc [3].
[1] https://kubernetes.github.io/ingress-nginx
[2] https://opendev.org/starlingx/nginx-ingress-controller-armada-app/src/branch/master/helm-charts/upstream/ingress-nginx-helm
[3] https://docs.starlingx.io/developer_resources/packaging_ref.html
Test Plan:
- PASS: run build-pkgs -c -p ingress-helm-nginx
- PASS: run dpkg -c ingress-nginx-helm*.deb
- PASS: check if ingress-nginx*.tgz exists
- PASS: run dpkg-deb -f ingress-nginx-helm*.deb Version
- PASS: check if package version matches
Story: 2011303
Task: 51451
Change-Id: I339c4e5f789fe4c627af6cc714156dea1bffe8db
Signed-off-by: jbarboza <joaopedro.barbozalioneza@windriver.com>
Upgrading from 24.09 25.03 meant the file
needed to be updated to be compatible with
stx release.
Test Plan:
PASS - Build stx-openstack tgz
PASS - Apply stx-openstack and check new version
Change-Id: Ibec37a25a6ee86d816adb1ef1d3cc28476e8a770
Signed-off-by: vrochalo <vinicius.rochalobo@windriver.com>
This reverts commit 32b671624f00f14a876b99e68e4a5d79e761255f.
Reason for revert: Reverting this form main branch to smooth the f/caracal merge-back process later. For now, this will be merged directly into f/caracal - https://review.opendev.org/c/starlingx/openstack-armada-app/+/940909
Change-Id: I2da3a04dc861b2a1e4852ad25199a34a447792b9
This change adds the maintain_user_overrides in the metadata.yaml
file to prevent user overrides from being discarded when the
application is updated [1].
This allows the application-update command to be run without the
--reuse-user-overrides flag and yet maintain any user overrides
that were applied prior to the update.
References:
[1] https://wiki.openstack.org/wiki/StarlingX/Containers/Applications/AppIntegration#maintain_user_overrides
TEST PLAN:
PASS - build openstack layer packages
PASS - build application tarball
PASS - check if the option is in metadata.yaml file inside the tarball
PASS - update running aplication with the tarbal land check if the
user overrides are still applied
Story: 2011262
Task: 51279
Change-Id: I51226d700fe33d1c4f5519d71f544f06c687906f
Signed-off-by: Joao Fracarolli <joao.vicentinifracarolli@windriver.com>
This change aims to remove the default daemonsets agents that are being
created but are not being used.
The _daemonset_overrides.tpl file, creates the daemonsets with
overrides and still creates the default daemonsets that end up not
being used.
The solution for this was by patching openstack-helm-infra removing a
section that aggregate the default daemonset to a global list.
In order to not remove the neutron-netns-cleanup-cron-default, an
override for this was created in the static overrides under the name
neutron-netns-cleanup-cron-openstack-control-plane.
Before the patch we had 25 daemonsets and 8 of them were not being used.
After the patch been applied we now have 17 daemonsets and all of them are being used.
Test Plan:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
PASS: Upload and Apply openstack tarball on standard system
PASS: *default* daemonsets are not deployed in openstack ns
PASS: New daemonset neutron-netns-cleanup-cron-openstack-control-plane
deployed in openstack ns
PASS: Launch 2x Guest instances (centos-guest VMs)
PASS: Access instances through a remote console
PASS: Ping instances from remote console (all to all)
PASS: Ping instances from external server in the management network
Story: 2011304
Task: 51652
Change-Id: I90a74c3e7da1d05a3db6661a2a3f7fd29a444ab9
Signed-off-by: kgoncalv <kayo.goncalvesdacosta@windriver.com>
Co-authored-by: Ingo Almendros <ingo.almendrosgirao@windriver.com>
During the review of the change [1], a block of source code has
been completely indented. This completely changed the structure of
the source code previously validated at Patchset 8 [2], causing the
stx-openstack upload failure.
The fix was to undo the wrong indentation, taking the code back to the
correct indentation tested at Patchset 8 [2].
[1] https://review.opendev.org/c/starlingx/openstack-armada-app/+/938407
[2] https://review.opendev.org/c/starlingx/openstack-armada-app/+/938407/8
Test Plan:
PASS: build-pkg openstack -c -l openstack
PASS: build openstack tarball
PASS: upload and apply openstack on a system
Closes-Bug: #2093370
Change-Id: I3c405b473515011a0ffb4568873708e72909ce3a
Signed-off-by: kgoncalv <kayo.goncalvesdacosta@windriver.com>
Neutron L3 agent daemonsets are only required if openvswitch is enabled.
However, currently, even when openvswitch is not used the L3 agent
daemonsets are being created, but never deployed. This increases the k8s
memory consumption and affects the platform scalability (number of
compute nodes supported).
This change enables the deployment of Neutron L3 agent daemonsets only
when openvswitch is enabled.
Test Plan:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
PASS: Upload and Apply openstack tarball on standard system
PASS: Check that Neutron L3 agents are not deployed
PASS: Check size reduction in Neutron release secret
PASS: Launch 3x Guest instances (centos-guest VMs)
PASS: Access instances through a remote console
PASS: Ping instances from remote console (all to all)
PASS: Ping instances from external server in the management network
Story: 2011304
Task: 51504
Change-Id: If22f63cf893d547e1e31da71ddb512622a25662c
Signed-off-by: Ingo Almendros Girao <ingo.almendrosgirao@windriver.com>
Co-authored-by: Alex Figueiredo <alex.fernandesfigueiredo@windriver.com>
Currently, the Nova plugin defines overrides per-host.
This task goal aims to consolidate these overrides by grouping hosts
with identical configurations. This change uses a feature introduced by
[1].
This structure ensures that the overrides section contains a
concise and consolidated set of overrides for group of hosts.
This approach aims to allow Nova-compute to be deployed using fewer
daemonsets of the nova release secrets, improving the stx-openstack
scalability. See below the new override structure:
overrides:
nova_compute:
hosts:
- conf:
nova:
:: :: ::
:: :: ::
:: :: ::
name:
- compute-0
- compute-2
- compute-3
[1]https://review.opendev.org/c/starlingx/openstack-armada-app/+/937807
Test Plan:
Build:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
System with identical configs (overrides grouped):
PASS: Upload and apply openstack tarball on standard system with
identical configs for nova overrides
PASS: Check grouping of nova overrides
PASS: Check grouping of nova daemonsets
PASS: Launch 1x Guest instance (centos-guest VMs)
System with different configs (overrides ungrouped):
PASS: Upload and apply openstack tarball on duplex system with
different configs for nova overrides
PASS: Check that nova overrides are ungrouped
PASS: Check that nova daemonsets are ungrouped
PASS: Launch 1x Guest instance (centos-guest VMs)
Story: 2011304
Task: 51515
Change-Id: I1e0ae0078c6457447a4c719ffda2aef6aedcdc65
Signed-off-by: kayo-costa <kayo.goncalvesdacosta@windriver.com>
This task aims to change the IP acquisition method for Nova compute
pods from the Nova plugin to a new environment variable that maps to
the status.hostIP field. The environment variable-based approach will
provide the cluster host IP address to the Nova compute container.
With the goal of assisting in the task of deploying Nova compute with
fewer daemonsets, grouping hosts with identical configurations, and
consequently making the solution more scalable, this implementation
removes the responsibility from the plugin of setting the IP
information, since doing so would prevent the grouping of the override
configurations due to having different values for each compute host.
Using the environment variable-based approach, the IP change will occur
inside the container just before executing the nova-compute command.
Since this task aims to set the IP inside the container and the Nova
configuration file located at /etc/nova is read-only, a new Nova
configuration file has been created, which is located inside the
compute container at /tmp/pod-shared, a similar approach of using this
path is already followed by other Nova configuration files
(nova-console.conf, nova-hypervisor.conf and nova-libvirt.conf). The
difference between the two nova.conf files is only the IPs in fields
my_ip, server_listen, server_proxyclient_address and
live_migration_inbound_addr, which will contain the cluster host IP
configured in the new environment variable in the new one.
TEST PLAN:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
PASS: upload and apply openstack tarball on standard system
PASS: nova-compute pod is running
PASS: CLUSTER_HOST_IP environment variable created with
.status.hostIP value
PASS: /tmp/pod-shared/nova.conf has the same configuration of
/etc/nova/nova.conf, with the only difference being that the
fields:
DEFAULT.my_ip
vnc.server_listen
vnc.server_proxyclient_address and
libvirt.live_migration_inbound_addr
are updated with the IP from the new environment variable
PASS: launch a guest instance (tis-centos-guest VM)
Story: 2011304
Task: 51517
Change-Id: I19792f4c15bc9adddc7e45c2d600ddeb1b3ec420
Signed-off-by: marantes <murillo.arantes@windriver.com>
The issue of having a config profile for each
compute of each neutron agent is that each
profile holds the information of the specific
compute node even if there are compute nodes
with the same config.
As the number of compute nodes increase,
the size of the overrides for neutron increases
as well. This results in a big increase in the
size of the neutron overrides.
The goal is to have StarlingX Openstack fully
functional and with a better scalability after
changing the way of how the config profiles to
each compute node is generated on neutron by
grouping computes with the same profile
per agent.
This adds support for specifying multiple
hosts for a single daemonset in
conf.overrides.neutron_dhcp-agent.hosts[].name
as shown below:
overrides:
neutron_dhcp-agent:
hosts:
- conf:
:: :: ::
:: :: ::
:: :: ::
name:
- compute-0
- compute-1
- compute-2
In one of the tests, the size reduced from
383044 to 267788 bytes (~30% less).
Before the change:
$ kubectl describe secret \
sh.helm.release.v1.osh-openstack-neutron.v1\
-n openstack
Name: sh.helm.release.v1.osh-openstack-neutron.v1
Namespace: openstack
Labels: modifiedAt=1735071637
name=osh-openstack-neutron
owner=helm
status=deployed
version=1
Annotations: <none>Type: helm.sh/release.v1Data
====
release: 383044 byte
After the change:
$ kubectl describe secret \
sh.helm.release.v1.osh-openstack-neutron.v1\
-n openstack
Name: sh.helm.release.v1.osh-openstack-neutron.v1
Namespace: openstack
Labels: modifiedAt=1735071637
name=osh-openstack-neutron
owner=helm
status=deployed
version=1
Annotations: <none>Type: helm.sh/release.v1Data
====
release: 267788 bytes
The reduction can be bigger as the number of
hosts with the same configurations increase.
Test Plan:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
PASS: Upload and Apply openstack tarball
on standard system
PASS: Check grouping of Neutron overrides
PASS: Check size reduction in Neutron
release secret
PASS: Launch 3x Guest instances
(tis-centos-guest VMs)
PASS: Access instances through a remote
console
PASS: Ping instances from remote console
(all to all)
PASS: Ping instances from external server
in the management network
Story: 2011304
Task: 51435
[1]: https://storyboard.openstack.org/#!/story/2011304 (TASK 51436)
Change-Id: I0344b7939932d91f7c23935a8e5a52cb6e3af62a
Signed-off-by: vrochalo <vinicius.rochalobo@windriver.com>
A daemonset overrides template generates a separate
daemonset and configuration secret for each host, even when
configurations are identical. This approach leads to unnecessary
resource consumption and complexity.
This adds support for specifying multiple hosts for a single daemonset
in conf.overrides.neutron_dhcp-agent.hosts[].name as shown below:
overrides:
neutron_dhcp-agent:
hosts:
- conf:
plugins:
openvswitch_agent:
agent: {}
ovs:
bridge_mappings: group0-data0:br-phy0,group0-data0b:br-phy0,group0-data1:br-phy0,group0-ext0:br-phy0,
datapath_type: system
integration_bridge: br-int
vhostuser_socket_dir: /var/run/openvswitch
sriov_agent:
agent:
root_helper: ''
securitygroup:
firewall_driver: noop
sriov_nic:
physical_device_mappings: ''
name:
- compute-0
- compute-1
- compute-2
In one of the tests, the size reduced from 383044 to 267788 bytes (~30%
less).
Before the change:
[sysadmin@controller-0 ~(keystone_admin)]$ kubectl describe secret sh.helm.release.v1.osh-openstack-neutron.v1 -n openstack
Name: sh.helm.release.v1.osh-openstack-neutron.v1
Namespace: openstack
Labels: modifiedAt=1735071637
name=osh-openstack-neutron
owner=helm
status=deployed
version=1
Annotations: <none>Type: helm.sh/release.v1Data
====
release: 383044 byte
After the change:
[sysadmin@controller-0 ~(keystone_admin)]$ kubectl describe secret sh.helm.release.v1.osh-openstack-neutron.v1 -n openstack
Name: sh.helm.release.v1.osh-openstack-neutron.v1
Namespace: openstack
Labels: modifiedAt=1735049803
name=osh-openstack-neutron
owner=helm
status=deployed
version=1
Annotations: <none>Type: helm.sh/release.v1Data
====
release: 267788 bytes
The reduction can be bigger as the number of hosts with the same
configurations increase.
Test Plan:
PASS: build-pkg -c -l openstack
PASS: build openstack tarball
PASS: Upload and Apply openstack tarball on standard system
PASS: Check grouping of Neutron overrides
PASS: Check size reduction in Neutron release secret
PASS: Launch 3x Guest instances (tis-centos-guest VMs)
PASS: Access instances through a remote console
PASS: Ping instances from remote console (all to all)
PASS: Ping instances from external server in the management network
Task: 51436
Story: 2011304
Change-Id: Ib9f41d9c9578d9340299b6438309b24826fce805
Signed-off-by: Daniel Bolgheroni <Daniel.Bolgheroni@windriver.com>
This commit introduces support for using NetApp as a volume backend for
Cinder in STX-OpenStack Helm, adding compatibility with both NFS and
iSCSI protocols. The motivation for this enhancement is to provide
greater flexibility for deployments that leverage NetApp storage
solutions, allowing users to configure and manage their storage backends
more effectively. The implementation is designed to be modular, ensuring
that the NetApp backend is not enabled by default but can be activated
through user-defined overrides.
The code introduces configuration templates for the NetApp drivers in
the `values.yaml` file for the Cinder Helm chart. Two backends are
defined: `netapp-nfs`, which uses the NFS protocol, and `netapp-iscsi`,
which relies on iSCSI. These configurations include key parameters like
the NetApp storage protocol, server hostname, and authentication
credentials described in [1] and [2]. However, by default, these backends
are not included in the `enabled_backends` list, ensuring that they
remain inactive unless explicitly enabled by the user or the plugins.
The NetApp backends will be automatically added to the deployment of
Cinder if the plugin verifies that it is available in the cluster. If an
user has NetApp but don't want to use it in STX-Openstack, an override
can be defined for `conf.cinder.DEFAULT.enabled_backends`, which will
have a higher priority than the system overrides generated by the
plugin.
To support the NFS backend specifically, a new `nfs.shares` file was
introduced in the Cinder ConfigMap, providing a location to define NFS
shares for the NetApp driver. The Cinder volume deployment is updated to
mount this file, ensuring that it is accessible to the Cinder service.
The deployment templates now include logic to handle the mounting of
this file dynamically.
Utility functions are enhanced to improve the detection of available
NetApp backends. The function `check_netapp_backends`, which executes the
`tridentctl` command to determine if the required NetApp drivers
(`ontap-nas` for NFS or `ontap-san` for iSCSI) are available. This
function returns a dictionary indicating the availability of these
backends, which is then used to dynamically adjust the Cinder Helm
overrides. The existing `is_netapp_available` function now uses this
enhanced logic to provide a simplified check for whether any NetApp
backend is available.
In the Helm configuration logic, overrides for the NetApp backends were
added dynamically based on the results of these utility checks. If either
the NFS or iSCSI backend is available, the necessary parameters are
appended to the backend overrides, ensuring that they are included in the
final deployment configuration. This approach avoids hardcoding and
allows the deployment to adapt to the specific NetApp backends detected
in the environment.
The implementation ensures that NetApp backends are disabled by default,
preventing unintended configurations while enabling users to activate
them seamlessly when needed.
[1] https://netapp.github.io/openstack-deploy-ops-guide/juno/content/cinder.examples.cinder_conf.html
[2] https://wiki.openstack.org/wiki/How_to_deploy_cinder_with_NetApp
Test Plan:
PASS: Build / Upload / Apply STX-Openstack
Not using NetApp:
PASS: Verify that the NetApp backends are not enabled in cinder.conf
PASS: Create a volume and verify that it was stored in Ceph
Using NetApp NFS:
PASS: Apply Helm overrides with the configuration pointing to the
NetApp cluster using an NFS backend
PASS: Verify that the netapp-nfs backend is enabled in cinder.conf
FAIL: Create a volume and verify that it was stored in NetApp by
accessing the ONTAP dashboard
Using NetApp iSCSI:
PASS: Apply Helm overrides with the configuration pointing to the
NetApp cluster using an iSCSI backend
PASS: Verify that the netapp-iscsi backend is enabled in cinder.conf
Failed test case is due to bug #2090845, which is already being worked
on.
Story: 2011281
Task: 51411
Task: 51412
Change-Id: I46cb68c5950e3343a3ed3a644981f558542e53d1
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
In preparation for the addition of the NetApp driver, some changes were
required in the Cinder Python plugin to allow for multiple backends to
be used at the same time. As STX-Openstack only supported Ceph so far,
this was not a requirements, so the plugin was written in a way that it
would either use Ceph or Ceph Rook as a backend. But now that we're
starting to support other backends as well, the logic for this plugin is
no longer valid.
Test Plan:
PASS: Build / Upload / Apply STX-Openstack
PASS: With Ceph configured as a backend, create a volume
Story: 2011281
Task: 51410
Change-Id: Id930bc29b5d4799fc65c5ce5943b21dec5d30d1f
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
STX-O needs to support NetApp storage backend. A new function should be
created to validate if there is support for the NetApp storage system.
Whenever it is necessary for Cinder, Glance or Nova to check for NetApp
storage backend support, this function will be used.
This commit creates a new function that returns True if NetApp backend
is available and False if it is not.
Test Plan:
PASS - Validate True return when NetApp backend is available
PASS - Validate False return when NetApp backend is not available
PASS - Validate False if wrong namespace is used
PASS - Build / upload / apply STX-Openstack
Story: 2011281
Task: 51342
Change-Id: I1f3cce6ff21b3babd26cbf18648962da1b5eaab8
Signed-off-by: Johnny Chia <johnny.chialung@windriver.com>
After [1] was introduced, it was noted that if the end user changed the
FQDN pattern ([2]), the novncproxy endpoint would not follow it. This
was caused because the function that sets the URL for this service was
not calling the function that uses this pattern, but instead was just
using a similar logic.
This change simply updates the `_get_novncproxy_base_url` function to
use the user-defined FQDN endpoint pattern instead of a hard-coded one.
[1] 0c02ebf1e1
[2] https://opendev.org/starlingx/openstack-armada-app/src/branch/master/stx-openstack-helm-fluxcd/stx-openstack-helm-fluxcd/helm-charts/clients/values.yaml#L219
Test Plan:
PASS: Build / Upload / Apply STX-Openstack
PASS: Modify the `serviceEndpointPattern` value for a custom one
("{service_name}.{endpoint_domain}" for example)
PASS: After applying TLS, create a VM and access its console via
Horizon
Closes-Bug: 2089165
Change-Id: I502ede740f834a7dfd7171bb205dc5e6e7b524a2
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
